doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc3035.txt b/doc/rfc/rfc3035.txt
new file mode 100644
index 0000000..2fabf24
--- /dev/null
+++ b/doc/rfc/rfc3035.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                           B. Davie
+Request for Comments: 3035                                   J. Lawrence
+Category: Standards Track                                  K. McCloghrie
+                                                                E. Rosen
+                                                              G. Swallow
+                                                     Cisco Systems, Inc.
+                                                              Y. Rekhter
+                                                        Juniper Networks
+                                                               P. Doolan
+                                                 Ennovate Networks, Inc.
+                                                            January 2001
+
+
+                  MPLS using LDP and ATM VC Switching
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a
+   way in which Asynchronous Transfer Mode (ATM) switches may be used as
+   Label Switching Routers.  The ATM switches run network layer routing
+   algorithms (such as Open Shortest Path First (OSPF), Intermediate
+   System to Intermediate System (IS-IS), etc.), and their data
+   forwarding is based on the results of these routing algorithms.  No
+   ATM-specific routing or addressing is needed.  ATM switches used in
+   this way are known as ATM-LSRs (Label Switching Routers).
+
+   This document extends and clarifies the relevant portions of [1] and
+   [2] by specifying in more detail the procedures which to be used when
+   distributing labels to or from ATM-LSRs, when those labels represent
+   Forwarding Equivalence Classes (FECs, see [1]) for which the routes
+   are determined on a hop-by-hop basis by network layer routing
+   algorithms.
+
+   This document also specifies the MPLS encapsulation to be used when
+   sending labeled packets to or from ATM-LSRs, and in that respect is a
+   companion document to [3].
+
+
+
+Davie                       Standards Track                     [Page 1]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+Table of Contents
+
+    1      Introduction  ...........................................   2
+    2      Specification of Requirements  ..........................   3
+    3      Definitions  ............................................   3
+    4      Special Characteristics of ATM Switches  ................   4
+    5      Label Switching Control Component for ATM  ..............   5
+    6      Hybrid Switches (Ships in the Night)  ...................   5
+    7      Use of  VPI/VCIs  .......................................   5
+    7.1    Direct Connections  .....................................   6
+    7.2    Connections via an ATM VP  ..............................   7
+    7.3    Connections via an ATM SVC  .............................   7
+    8      Label Distribution and Maintenance Procedures  ..........   7
+    8.1    Edge LSR Behavior  ......................................   8
+    8.2    Conventional ATM Switches (non-VC-merge)  ...............   9
+    8.3    VC-merge-capable ATM Switches  ..........................  11
+    9      Encapsulation  ..........................................  12
+   10      TTL Manipulation  .......................................  13
+   11      Optional Loop Detection: Distributing Path Vectors  .....  15
+   11.1    When to Send Path Vectors Downstream  ...................  15
+   11.2    When to Send Path Vectors Upstream  .....................  16
+   12      Security Considerations  ................................  17
+   13      Intellectual Property Considerations  ...................  17
+   14      References  .............................................  18
+   15      Acknowledgments  ........................................  18
+   16      Authors' Addresses  .....................................  18
+   17      Full Copyright Statement  ...............................  20
+
+1. Introduction
+
+   The MPLS Architecture [1] discusses the way in which ATM switches may
+   be used as Label Switching Routers.  The ATM switches run network
+   layer routing algorithms (such as OSPF, IS-IS, etc.), and their data
+   forwarding is based on the results of these routing algorithms. No
+   ATM-specific routing or addressing is needed.  ATM switches used in
+   this way are known as ATM-LSRs.
+
+   This document extends and clarifies the relevant portions of [1] and
+   [2] by specifying in more detail the procedures which are to be used
+   for distributing labels to or from ATM-LSRs, when those labels
+   represent Forwarding Equivalence Classes (FECs, see [1]) for which
+   the routes are determined on a hop-by-hop basis by network layer
+   routing algorithms.  The label distribution technique described here
+   is referred to in [1] as "downstream-on-demand".  This label
+   distribution technique MUST be used by ATM-LSRs that are not capable
+   of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs
+   that are capable of VC merge.
+
+
+
+
+Davie                       Standards Track                     [Page 2]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   This document does NOT specify the label distribution techniques to
+   be used in the following cases:
+
+      -  the routes are explicitly chosen before label distribution
+         begins, instead of being chosen on a hop-by-hop basis as label
+         distribution proceeds,
+
+      -  the routes are intended to diverge in any way from the routes
+         chosen by the conventional hop-by-hop routing at any time,
+
+      -  the labels represent FECs that consist of multicast packets,
+
+      -  the LSRs use "VP merge".
+
+   Further statements made in this document about ATM-LSR label
+   distribution do not necessarily apply in these cases.
+
+   This document also specifies the MPLS encapsulation to be used when
+   sending labeled packets to or from ATM-LSRs, and in that respect is a
+   companion document to [3].  The specified encapsulation is to be used
+   for multicast or explicitly routed labeled packets as well.
+
+   This document uses terminology from [1].
+
+2. Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+3. Definitions
+
+   A Label Switching Router (LSR) is a device which implements the label
+   switching control and forwarding components described in [1].
+
+   A label switching controlled ATM (LC-ATM) interface is an ATM
+   interface controlled by the label switching control component.  When
+   a packet traversing such an interface is received, it is treated as a
+   labeled packet.  The packet's top label is inferred either from the
+   contents of the VCI field or the combined contents of the VPI and VCI
+   fields.  Any two LDP peers which are connected via an LC-ATM
+   interface will use LDP negotiations to determine which of these cases
+   is applicable to that interface.
+
+   An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards
+   cells between these interfaces, using labels carried in the VCI or
+   VPI/VCI field, without reassembling the cells into frames before
+   forwarding.
+
+
+
+Davie                       Standards Track                     [Page 3]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   A frame-based LSR is a LSR which forwards complete frames between its
+   interfaces.  Note that such a LSR may have zero, one or more LC-ATM
+   interfaces.
+
+   Sometimes a single box may behave as an ATM-LSR with respect to
+   certain pairs of interfaces, but may behave as a frame-based LSR with
+   respect to other pairs.  For example, an ATM switch with an ethernet
+   interface may function as an ATM-LSR when forwarding cells between
+   its LC-ATM interfaces, but may function as a frame-based LSR when
+   forwarding frames from its ethernet to one of its LC-ATM interfaces.
+   In such cases, one can consider the two functions (ATM-LSR and
+   frame-based LSR) as being coresident in a single box.
+
+   It is intended that an LC-ATM interface be used to connect two ATM-
+   LSRs, or to connect an ATM-LSR to a frame-based LSR.  The use of an
+   LC-ATM interface to connect two frame-based LSRs is not considered in
+   this document.
+
+   An ATM-LSR domain is a set of ATM-LSRs which are mutually
+   interconnected by LC-ATM interfaces.
+
+   The Edge Set of an ATM-LSR domain is the set of frame-based LSRs
+   which are connected to members of the domain by LC-ATM interfaces.  A
+   frame-based LSR which is a member of an Edge Set of an ATM-LSR domain
+   may be called an Edge LSR.
+
+   VC-merge is the process by which a switch receives cells on several
+   incoming VCIs and transmits them on a single outgoing VCI without
+   causing the cells of different AAL5 PDUs to become interleaved.
+
+4. Special Characteristics of ATM Switches
+
+   While the MPLS architecture permits considerable flexibility in LSR
+   implementation, an ATM-LSR is constrained by the capabilities of the
+   (possibly pre-existing) hardware and the restrictions on such matters
+   as cell format imposed by ATM standards.  Because of these
+   constraints, some special procedures are required for ATM-LSRs.
+
+   Some of the key features of ATM switches that affect their behavior
+   as LSRs are:
+
+      -  the label swapping function is performed on fields (the VCI
+         and/or VPI) in the cell header; this dictates the size and
+         placement of the label(s) in a packet.
+
+      -  multipoint-to-point and multipoint-to-multipoint VCs are
+         generally not supported.  This means that most switches cannot
+         support 'VC-merge' as defined above.
+
+
+
+Davie                       Standards Track                     [Page 4]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+      -  there is generally no capability to perform a 'TTL-decrement'
+         function as is performed on IP headers in routers.
+
+   This document describes ways of applying label switching to ATM
+   switches which work within these constraints.
+
+5. Label Switching Control Component for ATM
+
+   To support label switching an ATM switch MUST implement the control
+   component of label switching.  This consists primarily of label
+   allocation, distribution, and maintenance procedures.  Label binding
+   information is communicated by several mechanisms, notably the Label
+   Distribution Protocol (LDP) [2].  This document imposes certain
+   requirements on the LDP.
+
+   This document considers only the case where the label switching
+   control component uses information learned directly from network
+   layer routing protocols.  It is presupposed that the switch
+   participates as a peer in these protocols (e.g., OSPF, IS-IS).
+
+   In some cases, LSRs make use of other protocols (e.g., RSVP, PIM,
+   BGP) to distribute label bindings.  In these cases, an ATM-LSR would
+   need to participate in these protocols.  However, these are not
+   explicitly considered in this document.
+
+   Support of label switching on an ATM switch does NOT require the
+   switch to support the ATM control component defined by the ITU and
+   ATM Forum (e.g., UNI, PNNI).  An ATM-LSR may OPTIONALLY respond to
+   OAM cells.
+
+6. Hybrid Switches (Ships in the Night)
+
+   The existence of the label switching control component on an ATM
+   switch does not preclude the ability to support the ATM control
+   component defined by the ITU and ATM Forum on the same switch and the
+   same interfaces.  The two control components, label switching and the
+   ITU/ATM Forum defined, would operate independently.
+
+   Definition of how such a device operates is beyond the scope of this
+   document.  However, only a small amount of information needs to be
+   consistent between the two control components, such as the portions
+   of the VPI/VCI space which are available to each component.
+
+7. Use of  VPI/VCIs
+
+   Label switching is accomplished by associating labels with Forwarding
+   Equivalence Classes, and using the label value to forward packets,
+   including determining the value of any replacement label.  See [1]
+
+
+
+Davie                       Standards Track                     [Page 5]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   for further details.  In an ATM-LSR, the label is carried in the
+   VPI/VCI field, or, when two ATM-LSRs are connected via an ATM
+   "Virtual Path", in the VCI field.
+
+   Labeled packets MUST be transmitted using the null encapsulation, as
+   defined in Section 6.1 of RFC 2684 [5].
+
+   In addition, if two LDP peers are connected via an LC-ATM interface,
+   a non-MPLS connection, capable of carrying unlabelled IP packets,
+   MUST be available.  This non-MPLS connection is used to carry LDP
+   packets between the two peers, and MAY also be used (but is not
+   required to be used) for other unlabeled packets (such as OSPF
+   packets, etc.).  The LLC/SNAP encapsulation of RFC 2684 [5] MUST be
+   used on the non-MPLS connection.
+
+   It SHOULD be possible to configure an LC-ATM interface with
+   additional VPI/VCIs that are used to carry control information or
+   non-labelled packets.  In that case, the VCI values MUST NOT be in
+   the 0-32 range.  These may use either the null encapsulation, as
+   defined in Section 6.1 of RFC 2684 [5], or the LLC/SNAP
+   encapsulation, as defined in Section 5.1 of RFC 2684 [5].
+
+7.1. Direct Connections
+
+   We say that two LSRs are "directly connected" over an LC-ATM
+   interface if all cells transmitted out that interface by one LSR will
+   reach the other, and there are no ATM switches between the two LSRs.
+
+   When two LSRs are directly connected via an LC-ATM interface, they
+   jointly control the allocation of VPIs/VCIs on the interface
+   connecting them.  They may agree to use the VPI/VCI field to encode a
+   single label.
+
+   The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI
+   32.  Other values can be configured, as long as both parties are
+   aware of the configured value.
+
+   A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
+   NOT be used as the encoding of a label.
+
+   With the exception of these reserved values, the VPI/VCI values used
+   in the two directions of the link MAY be treated as independent
+   spaces.
+
+   The allowable ranges of VCIs are communicated through LDP.
+
+
+
+
+
+
+Davie                       Standards Track                     [Page 6]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+7.2. Connections via an ATM VP
+
+   Sometimes it can be useful to treat two LSRs as adjacent (in some
+   LSP) across an LC-ATM interface, even though the connection between
+   them is made through an ATM "cloud" via an ATM Virtual Path.  In this
+   case, the VPI field is not available to MPLS, and the label MUST be
+   encoded entirely within the VCI field.
+
+   In this case, the default VCI value of the non-MPLS connection
+   between the LSRs is 32.  Other values can be configured, as long as
+   both parties are aware of the configured value.  The VPI is set to
+   whatever is required to make use of the Virtual Path.
+
+   A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
+   NOT be used as the encoding of a label.
+
+   With the exception of these reserved values, the VPI/VCI values used
+   in the two directions of the link MAY be treated as independent
+   spaces.
+
+   The allowable ranges of VPI/VCIs are communicated through LDP.  If
+   more than one VPI is used for label switching, the allowable range of
+   VCIs may be different for each VPI, and each range is communicated
+   through LDP.
+
+7.3. Connections via an ATM SVC
+
+   Sometimes it may be useful to treat two LSRs as adjacent (in some
+   LSP) across an LC-ATM interface, even though the connection between
+   them is made through an ATM "cloud" via a set of ATM Switched Virtual
+   Circuits.
+
+   The current document does not specify the procedure for handling this
+   case.  Such procedures can be found in [4].  The procedures described
+   in [4] allow a VCID to be assigned to each such VC, and specify how
+   LDP can be used used to bind a VCID to a FEC.  The top label of a
+   received packet would then be inferred (via a one-to-one mapping)
+   from the virtual circuit on which the packet arrived.  There would
+   not be a default VPI or VCI value for the non-MPLS connection.
+
+8. Label Distribution and Maintenance Procedures
+
+   This document discusses the use of "downstream-on-demand" label
+   distribution (see [1]) by ATM-LSRs.  These label distribution
+   procedures MUST be used by ATM-LSRs that do not support VC-merge, and
+   MAY also be used by ATM-LSRs that do support VC-merge.  The
+   procedures differ somewhat in the two cases, however.  We therefore
+   describe the two scenarios in turn.  We begin by describing the
+
+
+
+Davie                       Standards Track                     [Page 7]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   behavior of members of the Edge Set of an ATM-LSR domain; these "Edge
+   LSRs" are not themselves ATM-LSRs, and their behavior is the same
+   whether the domain contains VC-merge capable LSRs or not.
+
+8.1. Edge LSR Behavior
+
+   Consider a member of the Edge Set of an ATM-LSR domain.  Assume that,
+   as a result of its routing calculations, it selects an ATM-LSR as the
+   next hop of a certain FEC, and that the next hop is reachable via a
+   LC-ATM interface.  The Edge LSR uses LDP to request a label binding
+   for that FEC from the next hop.  The hop count field in the request
+   is set to 1 (but see the next paragraph).  Once the Edge LSR receives
+   the label binding information, it may use MPLS forwarding procedures
+   to transmit packets in the specified FEC, using the specified label
+   as an outgoing label.  (Or using the VPI/VCI that corresponds to the
+   specified VCID as the outgoing label, if the VCID technique of [4] is
+   being used.)
+
+   Note: if the Edge LSR's previous hop is using downstream-on-demand
+   label distribution to request a label from the Edge LSR for a
+   particular FEC, and if the Edge LSR is not merging the LSP from that
+   previous hop with any other LSP, and if the request from the previous
+   hop has a hop count of h, then the hop count in the request issued by
+   the Edge LSR should not be set to 1, but rather to h+1.
+
+   The binding received by the edge LSR may contain a hop count, which
+   represents the number of hops a packet will take to cross the ATM-LSR
+   domain when using this label.  If there is a hop count associated
+   with the binding, the ATM-LSR SHOULD adjust a data packet's TTL by
+   this amount before transmitting the packet.  In any event, it MUST
+   adjust a data packet's TTL by at least one before transmitting it.
+   The procedures for doing so (in the case of IP packets) are specified
+   in section 10.  The procedures for encapsulating the packets are
+   specified in section 9.
+
+   When a member of the Edge Set of the ATM-LSR domain receives a label
+   binding request from an ATM-LSR, it allocates a label, and returns
+   (via LDP) a binding containing the allocated label back to the peer
+   that originated the request.  It sets the hop count in the binding to
+   1.
+
+   When a routing calculation causes an Edge LSR to change the next hop
+   for a particular FEC, and the former next hop was in the ATM-LSR
+   domain, the Edge LSR SHOULD notify the former next hop (via LDP) that
+   the label binding associated with the FEC is no longer needed.
+
+
+
+
+
+
+Davie                       Standards Track                     [Page 8]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+8.2. Conventional ATM Switches (non-VC-merge)
+
+   When an ATM-LSR receives (via LDP) a label binding request for a
+   certain FEC from a peer connected to the ATM-LSR over a LC-ATM
+   interface, the ATM-LSR takes the following actions:
+
+      -  it allocates a label,
+
+      -  it requests (via LDP) a label binding from the next hop for
+         that FEC;
+
+      -  it returns (via LDP) a binding containing the allocated
+         incoming label back to the peer that originated the request.
+
+   For purposes of this procedure, we define a maximum hop count value
+   MAXHOP.  MAXHOP has a default value of 255, but may be configured to
+   a different value.
+
+   The hop count field in the request that the ATM-LSR sends (to the
+   next hop LSR) MUST be set to one more than the hop count field in the
+   request that it received from the upstream LSR.  If the resulting hop
+   count exceeds MAXHOP, the request MUST NOT be sent to the next hop,
+   and the ATM-LSR MUST notify the upstream neighbor that its binding
+   request cannot be satisfied.
+
+   Otherwise, once the ATM-LSR receives the binding from the next hop,
+   it begins using that label.
+
+   The ATM-LSR MAY choose to wait for the request to be satisfied from
+   downstream before returning the binding upstream.  This is a form of
+   "ordered control" (as defined in [1] and [2]), in particular
+   "ingress-initiated ordered control".  In this case, as long as the
+   ATM-LSR receives from downstream a hop count which is greater than 0
+   and less than MAXHOP, it MUST increment the hop count it receives
+   from downstream and MUST include the result in the binding it returns
+   upstream.  However, if the hop count exceeds MAXHOP, a label binding
+   MUST NOT be passed upstream.  Rather, the upstream LDP peer MUST be
+   informed that the requested label binding cannot be satisfied.  If
+   the hop count received from downstream is 0, the hop count passed
+   upstream should also be 0; this indicates that the actual hop count
+   is unknown.
+
+   Alternatively, the ATM-LSR MAY return the binding upstream without
+   waiting for a binding from downstream ("independent" control, as
+   defined in [1] and [2]).  In this case, it specifies a hop count of 0
+   in the binding, indicating that the true hop count is unknown.  The
+   correct value for hop count will be returned later, as described
+   below.
+
+
+
+Davie                       Standards Track                     [Page 9]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   Note that an ATM-LSR, or a member of the edge set of an ATM-LSR
+   domain, may receive multiple binding requests for the same FEC from
+   the same ATM-LSR.  It MUST generate a new binding for each request
+   (assuming adequate resources to do so), and retain any existing
+   binding(s).  For each request received, an ATM-LSR MUST also generate
+   a new binding request toward the next hop for the FEC.
+
+   When a routing calculation causes an ATM-LSR to change the next hop
+   for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that
+   the label binding associated with the FEC is no longer needed.
+
+   When a LSR receives a notification that a particular label binding is
+   no longer needed, the LSR MAY deallocate the label associated with
+   the binding, and destroy the binding.  In the case where an ATM-LSR
+   receives such notification and destroys the binding, it MUST notify
+   the next hop for the FEC that the label binding is no longer needed.
+   If a LSR does not destroy the binding, it may re-use the binding only
+   if it receives a request for the same FEC with the same hop count as
+   the request that originally caused the binding to be created.
+
+   When a route changes, the label bindings are re-established from the
+   point where the route diverges from the previous route.   LSRs
+   upstream of that point are (with one exception, noted below)
+   oblivious to the change.
+
+   Whenever a LSR changes its next hop for a particular FEC, if the new
+   next hop is reachable via an LC-ATM interface, then for each label
+   that it has bound to that FEC, and distributed upstream, it MUST
+   request a new label binding from the new next hop.
+
+   When an ATM-LSR receives a label binding for a particular FEC from a
+   downstream neighbor, it may already have provided a corresponding
+   label binding for this FEC to an upstream neighbor, either because it
+   is using independent control, or because the new binding from
+   downstream is the result of a routing change.  In this case, unless
+   the hop count is 0, it MUST extract the hop count from the new
+   binding and increment it by one.  If the new hop count is different
+   from that which was previously conveyed to the upstream neighbor
+   (including the case where the upstream neighbor was given the value
+   'unknown') the ATM-LSR MUST notify the upstream neighbor of the
+   change.  Each ATM-LSR in turn MUST increment the hop count and pass
+   it upstream until it reaches the ingress Edge LSR.  If at any point
+   the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw
+   the binding from the upstream neighbor.  A hop count of 0 MUST be
+   passed upstream unchanged.
+
+
+
+
+
+
+Davie                       Standards Track                    [Page 10]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   Whenever an ATM-LSR originates a label binding request to its next
+   hop LSR as a result of receiving a label binding request from another
+   (upstream) LSR, and the request to the next hop LSR is not satisfied,
+   the ATM-LSR SHOULD destroy the binding created in response to the
+   received request, and notify the requester (via LDP).
+
+   If an ATM-LSR receives a binding request containing a hop count that
+   exceeds MAXHOP, it MUST not establish a binding, and it MUST return
+   an error to the requester.
+
+   When a LSR determines that it has lost its LDP session with another
+   LSR, the following actions are taken.  Any binding information
+   learned via this connection MUST be discarded.  For any label
+   bindings that were created as a result of receiving label binding
+   requests from the peer, the LSR MAY destroy these bindings (and
+   deallocate labels associated with these binding).
+
+   An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding
+   requests from its neighbors.  That is, if it receives a request for a
+   binding to a particular FEC and the LSR making that request is,
+   according to this ATM-LSR, the next hop for that FEC, it should not
+   return a binding for that route.
+
+   It is expected that non-merging ATM-LSRs would generally use
+   "conservative label retention mode" [1].
+
+8.3. VC-merge-capable ATM Switches
+
+   Relatively minor changes are needed to accommodate ATM-LSRs which
+   support VC-merge.  The primary difference is that a VC-merge-capable
+   ATM-LSR needs only one outgoing label per FEC, even if multiple
+   requests for label bindings to that FEC are received from upstream
+   neighbors.
+
+   When a VC-merge-capable ATM-LSR receives a binding request from an
+   upstream LSR for a certain FEC, and it does not already have an
+   outgoing label binding for that FEC (or an outstanding request for
+   such a label binding), it MUST issue a bind request to its next hop
+   just as it would do if it were not merge-capable.  If, however, it
+   already has an outgoing label binding for that FEC, it does not need
+   to issue a downstream binding request.  Instead, it may simply
+   allocate an incoming label, and return that label in a binding to the
+   upstream requester.  When packets with that label as top label are
+   received from the requester, the top label value will be replaced
+   with the existing outgoing label value that corresponds to the same
+   FEC.
+
+
+
+
+
+Davie                       Standards Track                    [Page 11]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   If the ATM-LSR does not have an outgoing label binding for the FEC,
+   but does have an outstanding request for one, it need not issue
+   another request.
+
+   When sending a label binding upstream, the hop count associated with
+   the corresponding binding from downstream MUST be incremented by 1,
+   and the result transmitted upstream as the hop count associated with
+   the new binding.  However, there are two exceptions: a hop count of 0
+   MUST be passed upstream unchanged, and if the hop count is already at
+   MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead
+   MUST send an error upstream.
+
+   Note that, just like conventional ATM-LSRs and members of the edge
+   set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a
+   new binding every time it receives a request from upstream, since
+   there may be switches upstream which do not support VC-merge.
+   However, it only needs to issue a corresponding binding request
+   downstream if it does not already have a label binding for the
+   appropriate route.
+
+   When a change in the routing table of a VC-merge-capable ATM-LSR
+   causes it to select a new next hop for one of its FECs, it MAY
+   optionally release the binding for that route from the former next
+   hop.  If it doesn't already have a corresponding binding for the new
+   next hop, it must request one.  (The choice between conservative and
+   liberal label retention mode [1] is an implementation option.)
+
+   If a new binding is obtained, which contains a hop count that differs
+   from that which was received in the old binding, then the ATM-LSR
+   must take the new hop count, increment it by one, and notify any
+   upstream neighbors who have label bindings for this FEC of the new
+   value.  Just as with conventional ATM-LSRs, this enables the new hop
+   count to propagate back towards the ingress of the ATM-LSR domain.
+   If at any point the hop count exceeds MAXHOP, then the label bindings
+   for this route must be withdrawn from all upstream neighbors to whom
+   a binding was previously provided.  This ensures that any loops
+   caused by routing transients will be detected and broken.
+
+9. Encapsulation
+
+   The procedures described in this section affect only the Edge LSRs of
+   the ATM-LSR domain.  The ATM-LSRs themselves do not modify the
+   encapsulation in any way.
+
+   Labeled packets MUST be transmitted using the null encapsulation of
+   Section 6.1 of RFC 2684 [5].
+
+
+
+
+
+Davie                       Standards Track                    [Page 12]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   Except in certain circumstances specified below, when a labeled
+   packet is transmitted on an LC-ATM interface, where the VPI/VCI (or
+   VCID) is interpreted as the top label in the label stack, the packet
+   MUST also contain a "shim header" [3].
+
+   If the packet has a label stack with n entries, it MUST carry a shim
+   with n entries.  The actual value of the top label is encoded in the
+   VPI/VCI field.  The label value of the top entry in the shim (which
+   is just a "placeholder" entry) MUST be set to 0 upon transmission,
+   and MUST be ignored upon reception.  The packet's outgoing TTL, and
+   its CoS, are carried in the TTL and CoS fields respectively of the
+   top stack entry in the shim.
+
+   Note that if a packet has a label stack with only one entry, this
+   requires it to have a single-entry shim (4 bytes), even though the
+   actual label value is encoded into the VPI/VCI field.  This is done
+   to ensure that the packet always has a shim.  Otherwise, there would
+   be no way to determine whether it had one or not, i.e., no way to
+   determine whether there are additional label stack entries.
+
+   The only ways to eliminate this extra overhead are:
+
+      -  through apriori knowledge that packets have only a single label
+         (e.g., perhaps the network only supports one level of label)
+
+      -  by using two VCs per FEC, one for those packets which have only
+         a single label, and one for those packets which have more than
+         one label
+
+   The second technique would require that there be some way of
+   signalling via LDP that the VC is carrying only packets with a single
+   label, and is not carrying a shim.  When supporting VC merge, one
+   would also have to take care not to merge a VC on which the shim  is
+   not used into a VC on which it is used, or vice versa.
+
+   While either of these techniques is permitted, it is doubtful that
+   they have any practical utility.  Note that if the shim header is not
+   present, the outgoing TTL is carried in the TTL field of the network
+   layer header.
+
+10. TTL Manipulation
+
+   The procedures described in this section affect only the Edge LSRs of
+   the ATM-LSR domain.  The ATM-LSRs themselves do not modify the TTL in
+   any way.
+
+
+
+
+
+
+Davie                       Standards Track                    [Page 13]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   The details of the TTL adjustment procedure are as follows.  If a
+   packet was received by the Edge LSR as an unlabeled packet, the
+   "incoming TTL" comes from the IP header.  (Procedures for other
+   network layer protocols are for further study.) If a packet was
+   received by the Edge LSR as a labeled packet, using the encapsulation
+   specified in [3], the "incoming TTL" comes from the entry at the top
+   of the label stack.
+
+   If a hop count has been associated with the label binding that is
+   used when the packet is forwarded, the "outgoing TTL" is set to the
+   larger of (a) 0 or (b) the difference between the incoming TTL and
+   the hop count.  If a hop count has not been associated with the label
+   binding that is used when the packet is forwarded, the "outgoing TTL"
+   is set to the larger of (a) 0 or (b) one less than the incoming TTL.
+
+   If this causes the outgoing TTL to become zero, the packet MUST NOT
+   be transmitted as a labeled packet using the specified label.  The
+   packet can be treated in one of two ways:
+
+      -  it may be treated as having expired; this may cause an ICMP
+         message to be transmitted;
+
+      -  the packet may be forwarded, as an unlabeled packet, with a TTL
+         that is 1 less than the incoming TTL; such forwarding would
+         need to be done over a non-MPLS connection.
+
+   Of course, if the incoming TTL is 1, only the first of these two
+   options is applicable.
+
+   If the packet is forwarded as a labeled packet, the outgoing TTL is
+   carried as specified in section 9.
+
+   When an Edge LSR receives a labeled packet over an LC-ATM interface,
+   it obtains the incoming TTL from the top label stack entry of the
+   generic encapsulation, or, if that encapsulation is not present, from
+   the IP header.
+
+   If the packet's next hop is an ATM-LSR, the outgoing TTL is formed
+   using the procedures described in this section.  Otherwise the
+   outgoing TTL is formed using the procedures described in [3].
+
+   The procedures in this section are intended to apply only to unicast
+   packets.
+
+
+
+
+
+
+
+
+Davie                       Standards Track                    [Page 14]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+11. Optional Loop Detection: Distributing Path Vectors
+
+   Every ATM-LSR MUST implement, as a configurable option, the following
+   procedure for detecting forwarding loops.  We refer to this as the
+   LDPV (Loop Detection via Path Vectors) procedure.  This procedure
+   does not prevent the formation of forwarding loops, but does ensure
+   that any such loops are detected.  If this option is not enabled,
+   loops are detected by the hop count mechanism previously described.
+   If this option is enabled, loops will be detected more quickly, but
+   at a higher cost in overhead.
+
+11.1. When to Send Path Vectors Downstream
+
+   Suppose an LSR R sends a request for a label binding, for a
+   particular LSP, to its next hop.  Then if R does not support VC-
+   merging, and R is configured to use the LDPV procedure:
+
+      -  If R is sending the request because it is an ingress node for
+         that LSP, or because it has acquired a new next hop, then R
+         MUST include a path vector object with the request, and the
+         path vector object MUST contain only R's own address.
+
+      -  If R is sending the request as a result of having received a
+         request from an upstream LSR, then:
+
+         *  if the received request has a path vector object, R MUST add
+            its own address to the received path vector object, and MUST
+            pass the resulting path vector object to its next hop along
+            with the label binding request;
+
+         *  if the received request does not have a path vector object,
+            R MUST include a path vector object with the request it
+            sends, and the path vector object MUST contain only R's own
+            address.
+
+   An LSR which supports VC-merge SHOULD NOT include a path vector
+   object in the requests that it sends to its next hop.
+
+   If an LSR receives a label binding request whose path vector object
+   contains the address of the node itself, the LSR concludes that the
+   label binding requests have traveled in a loop.  The LSR MUST act as
+   it would in the case where the hop count exceeds MAXHOP (see section
+   8.2).
+
+   This procedure detects the case where the request messages loop
+   though a sequence of non-merging ATM-LSRs.
+
+
+
+
+
+Davie                       Standards Track                    [Page 15]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+11.2. When to Send Path Vectors Upstream
+
+   As specified in section 8, there are circumstances in which an LSR R
+   must inform its upstream neighbors, via a label binding response
+   message, of a change in hop count for a particular LSP.  If the
+   following conditions all hold:
+
+      -  R is configured for the LDPV procedure,
+
+      -  R supports VC-merge,
+
+      -  R is not the egress for that LSP, and
+
+      -  R is not informing its neighbors of a decrease in the hop
+         count,
+
+   then R MUST include a path vector object in the response message.
+
+   If the change in hop count is a result of R's having been informed by
+   its next hop, S, of a change in hop count, and the message from S to
+   R included a path vector object, then if the above conditions hold, R
+   MUST add itself to this object and pass the result upstream.
+   Otherwise, if the above conditions hold, R MUST create a new object
+   with only its own address.
+
+   If R is configured for the LDPV procedure, and R supports VC merge,
+   then it MAY include a path vector object in any label binding
+   response message that it sends upstream.  In particular, at any time
+   that R receives a label binding response from its next hop, if that
+   response contains a path vector, R MAY (if configured for the LDPV
+   procedure) send a response to its upstream neighbors, containing the
+   path vector object formed by adding its own address to the received
+   path vector.
+
+   If R does not support VC merge, it SHOULD NOT send a path vector
+   object upstream.
+
+   If an LSR  receives a message from  its next hop, with a  path vector
+   object containing its own address, then  LSR  MUST act as it would if
+   it received a message with a hop count equal to MAXHOP.
+
+   LSRs which are configured for the LDPV procedure SHOULD NOT store a
+   path vector once the corresponding path vector object has been
+   transmitted.
+
+
+
+
+
+
+
+Davie                       Standards Track                    [Page 16]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   Note that if the ATM-LSR domain consists entirely of non-merging
+   ATM-LSRs, path vectors need not ever be sent upstream, since any
+   loops will be detected by means of the path vectors traveling
+   downstream.
+
+   By not sending path vectors unless the hop count increases, one
+   avoids sending them in many situations when there is no loop.  The
+   cost is that in some situations in which there is a loop, the time to
+   detect the loop may be lengthened.
+
+12. Security Considerations
+
+   The encapsulation and procedures specified in this document do not
+   interfere in any way with the application of authentication and/or
+   encryption to network layer packets (such as the application of IPSEC
+   to IP datagrams).
+
+   The procedures described in this document do not protect against the
+   alteration (either accidental or malicious) of MPLS labels.  Such
+   alteration could cause misforwarding.
+
+   The procedures described in this document do not enable a receiving
+   LSR to authenticate the transmitting LSR.
+
+   A discussion of the security considerations applicable to the label
+   distribution mechanism can be found in [2].
+
+13. Intellectual Property Considerations
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+
+
+
+Davie                       Standards Track                    [Page 17]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+14. References
+
+   [1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label
+       Switching Architecture", RFC 3031, January 2001.
+
+   [2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas,
+       "LDP Specification", RFC 3036, January 2001.
+
+   [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G.,
+       Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
+       January 2001.
+
+   [4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification
+       over ATM Link for LDP", RFC 3038, January 2001.
+
+   [5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM
+       Adaptation Layer 5", RFC 2684, September 1999.
+
+15. Acknowledgments
+
+   Significant contributions to this work have been made by Anthony
+   Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan
+   Littlewood and Dan Tappan.  We thank Alex Conta for his comments.
+
+16. Authors' Addresses
+
+   Bruce Davie
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA, 01824
+
+   EMail: bsd@cisco.com
+
+
+   Paul Doolan
+   Ennovate Networks Inc.
+   60 Codman Hill Rd
+   Boxborough, MA 01719
+
+   EMail: pdoolan@ennovatenetworks.com
+
+
+
+
+
+Davie                       Standards Track                    [Page 18]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+   Jeremy Lawrence
+   Cisco Systems, Inc.
+   99 Walker St.
+   North Sydney, NSW, Australia
+
+   EMail: jlawrenc@cisco.com
+
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 Tasman Drive
+   San Jose, CA, 95134
+
+   EMail: kzm@cisco.com
+
+
+   Yakov Rekhter
+   Juniper Networks
+   1194 N. Mathilda Avenue
+   Sunnyvale, CA 94089
+
+   EMail: yakov@juniper.net
+
+
+   Eric Rosen
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA, 01824
+
+   EMail: erosen@cisco.com
+
+
+   George Swallow
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA, 01824
+
+   EMail: swallow@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davie                       Standards Track                    [Page 19]
+
+RFC 3035          MPLS using LDP and ATM VC Switching       January 2001
+
+
+17.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davie                       Standards Track                    [Page 20]
+