rfc3036.txt

最新的RFC

      3. Advertisement messages, used to create, change, and delete
         label mappings for FECs.

      4. Notification messages, used to provide advisory information and
         to signal error information.

   Discovery messages provide a mechanism whereby LSRs indicate their
   presence in a network by sending a Hello message periodically.  This
   is transmitted as a UDP packet to the LDP port at the `all routers on
   this subnet' group multicast address.  When an LSR chooses to
   establish a session with another LSR learned via the Hello message,
   it uses the LDP initialization procedure over TCP transport.  Upon
   successful completion of the initialization procedure, the two LSRs
   are LDP peers, and may exchange advertisement messages.

   When to request a label or advertise a label mapping to a peer is
   largely a local decision made by an LSR.  In general, the LSR
   requests a label mapping from a neighboring LSR when it needs one,
   and advertises a label mapping to a neighboring LSR when it wishes
   the neighbor to use a label.

   Correct operation of LDP requires reliable and in order delivery of
   messages.  To satisfy these requirements LDP uses the TCP transport
   for session, advertisement and notification messages; i.e., for
   everything but the UDP-based discovery mechanism.








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


1.3. LDP Message Structure

   All LDP messages have a common structure that uses a Type-Length-
   Value (TLV) encoding scheme; see Section "Type-Length-Value"
   encoding.  The Value part of a TLV-encoded object, or TLV for short,
   may itself contain one or more TLVs.

1.4. LDP Error Handling

   LDP errors and other events of interest are signaled to an LDP peer
   by notification messages.

   There are two kinds of LDP notification messages:

      1. Error notifications, used to signal fatal errors.  If an LSR
         receives an error notification from a peer for an LDP session,
         it terminates the LDP session by closing the TCP transport
         connection for the session and discarding all label mappings
         learned via the session.

      2. Advisory notifications, used to pass an LSR information about
         the LDP session or the status of some previous message received
         from the peer.

1.5. LDP Extensibility and Future Compatibility

   Functionality may be added to LDP in the future.  It is likely that
   future functionality will utilize new messages and object types
   (TLVs).  It may be desirable to employ such new messages and TLVs
   within a network using older implementations that do not recognize
   them.  While it is not possible to make every future enhancement
   backwards compatible, some prior planning can ease the introduction
   of new capabilities.  This specification defines rules for handling
   unknown message types and unknown TLVs for this purpose.

1.6. Specification Language

   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 [RFC2119].











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


2. LDP Operation

2.1. FECs

   It is necessary to precisely specify which packets may be mapped to
   each LSP.  This is done by providing a FEC specification for each
   LSP.  The FEC identifies the set of IP packets which may be mapped to
   that LSP.

   Each FEC is specified as a set of one or more FEC elements.  Each FEC
   element identifies a set of packets which may be mapped to the
   corresponding LSP.  When an LSP is shared by multiple FEC elements,
   that LSP is terminated at (or before) the node where the FEC elements
   can no longer share the same path.

   Following are the currently defined types of FEC elements.  New
   element types may be added as needed:

      1. Address Prefix.  This element is an address prefix of any
         length from 0 to a full address, inclusive.

      2. Host Address.  This element is a full host address.

   (We will see below that an Address Prefix FEC element which is a full
   address has a different effect than a Host Address FEC element which
   has the same address.)

   We say that a particular address "matches" a particular address
   prefix if and only if that address begins with that prefix.  We also
   say that a particular packet matches a particular LSP if and only if
   that LSP has an Address Prefix FEC element which matches the packet's
   destination address.  With respect to a particular packet and a
   particular LSP, we refer to any Address Prefix FEC element which
   matches the packet as the "matching prefix".

   The procedure for mapping a particular packet to a particular LSP
   uses the following rules.  Each rule is applied in turn until the
   packet can be mapped to an LSP.

      -  If there is exactly one LSP which has a Host Address FEC
         element that is identical to the packet's destination address,
         then the packet is mapped to that LSP.

      -  If there are multiple LSPs, each containing a Host Address FEC
         element that is identical to the packet's destination address,
         then the packet is mapped to one of those LSPs.  The procedure
         for selecting one of those LSPs is beyond the scope of this
         document.



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


      -  If a packet matches exactly one LSP, the packet is mapped to
         that LSP.

      -  If a packet matches multiple LSPs, it is mapped to the LSP
         whose matching prefix is the longest.  If there is no one LSP
         whose matching prefix is longest, the packet is mapped to one
         from the set of LSPs whose matching prefix is longer than the
         others.  The procedure for selecting one of those LSPs is
         beyond the scope of this document.

      -  If it is known that a packet must traverse a particular egress
         router, and there is an LSP which has an Address Prefix FEC
         element which is an address of that router, then the packet is
         mapped to that LSP.  The procedure for obtaining this knowledge
         is beyond the scope of this document.

   The procedure for determining that a packet must traverse a
   particular egress router is beyond the scope of this document.  (As
   an example, if one is running a link state routing algorithm, it may
   be possible to obtain this information from the link state data base.
   As another example, if one is running BGP, it may be possible to
   obtain this information from the BGP next hop attribute of the
   packet's route.)

   It is worth pointing out a few consequences of these rules:

      -  A packet may be sent on the LSP whose Address Prefix FEC
         element is the address of the packet's egress router ONLY if
         there is no LSP matching the packet's destination address.

      -  A packet may match two LSPs, one with a Host Address FEC
         element and one with an Address Prefix FEC element.  In this
         case, the packet is always assigned to the former.

      -  A packet which does not match a particular Host Address FEC
         element may not be sent on the corresponding LSP, even if the
         Host Address FEC element identifies the packet's egress router.

2.2. Label Spaces, Identifiers, Sessions and Transport

2.2.1. Label Spaces

   The notion of "label space" is useful for discussing the assignment
   and distribution of labels.  There are two types of label spaces:







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


      -  Per interface label space.  Interface-specific incoming labels
         are used for interfaces that use interface resources for
         labels.  An example of such an interface is a label-controlled
         ATM interface that uses VCIs as labels, or a Frame Relay
         interface that uses DLCIs as labels.

         Note that the use of a per interface label space only makes
         sense when the LDP peers are "directly connected" over an
         interface, and the label is only going to be used for traffic
         sent over that interface.

      -  Per platform label space.  Platform-wide incoming labels are
         used for interfaces that can share the same labels.

2.2.2. LDP Identifiers

   An LDP identifier is a six octet quantity used to identify an LSR
   label space.  The first four octets identify the LSR and must be a
   globally unique value, such as a 32-bit router Id assigned to the
   LSR.  The last two octets identify a specific label space within the
   LSR.  The last two octets of LDP Identifiers for platform-wide label
   spaces are always both zero.  This document uses the following print
   representation for LDP Identifiers:

             <LSR Id> : <label space id>

   e.g., lsr171:0, lsr19:2.

   Note that an LSR that manages and advertises multiple label spaces
   uses a different LDP Identifier for each such label space.

   A situation where an LSR would need to advertise more than one label
   space to a peer and hence use more than one LDP Identifier occurs
   when the LSR has two links to the peer and both are ATM (and use per
   interface labels).  Another situation would be where the LSR had two
   links to the peer, one of which is ethernet (and uses per platform
   labels) and the other of which is ATM.

2.2.3. LDP Sessions

   LDP sessions exist between LSRs to support label exchange between
   them.

      When an LSR uses LDP to advertise more than one label space to
      another LSR it uses a separate LDP session for each label space.






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


2.2.4. LDP Transport

   LDP uses TCP as a reliable transport for sessions.

      When multiple LDP sessions are required between two LSRs there is
      one TCP session for each LDP session.

2.3. LDP Sessions between non-Directly Connected LSRs

   LDP sessions between LSRs that are not directly connected at the link
   level may be desirable in some situations.

   For example, consider a "traffic engineering" application where LSRa
   sends traffic matching some criteria via an LSP to non-directly
   connected LSRb rather than forwarding the traffic along its normally
   routed path.

   The path between LSRa and LSRb would include one or more intermediate
   LSRs (LSR1,...LSRn).  An LDP session between LSRa and LSRb would
   enable LSRb to label switch traffic arriving on the LSP from LSRa by
   providing LSRb means to advertise labels for this purpose to LSRa.

   In this situation LSRa would apply two labels to traffic it forwards
   on the LSP to LSRb: a label learned from LSR1 to forward traffic
   along the LSP path from LSRa to LSRb; and a label learned from LSRb
   to enable LSRb to label switch traffic arriving on the LSP.

   LSRa first adds the label learned via its LDP session with LSRb to
   the packet label stack (either by replacing the label on top of the
   packet label stack with it if the packet arrives labeled or by
   pushing it if the packet arrives unlabeled).  Next, it pushes the
   label for the LSP learned from LSR1 onto the label stack.

2.4. LDP Discovery

   LDP discovery is a mechanism that enables an LSR to discover
   potential LDP peers.  Discovery makes it unnecessary to explicitly
   configure an LSR's label switching peers.

   There are two variants of the discovery mechanism:

      -  A basic discovery mechanism used to discover LSR neighbors that