Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com> Subject: Document Action: 'Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE' to Informational RFC (draft-shiomoto-ccamp-switch-programming-05.txt) The IESG has approved the following document: - 'Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE' (draft-shiomoto-ccamp-switch-programming-05.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-shiomoto-ccamp-switch-programming/
Technical Summary The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and links to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives. End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to programme their data planes relative to sending and receiving control plane messages. This document clarifies and summarises the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. Working Group Summary The document was written in the hope that the CCAMP working group would adopt it. In the end, the working group reviewed and contributed to the document, but the chairs agreed that the work was not central to the working group and that AD Sponsored would be a more appropriate course. The document has been reviewed on several occasions by the CCAMP working group including a formal review instigated by the chairs when it became clear that the authors would request AD sponsorship. Document Quality This Informational document does not define new protocol elements. It seeks to describe existing implementations and give advice for new implementations. Personnel Daniel King (firstname.lastname@example.org) is the Document Shepherd for this document. Stewart Bryant (email@example.com) is the Responsible Area Director. RFC Editor Note OLD -- section 1, paragraph 4: "...with relation to the programming..." NEW -- section 1, paragraph 4: "...in relation to the programming..."