rfc3035.txt

最新的RFC


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]