doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6383.txt b/doc/rfc/rfc6383.txt
new file mode 100644
index 0000000..a0c8375
--- /dev/null
+++ b/doc/rfc/rfc6383.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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
+   personnel are not put at risk.
+
+   Similarly, all Label Switching Routers (LSRs) along the path of the
+   LSP need to know when to program their data planes relative to
+   sending and receiving control-plane messages.
+
+
+
+
+Shiomoto & Farrel             Informational                     [Page 2]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+   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.  Bidirectional LSPs, it
+   should be noted, are supported only in GMPLS.  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.  For example, the dynamic provisioning performance metrics
+   set out in [RFC5814] need to be understood in the context of LSP
+   setup times and not in terms of control message exchange times that
+   are actually only a component of the whole LSP establishment process.
+
+   Implementations could significantly benefit from this document
+   definitively identifying any LSR to forward the Path or Resv message
+   [RFC3473] before programming its cross-connect, thereby exploiting
+   pipelining (i.e., doing one action in the background while another is
+   progressing) to try to minimize the total time to set up the LSP.
+   However, while this document gives advice and identifies the issues
+   to be considered, it is not possible to make definitive statements
+   about how much pipelining is safe, since a node cannot "know" much
+   without first probing the network (for example, with protocol
+   extensions) which would defeat the point of pipelining.  Due to the
+   number of variables introduced by path length, and other node
+   behavior, ingress might be limited to a very pessimistic view for
+   safety.  Furthermore, it seems unlikely that an implementation would
+   necessarily give a full and frank description of how long it takes to
+   program and stabilize its cross-connects.  Nevertheless, this
+   document identifies the issues and opportunities for pipelining in
+   GMPLS systems.
+
+1.1.  Terminology
+
+   It is assumed that the reader is familiar with the basic message
+   flows of RSVP-TE as used in MPLS-TE and GMPLS.  Refer to [RFC2205],
+   [RFC3209], [RFC3471], and [RFC3473] for more details.
+
+1.1.1.  What is a Cross-Connect?
+
+   In the context of this document, the concept of a "cross-connection"
+   should be taken to imply the data forwarding instructions installed
+   (that is, "programmed") at a network node (or "switch").
+
+   In packet MPLS networks, this is often referred to as the Incoming
+   Label Map (ILM) and Next Hop Label Forwarding Entry (NHLFE) [RFC3031]
+   which are sometimes considered together as entries in the Label
+   Forwarding Information Base (LFIB) [RFC4221].  Where there is
+
+
+
+Shiomoto & Farrel             Informational                     [Page 3]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+   admission control and resource reservation associated with the data
+   forwarding path (such as the allocation of data buffers) [RFC3209],
+   this can be treated as part of the cross-connect programming process
+   since the LSP will not be available to forward data in the manner
+   agreed to during the signaling protocol exchange until the resources
+   are correctly allocated and reserved.
+
+   In non-packet networks (such as time-division multiplexing, or
+   optical switching networks), the cross-connect concept may be an
+   electronic cross-connect array or a transparent optical device (such
+   as a microelectromechanical system (MEMS)).  In all cases, however,
+   the concept applies to the instructions that are programmed into the
+   forwarding plane (that is, the data plane) so that incoming data for
+   the LSP on one port can be correctly handled and forwarded out of
+   another port.
+
+2.  Unidirectional MPLS-TE LSPs
+
+   [RFC3209] describes the RSVP-TE signaling and processing for MPLS-TE
+   packet-based networks.  LSPs in these networks are unidirectional by
+   definition (there are no bidirectional capabilities in [RFC3209]).
+
+   Section 4.1.1.1 of [RFC3209] describes a node's process prior to
+   sending a Resv message to its upstream neighbor.
+
+      The node then sends the new LABEL object as part of the Resv
+      message to the previous hop.  The node SHOULD be prepared to
+      forward packets carrying the assigned label prior to sending the
+      Resv message.
+
+   This means that the cross-connect should be in place to support
+   traffic that may arrive at the node before the node sends the Resv.
+   This is clearly advisable because the upstream LSRs might otherwise
+   complete their cross-connections more rapidly and encourage the
+   ingress to start transmitting data with the risk that the node that
+   sent the Resv "early" would be unable to forward the data it received
+   and would be forced to drop it, or might accidentally send it along
+   the wrong LSP because of stale cross-connect information.
+
+   The use of "SHOULD" [RFC2119] in this text indicates that an
+   implementation could be constructed that sends a Resv before it is
+   ready to receive and forward data.  This might be done simply because
+   the internal construction of the node means that the control-plane
+   components cannot easily tell when the cross-connection has been
+   installed.  Alternatively, it might arise because the implementation
+   is aware that it will be slow and does not wish to hold up the
+   establishment of the LSP.  In this latter case, the implementation is
+   choosing to pipeline the cross-connect programming with the protocol
+
+
+
+Shiomoto & Farrel             Informational                     [Page 4]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+   exchange taking a gamble that there will be other upstream LSRs that
+   may also take some time to process, and it will in any case be some
+   time before the ingress actually starts to send data.  It should be
+   noted that, as well as the risks described in the previous paragraph,
+   a node that behaves like this must include a mechanism to report a
+   failure to chase the Resv message (using a PathErr) in the event that
+   the pipelined cross-connect processing fails.
+
+3.  GMPLS LSPs
+
+   GMPLS [RFC3945] extends RSVP-TE signaling for use in networks of
+   different technologies [RFC3471] [RFC3473].  This means that RSVP-TE
+   signaling may be used in MPLS packet switching networks, as well as
+   layer two networks (Ethernet, Frame Relay, ATM), time-division
+   multiplexing networks (Time Division Multiplexer (TDM), i.e.,
+   Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy
+   (SDH)), Wavelength Division Multiplexing (WDM) networks, and fiber
+   switched network.
+
+   The introduction of these other technologies, specifically the
+   optical technologies, brings about the second definition of the
+   "safe" commencement of data transmission as described in Section 1.
+   That is, there is a physical safety issue that means that the lasers
+   should not be enabled until the cross-connects are correctly in
+   place.
+
+   GMPLS supports unidirectional and bidirectional LSPs.  These are
+   split into separate sections for discussion.  The processing rules
+   are inherited from [RFC3209] unless they are specifically modified by
+   [RFC3471] and [RFC3473].
+
+3.1.  Unidirectional LSPs
+
+   Unidirectional LSP processing would be the same as that described in
+   Section 2 except for the use of the Suggested_Label object defined in
+   [RFC3473].  This object allows an upstream LSR to 'suggest' to its
+   downstream neighbor the label that should be used for forward-
+   direction data by including the object on a Path message.  The
+   purpose of this object is to help the downstream LSR in its choice of
+   label, but it also makes it possible for the upstream LSR to
+   'pipeline' programming its cross-connect with the RSVP-TE signaling
+   exchanges.  That means that the cross-connect might be in place
+   before the signaling has completed (i.e., before a Resv message
+   carrying a Label object has been received at the upstream LSR).
+
+
+
+
+
+
+
+Shiomoto & Farrel             Informational                     [Page 5]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+   We need to know when it is safe to start sending data.  There are
+   three sources of information.
+
+   -  Section 3.4 of [RFC3471] states:
+
+      In particular, an ingress node should not transmit data traffic on
+      a suggested label until the downstream node passes a label
+      upstream.
+
+   The implication here is that an ingress node may (safely) start to
+   transmit data when it receives a label in a Resv message.
+
+   -  Section 2.5 of [RFC3473] states:
+
+      Furthermore, an ingress node SHOULD NOT transmit data traffic
+      using a suggested label until the downstream node passes a
+      corresponding label upstream.
+
+   This is a confirmation of the first source.
+
+   -  Section 4.1.1.1 of [RFC3209] states:
+
+      The node then sends the new LABEL object as part of the Resv
+      message to the previous hop.  The node SHOULD be prepared to
+      forward packets carrying the assigned label prior to sending the
+      Resv message.
+
+   In this text, the word "prior" is very important.  It means that the
+   cross-connect must be in place for forward traffic before the Resv is
+   sent.  In other words, each of the transit nodes and the egress node
+   must finish making their cross-connects before they send the Resv
+   message to their upstream neighbors.
+
+   Thus, as in Section 2, we can deduce that the ingress must not start
+   to transmit traffic until it has both received a Resv and has
+   programmed its own cross-connect.
+
+3.2.  Bidirectional LSPs
+
+   A bidirectional LSP is established with one signaling exchange of a
+   Path message from ingress to egress, and a Resv from egress to
+   ingress.  The LSP itself is comprised of two sets of forwarding
+   state, one providing a path from the ingress to the egress (the
+   forwards data path), and one from the egress to the ingress (the
+   reverse data path).
+
+
+
+
+
+
+Shiomoto & Farrel             Informational                     [Page 6]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+3.2.1.  Forwards Direction Data
+
+   The processing for the forwards direction data path is exactly as
+   described for a unidirectional LSP in Section 3.1.
+
+3.2.2.  Reverse Direction Data
+
+   For the reverse direction data flow, an Upstream_Label object is
+   carried in the Path message from each LSR to its downstream neighbor.
+   The Upstream_Label object tells the downstream LSR which label to use
+   for data being sent to the upstream LSR (that is, reverse direction
+   data).  The use of the label is confirmed by the downstream LSR when
+   it sends a Resv message.  Note that there is no explicit confirmation
+   of the label in the Resv message, but if the label was not acceptable
+   to the downstream LSR, it would return a PathErr message instead.
+
+   The upstream LSR must decide when to send the Path message relative
+   to when it programs its cross-connect.  That is:
+
+   -  Should it program the cross-connect before it sends the Path
+      message;
+
+   -  Can it overlap the programming with the exchange of messages; or
+
+   -  Must it wait until it receives a Resv from its downstream
+      neighbor?
+
+   The defining reference is Section 3.1 of [RFC3473]:
+
+      The Upstream_Label object MUST indicate a label that is valid for
+      forwarding at the time the Path message is sent.
+
+   In this text, "valid for forwarding" should be taken to mean that it
+   is safe for the LSR that sends the Path message to receive data, and
+   that the LSR will forward data correctly.  The text does not mean
+   that the label is "acceptable for use" (i.e., the label is available
+   to be cross-connected).
+
+   This point is clarified later in Section 3.1 of [RFC3473]:
+
+      Terminator nodes process Path messages as usual, with the
+      exception that the upstream label can immediately be used to
+      transport data traffic associated with the LSP upstream towards
+      the initiator.
+
+   This is a clear statement that when a Path message has been fully
+   processed by an egress node, it is completely safe to transmit data
+   toward the ingress (i.e., reverse direction data).
+
+
+
+Shiomoto & Farrel             Informational                     [Page 7]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+   From this we can deduce several things:
+
+   -  An LSR must not wait to receive a Resv message before it programs
+      the cross-connect for the reverse direction data.  It must be
+      ready to receive data from the moment that the egress completes
+      processing the Path message that it receives (i.e., before it
+      sends a Resv back upstream).
+
+   -  An LSR may expect to start receiving reverse direction data as
+      soon as it sends a Path message for a bidirectional LSP.
+
+   -  An LSR may make some assumptions about the time lag between
+      sending a Path message and the message reaching and being
+      processed by the egress.  It may take advantage of this time lag
+      to pipeline programming the cross-connect.
+
+3.3.  ResvConf Message
+
+   The ResvConf message is used in standard RSVP [RFC2205] to let the
+   ingress confirm to the egress that the Resv has been successfully
+   received, and what bandwidth has been reserved.  In RSVP-TE [RFC3209]
+   and GMPLS [RFC3473], it is not expected that bandwidth will be
+   modified along the path of the LSP, so the purpose of the ResvConf is
+   reduced to a confirmation that the LSP has been successfully
+   established.
+
+   The egress may request that a ResvConf be sent by including a
+   Resv_Confirm object in the Resv message that it sends.  When the
+   ingress receives the Resv message and sees the Resv_Confirm object,
+   it can respond with a ResvConf message.
+
+   It should be clear that this mechanism might provide a doubly secure
+   way for the egress to ensure that the reverse direction data path is
+   safely in place before transmitting data.  That is, if the egress
+   waits until it receives a ResvConf message, it can be sure that the
+   whole LSP is in place.
+
+   However, this mechanism is excessive given the definitions presented
+   in Section 3.2.2, and would delay LSP setup by one end-to-end message
+   propagation cycle.  It should be noted as well that the generation
+   and of the ResvConf message is not guaranteed.  Furthermore, many (if
+   not most) GMPLS implementations neither request nor send ResvConf
+   messages.  Therefore, egress reliance  on the receipt of a ResvConf
+   as a way of knowing that it is safe to start transmitting reverse
+   direction data is not recommended.
+
+
+
+
+
+
+Shiomoto & Farrel             Informational                     [Page 8]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+3.4.  Administrative Status
+
+   GMPLS offers an additional tool for ensuring safety of the LSP.  The
+   Administrative Status information is defined in Section 8 of
+   [RFC3471] and is carried in the Admin_Status Object defined in
+   Section 7 of [RFC3473].
+
+   This object allows an ingress to set up an LSP in "Administratively
+   Down" state.  This state means that [RFC3471]:
+
+      ... the local actions related to the "administratively down" state
+      should be taken.
+
+   In this state, it is assumed that the LSP exists (i.e., the cross-
+   connects are all in place), but no data is transmitted (i.e., in
+   optical systems, the lasers are off).
+
+   Additionally, the Admin_Status object allows the LSP to be put into
+   "Testing" state.  This state means ([RFC3471]) that:
+
+      ... the local actions related to the "testing" mode should be
+      taken.
+
+   This state allows the connectivity of the LSP to be tested without
+   actually exchanging user data.  For example, in an optical system, it
+   would be possible to run a data continuity test (using some external
+   coordination of errors).  In a packet network, a connection
+   verification exchange (such as the in-band Virtual Circuit
+   Connectivity Verification described in Section 5.1.1 of [RFC5085])
+   could be used.  Once connectivity has been verified, the LSP could be
+   put into active mode and the exchange of user data could commence.
+
+   These processes may be considered particularly important in systems
+   where the control-plane processors are physically distinct from the
+   data-plane cross-connects (for example, where there is a
+   communication protocol operating between the control-plane processor
+   and the data-plane switch) in which case the successful completion of
+   control-plane signaling cannot necessarily be taken as evidence of
+   correct data-plane programming.
+
+4.  Implications for Performance Metrics
+
+   The ability of LSRs to handle and propagate control-plane messages
+   and to program cross-connects varies considerably from device to
+   device according to switching technology, control-plane connectivity,
+   and implementation.  These factors influence how quickly an LSP can
+   be established.
+
+
+
+
+Shiomoto & Farrel             Informational                     [Page 9]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+   Different applications have different requirements for the speed of
+   setup of LSPs, and this may be particularly important in recovery
+   scenarios.  It is important for service providers considering the
+   deployment of MPLS-TE or GMPLS equipment to have a good benchmark for
+   the performance of the equipment.  Similarly, it is important for
+   equipment vendors to be compared on a level playing field.
+
+   In order to provide a basis for comparison, [RFC5814] defines a
+   series of performance metrics to evaluate dynamic LSP provisioning
+   performance in MPLS-TE/GMPLS networks.  Any use of such metrics must
+   be careful to understand what is being measured, bearing in mind that
+   it is not enough to know that the control-plane message has been
+   processed and forwarded: the cross-connect must be put in place
+   before the LSP can be used.  Thus, care must be taken to ensure that
+   devices are correctly conforming to the procedures clarified in
+   Section 2 of this document, and not simply forwarding control-plane
+   messages with the intent to program the cross-connects in the
+   background.
+
+5.  Security Considerations
+
+   This document does not define any network behavior and does not
+   introduce or seek to solve any security issues.
+
+   It may be noted that a clear understanding of when to start sending
+   data may reduce the risk of data being accidentally delivered to the
+   wrong place or individuals being hurt.
+
+6.  Acknowledgments
+
+   Thanks to Weiqiang Sun, Olufemi Komolafe, Daniel King, and Stewart
+   Bryant for their review and comments.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+             Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+             Functional Specification", RFC 2205, September 1997.
+
+   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+             Tunnels", RFC 3209, December 2001.
+
+
+
+
+Shiomoto & Farrel             Informational                    [Page 10]
+
+RFC 6383            RVSP-TE Data Label Switch Update      September 2011
+
+
+   [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
+             Switching (GMPLS) Signaling Functional Description", RFC
+             3471, January 2003.
+
+   [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
+             Switching (GMPLS) Signaling Resource ReserVation Protocol-
+             Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+             January 2003.
+
+   [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
+             Switching (GMPLS) Architecture", RFC 3945, October 2004.
+
+7.2.  Informative References
+
+   [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+             Label Switching Architecture", RFC 3031, January 2001.
+
+   [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
+             Label Switching (MPLS) Management Overview", RFC 4221,
+             November 2005.
+
+   [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
+             Circuit Connectivity Verification (VCCV): A Control Channel
+             for Pseudowires", RFC 5085, December 2007.
+
+   [RFC5814] Sun, W., Ed., and G. Zhang, Ed., "Label Switched Path (LSP)
+             Dynamic Provisioning Performance Metrics in Generalized
+             MPLS Networks", RFC 5814, March 2010.
+
+Authors' Addresses
+
+   Kohei Shiomoto
+   NTT Service Integration Laboratories
+   3-9-11 Midori
+   Musashino, Tokyo 180-8585
+   Japan
+   Phone: +81 422 59 4402
+   EMail: shiomoto.kohei@lab.ntt.co.jp
+
+   Adrian Farrel
+   Old Dog Consulting
+   EMail: adrian@olddog.co.uk
+
+
+
+
+
+
+
+
+
+Shiomoto & Farrel             Informational                    [Page 11]
+