rfc3035.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

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]