rfc3036.txt

RFC 的详细文档！

      2. The next hop router for the FEC is outside of the Label
         Switching Network.

      3. FEC elements are reachable by crossing a routing domain
         boundary, such as another area for OSPF summary networks, or
         another autonomous system for OSPF AS externals and BGP routes
         [RFC2328] [RFC1771].

   Note that whether an LSR is an egress for a given FEC may change over
   time, depending on the state of the network and LSR configuration
   settings.

2.6.2. Label Retention Mode

   The MPLS architecture [RFC3031] introduces the notion of label
   retention mode which specifies whether an LSR maintains a label
   binding for a FEC learned from a neighbor that is not its next hop
   for the FEC.

2.6.2.1. Conservative Label Retention Mode

   In Downstream Unsolicited advertisement mode, label mapping
   advertisements for all routes may be received from all peer LSRs.
   When using conservative label retention, advertised label mappings
   are retained only if they will be used to forward packets (i.e., if
   they are received from a valid next hop according to routing).  If
   operating in Downstream on Demand mode, an LSR will request label
   mappings only from the next hop LSR according to routing.  Since
   Downstream on Demand mode is primarily used when label conservation
   is desired (e.g., an ATM switch with limited cross connect space), it
   is typically used with the conservative label retention mode.

   The main advantage of the conservative mode is that only the labels
   that are required for the forwarding of data are allocated and
   maintained.  This is particularly important in LSRs where the label
   space is inherently limited, such as in an ATM switch.  A
   disadvantage of the conservative mode is that if routing changes the
   next hop for a given destination, a new label must be obtained from
   the new next hop before labeled packets can be forwarded.

2.6.2.2. Liberal Label Retention Mode

   In Downstream Unsolicited advertisement mode, label mapping
   advertisements for all routes may be received from all LDP peers.
   When using liberal label retention, every label mappings received



Andersson, et al.           Standards Track                    [Page 22]

RFC 3036                   LDP Specification                January 2001


   from a peer LSR is retained regardless of whether the LSR is the next
   hop for the advertised mapping.  When operating in Downstream on
   Demand mode with liberal label retention, an LSR might choose to
   request label mappings for all known prefixes from all peer LSRs.
   Note, however, that Downstream on Demand mode is typically used by
   devices such as ATM switch-based LSRs for which the conservative
   approach is recommended.

   The main advantage of the liberal label retention mode is that
   reaction to routing changes can be quick because labels already
   exist.  The main disadvantage of the liberal mode is that unneeded
   label mappings are distributed and maintained.

2.6.3. Label Advertisement Mode

   Each interface on an LSR is configured to operate in either
   Downstream Unsolicited or Downstream on Demand advertisement mode.
   LSRs exchange advertisement modes during initialization.  The major
   difference between Downstream Unsolicited and Downstream on Demand
   modes is in which LSR takes responsibility for initiating mapping
   requests and mapping advertisements.

2.7. LDP Identifiers and Next Hop Addresses

   An LSR maintains learned labels in a Label Information Base (LIB).
   When operating in Downstream Unsolicited mode, the LIB entry for an
   address prefix associates a collection of (LDP Identifier, label)
   pairs with the prefix, one such pair for each peer advertising a
   label for the prefix.

   When the next hop for a prefix changes the LSR must retrieve the
   label advertised by the new next hop from the LIB for use in
   forwarding.  To retrieve the label the LSR must be able to map the
   next hop address for the prefix to an LDP Identifier.

   Similarly, when the LSR learns a label for a prefix from an LDP peer,
   it must be able to determine whether that peer is currently a next
   hop for the prefix to determine whether it needs to start using the
   newly learned label when forwarding packets that match the prefix.
   To make that decision the LSR must be able to map an LDP Identifier
   to the peer's addresses to check whether any are a next hop for the
   prefix.

   To enable LSRs to map between a peer LDP identifier and the peer's
   addresses, LSRs advertise their addresses using LDP Address and
   Withdraw Address messages.





Andersson, et al.           Standards Track                    [Page 23]

RFC 3036                   LDP Specification                January 2001


   An LSR sends an Address message to advertise its addresses to a peer.
   An LSR sends a Withdraw Address message to withdraw previously
   advertised addresses from a peer

2.8. Loop Detection

   Loop detection is a configurable option which provides a mechanism
   for finding looping LSPs and for preventing Label Request messages
   from looping in the presence of non-merge capable LSRs.

   The mechanism makes use of Path Vector and Hop Count TLVs carried by
   Label Request and Label Mapping messages.  It builds on the following
   basic properties of these TLVs:

      -  A Path Vector TLV contains a list of the LSRs that its
         containing message has traversed.  An LSR is identified in a
         Path Vector list by its unique LSR Identifier (Id), which is
         the first four octets of its LDP Identifier.  When an LSR
         propagates a message containing a Path Vector TLV it adds its
         LSR Id to the Path Vector list.  An LSR that receives a message
         with a Path Vector that contains its LSR Id detects that the
         message has traversed a loop.  LDP supports the notion of a
         maximum allowable Path Vector length; an LSR that detects a
         Path Vector has reached the maximum length behaves as if the
         containing message has traversed a loop.

      -  A Hop Count TLV contains a count of the LSRS that the
         containing message has traversed.  When an LSR propagates a
         message containing a Hop Count TLV it increments the count.  An
         LSR that detects a Hop Count has reached a configured maximum
         value behaves as if the containing message has traversed a
         loop.  By convention a count of 0 is interpreted to mean the
         hop count is unknown.  Incrementing an unknown hop count value
         results in an unknown hop count value (0).

   The following paragraphs describes LDP loop detection procedures.
   For these paragraphs, and only these paragraphs, "MUST" is redefined
   to mean "MUST if configured for loop detection".  The paragraphs
   specify messages that must carry Path Vector and Hop Count TLVs.
   Note that the Hop Count TLV and its procedures are used without the
   Path Vector TLV in situations when loop detection is not configured
   (see [RFC3035] and [RFC3034]).

2.8.1. Label Request Message

   The use of the Path Vector TLV and Hop Count TLV prevent Label
   Request messages from looping in environments that include non-merge
   capable LSRs.



Andersson, et al.           Standards Track                    [Page 24]

RFC 3036                   LDP Specification                January 2001


   The rules that govern use of the Hop Count TLV in Label Request
   messages by LSR R when Loop Detection is enabled are the following:

   -  The Label Request message MUST include a Hop Count TLV.

   -  If R is sending the Label Request because it is a FEC ingress, it
      MUST include a Hop Count TLV with hop count value 1.

   -  If R is sending the Label Request as a result of having received a
      Label Request from an upstream LSR, and if the received Label
      Request contains a Hop Count TLV, R MUST increment the received
      hop count value by 1 and MUST pass the resulting value in a Hop
      Count TLV to its next hop along with the Label Request message;

   The rules that govern use of the Path Vector TLV in Label Request
   messages by LSR R when Loop Detection is enabled are the following:

   -  If R is sending the Label Request because it is a FEC ingress,
      then if R is non-merge capable, it MUST include a Path Vector TLV
      of length 1 containing its own LSR Id.

   -  If R is sending the Label Request as a result of having received a
      Label Request from an upstream LSR, then if the received Label
      Request contains a Path Vector TLV or if R is non-merge capable:

         R MUST add its own LSR Id to the Path Vector, and MUST pass the
         resulting Path Vector to its next hop along with the Label
         Request message.  If the Label Request contains no Path Vector
         TLV, R MUST include a Path Vector TLV of length 1 containing
         its own LSR Id.

   Note that if R receives a Label Request message for a particular FEC,
   and R has previously sent a Label Request message for that FEC to its
   next hop and has not yet received a reply, and if R intends to merge
   the newly received Label Request with the existing outstanding Label
   Request, then R does not propagate the Label Request to the next hop.

   If R receives a Label Request message from its next hop with a Hop
   Count TLV which exceeds the configured maximum value, or with a Path
   Vector TLV containing its own LSR Id or which exceeds the maximum
   allowable length, then R detects that the Label Request message has
   traveled in a loop.

   When R detects a loop, it MUST send a Loop Detected Notification
   message to the source of the Label Request message and drop the Label
   Request message.





Andersson, et al.           Standards Track                    [Page 25]

RFC 3036                   LDP Specification                January 2001


2.8.2. Label Mapping Message

   The use of the Path Vector TLV and Hop Count TLV in the Label Mapping
   message provide a mechanism to find and terminate looping LSPs.  When
   an LSR receives a Label Mapping message from a next hop, the message
   is propagated upstream as specified below until an ingress LSR is
   reached or a loop is found.

   The rules that govern the use of the Hop Count TLV in Label Mapping
   messages sent by an LSR R when Loop Detection is enabled are the
   following:

   -  R MUST include a Hop Count TLV.

   -  If R is the egress, the hop count value MUST be 1.

   -  If the Label Mapping message is being sent to propagate a Label
      Mapping message received from the next hop to an upstream peer,
      the hop count value MUST be determined as follows:

      o  If R is a member of the edge set of an LSR domain whose LSRs do
         not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame
         Relay LSR domain) and the upstream peer is within that domain,
         R MUST reset the hop count to 1 before propagating the message.

      o  Otherwise, R MUST increment the hop count received from the
         next hop before propagating the message.

   -  If the Label Mapping message is not being sent to propagate a
      Label Mapping message, the hop count value MUST be the result of
      incrementing R's current knowledge of the hop count learned from
      previous Label Mapping messages.  Note that this hop count value
      will be unknown if R has not received a Label Mapping message from
      the next hop.

   Any Label Mapping message MAY contain a Path Vector TLV.  The rules
   that govern the mandatory use of the Path Vector TLV in Label Mapping
   messages sent by LSR R when Loop Detection is enabled are the
   following:

   -  If R is the egress, the Label Mapping message need not include a
      Path Vector TLV.

   -  If R is sending the Label Mapping message to propagate a Label
      Mapping message received from the next hop to an upstream peer,
      then:





Andersson, et al.           Standards Track                    [Page 26]

RFC 3036                   LDP Specification                January 2001


      o  If R is merge capable and if R has not previously sent a Label
         Mapping message to the upstream peer, then it MUST include a
         Path Vector TLV.

      o  If the received message contains an unknown hop count, then R
         MUST include a Path Vector TLV.

      o  If R has previously sent a Label Mapping message to the
         upstream peer, then it MUST include a Path Vector TLV if the
         received message reports an LSP hop count increase, a change in
         hop count from unknown to known, or a change from known to
         unknown.

      If the above rules require R include a Path Vector TLV in the
      Label Mapping message, R computes it as follows:

      o  If the received Label Mapping message included a Path Vector,