1 / 9

IETF 70, PCE WG, Vancouver 12/04/2007

sanjiv
Download Presentation

IETF 70, PCE WG, Vancouver 12/04/2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PCE communication Protocol (PCEP)draft-ietf-pce-pcep-09.txtJ.P. Vasseur (Cisco System Inc.) J.L. Le Roux (France Telecom) A. Ayyangar (Nuova Systems) E. Oki (NTT) A. Atlas (Google) A. Dolganow (Alcatel) Y. Ikejiri (NTT Communications Corporation) K. Kumaki (KDDI Corporation) IETF 70, PCE WG, Vancouver 12/04/2007

  2. Changes since last version 1/2 • P flag of the END-POINT object MUST be set in PCReq messages • P flag of the RP object MUST be set in PCReq/PCRep and MUST be cleared in PCErr/PCNtf • Clarification on receiving two optimization metric objects (B=0) • the receiving peer MUST send a PCErr message with Error-type=10 and Error-value=2 • New Error Type/Values: • Type 10: reception of a malformed object • Value 1: reception of an object with P flag not set although it must be set • Value 2: reception of a PCReq message with two METRIC object with B-flag clear

  3. Changes since last version 2/2 • PCEP TLVs • We used to have different TLV formats • We have now defined a single TLV format for all PCEP objects • Type: 2 bytes, Length: 2 bytes • We redefined the NO-PATH-VECTOR, OVERLOAD-DURATION and REQ-MISSING TLVs accordingly • Single IANA code point registry • Clarification regarding non understood object • If a PCReq includes multiple unsynchronized requests, only requests for which an object with the P flag set is unknown/unsupported MUST be rejected • If a PCReq includes multiple synchronized requests, with one request for which an object with the P flag set is unknown/unsupported => All requests MUST be rejected • Change in the FSM with regards to the collision resolution procedure • IANA Section updated • Rewordings for the sake of clarity

  4. Collision Resolution • Collision when two PCEP peers try simultaneously to setup a PCEP session • May lead to two TCP connections and two PCEP sessions • Collision resolution used to be performed in the TCPPending state, that is at the TCP level • If the system detects that a PCE Peer with an higher IP @ tries to simultaneously establish a TCP connection, it stops the current TCP connection establishment and goes back to the idle state • Difficult to implement due to atomicity of TCP socket methods • Now performed in the OpenWait sate, at the "application" level • If Open received, check other sessions with same peer • If one other session => Collision resolution • If the system initiated the current session and has lower IP @, it closes the TCP connection and goes back to the idle state • Thanks to Fabien Verhaeghe that raised this point

  5. Next Steps • Again thanks a lot for the very useful comments provided by implementers • At least 9 known implementations on the table which is quite good for a two years old protocol ! • Adrian agreed to make a detailed review • For sure a few comments  • Rev 10 to be submitted before end December => WG last Call • Target: Document sent to the IESG before end January • Extensive testing, successful interop testing

  6. France Telecom / MARBEN Products PCEP Interoperability sessionFabien Verhaeghe (MARBEN Products) Mohamad Chaitou (France Telecom) IETF 70, PCE WG, Vancouver 12/04/2007

  7. PCEP Interoperability session scope Profile FT PCC / MARBEN PCE FT PCE / MARBEN PCC Session management PCEP session opening/closing PCEP session parameters negotiation PCEP KeepAlive Mechanism PCEP session FSM (OpenWait, KeepWait…) Computation Request Simple requests with no constraint Multi constraint requests Unsuccessful Path Computation Path Reply with optional object Path requests with unsupported object

  8. PCEP interoperability session results PCEP Session management No interoperability problem encountered No interoperability problem encountered Common understanding of the PCEP draft PCEP protocol quite straight forward  risk of interoperability problem seems very low Path Computation Request Conclusion

  9. ThanksQuestions?

More Related