datatracker.ietf.org
Sign in
Version 5.3.1, 2014-04-16
Report a bug

Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE
RFC 6383

Internet Engineering Task Force (IETF)                       K. Shiomoto
Request for Comments: 6383                                           NTT
Category: Informational                                        A. Farrel
ISSN: 2070-1721                                       Old Dog Consulting
                                                          September 2011

           Advice on When It Is Safe to Start Sending Data on
             Label Switched Paths Established Using RSVP-TE

Abstract

   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 link 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 program their data planes relative to sending and receiving
   control-plane messages.

   This document clarifies and summarizes 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.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

Shiomoto & Farrel             Informational                     [Page 1]
RFC 6383            RVSP-TE Data Label Switch Update      September 2011

   Information about the current status of this document, any
   errata, and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6383.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   The Resource Reservation Protocol (RSVP) [RFC2205] has been extended
   to support Traffic Engineering (TE) in Multiprotocol Label Switching
   (MPLS) and Generalized MPLS (GMPLS) networks [RFC3209] [RFC3473].
   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.
   In some technologies this requires configuration of physical devices,
   while in others it may involve the exchange of commands between
   different components of the node.  The nature of a cross-connect is
   described further in Section 1.1.1.

   End points of an LSP need to know when it is safe to start sending
   data.  In this context "safe" has two meanings.  The first issue is
   that the sender needs to know that the data path has been fully
   established, setting up the cross-connects and removing any old,
   incorrect forwarding instructions, so that data will be delivered to
   the intended destination.  The other meaning of "safe" is that in
   optical technologies, lasers must not be turned on until the correct
   cross-connects have been put in place to ensure that service

[include full document text]