rfc3036.txt

最新的RFC

      LDP peers that it has been reconfigured.

2.5.4. Initialization State Machine

   It is convenient to describe LDP session negotiation behavior in
   terms of a state machine.  We define the LDP state machine to have
   five possible states and present the behavior as a state transition
   table and as a state transition diagram.

































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


               Session Initialization State Transition Table

      STATE         EVENT                               NEW STATE

      NON EXISTENT  Session TCP connection established  INITIALIZED
                    established

      INITIALIZED   Transmit Initialization msg         OPENSENT
                          (Active Role)

                    Receive acceptable                  OPENREC
                          Initialization msg
                          (Passive Role )
                      Action: Transmit Initialization
                              msg and KeepAlive msg

                    Receive Any other LDP msg           NON EXISTENT
                      Action: Transmit Error Notification msg
                              (NAK) and close transport connection

      OPENREC       Receive KeepAlive msg               OPERATIONAL

                    Receive Any other LDP msg           NON EXISTENT
                      Action: Transmit Error Notification msg
                              (NAK) and close transport connection

      OPENSENT      Receive acceptable                  OPENREC
                          Initialization msg
                      Action: Transmit KeepAlive msg

                    Receive Any other LDP msg           NON EXISTENT
                      Action: Transmit Error Notification msg
                              (NAK) and close transport connection

      OPERATIONAL   Receive Shutdown msg                NON EXISTENT
                      Action: Transmit Shutdown msg and
                              close transport connection

                    Receive other LDP msgs              OPERATIONAL

                    Timeout                             NON EXISTENT
                      Action: Transmit Shutdown msg and
                              close transport connection








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


               Session Initialization State Transition Diagram

                                 +------------+
                                 |            |
                   +------------>|NON EXISTENT|<--------------------+
                   |             |            |                     |
                   |             +------------+                     |
                   | Session        |    ^                          |
                   |   connection   |    |                          |
                   |   established  |    | Rx any LDP msg except    |
                   |                V    |   Init msg or Timeout    |
                   |            +-----------+                       |
      Rx Any other |            |           |                       |
         msg or    |            |INITIALIZED|                       |
         Timeout / |        +---|           |-+                     |
      Tx NAK msg   |        |   +-----------+ |                     |
                   |        | (Passive Role)  | (Active Role)       |
                   |        | Rx Acceptable   | Tx Init msg         |
                   |        |    Init msg /   |                     |
                   |        | Tx Init msg     |                     |
                   |        |    Tx KeepAlive |                     |
                   |        V    msg          V                     |
                   |   +-------+        +--------+                  |
                   |   |       |        |        |                  |
                   +---|OPENREC|        |OPENSENT|----------------->|
                   +---|       |        |        | Rx Any other msg |
                   |   +-------+        +--------+    or Timeout    |
      Rx KeepAlive |        ^                |     Tx NAK msg       |
         msg       |        |                |                      |
                   |        |                | Rx Acceptable        |
                   |        |                |    Init msg /        |
                   |        +----------------+ Tx KeepAlive msg     |
                   |                                                |
                   |      +-----------+                             |
                   +----->|           |                             |
                          |OPERATIONAL|                             |
                          |           |---------------------------->+
                          +-----------+     Rx Shutdown msg
                   All other  |   ^            or Timeout /
                     LDP msgs |   |         Tx Shutdown msg
                              |   |
                              +---+









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


2.5.5. Maintaining Hello Adjacencies

   An LDP session with a peer has one or more Hello adjacencies.

   An LDP session has multiple Hello adjacencies when a pair of LSRs is
   connected by multiple links that share the same label space; for
   example, multiple PPP links between a pair of routers.  In this
   situation the Hellos an LSR sends on each such link carry the same
   LDP Identifier.

   LDP includes mechanisms to monitor the necessity of an LDP session
   and its Hello adjacencies.

   LDP uses the regular receipt of LDP Discovery Hellos to indicate a
   peer's intent to use the label space identified by the Hello.  An LSR
   maintains a hold timer with each Hello adjacency which it restarts
   when it receives a Hello that matches the adjacency.  If the timer
   expires without receipt of a matching Hello from the peer, LDP
   concludes that the peer no longer wishes to label switch using that
   label space for that link (or target, in the case of Targeted Hellos)
   or that the peer has failed.  The LSR then deletes the Hello
   adjacency.  When the last Hello adjacency for a LDP session is
   deleted, the LSR terminates the LDP session by sending a Notification
   message and closing the transport connection.

2.5.6. Maintaining LDP Sessions

   LDP includes mechanisms to monitor the integrity of the LDP session.

   LDP uses the regular receipt of LDP PDUs on the session transport
   connection to monitor the integrity of the session.  An LSR maintains
   a KeepAlive timer for each peer session which it resets whenever it
   receives an LDP PDU from the session peer.  If the KeepAlive timer
   expires without receipt of an LDP PDU from the peer the LSR concludes
   that the transport connection is bad or that the peer has failed, and
   it terminates the LDP session by closing the transport connection.

   After an LDP session has been established, an LSR must arrange that
   its peer receive an LDP PDU from it at least every KeepAlive time
   period to ensure the peer restarts the session KeepAlive timer.  The
   LSR may send any protocol message to meet this requirement.  In
   circumstances where an LSR has no other information to communicate to
   its peer, it sends a KeepAlive message.

   An LSR may choose to terminate an LDP session with a peer at any
   time.  Should it choose to do so, it informs the peer with a Shutdown
   message.




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


2.6. Label Distribution and Management

   The MPLS architecture [RF3031] allows an LSR to distribute a FEC
   label binding in response to an explicit request from another LSR.
   This is known as Downstream On Demand label distribution.  It also
   allows an LSR to distribute label bindings to LSRs that have not
   explicitly requested them.  [RFC3031] calls this method of label
   distribution Unsolicited Downstream; this document uses the term
   Downstream Unsolicited.

   Both of these label distribution techniques may be used in the same
   network at the same time.  However, for any given LDP session, each
   LSR must be aware of the label distribution method used by its peer
   in order to avoid situations where one peer using Downstream
   Unsolicited label distribution assumes its peer is also.  See Section
   "Downstream on Demand label Advertisement".

2.6.1. Label Distribution Control Mode

   The behavior of the initial setup of LSPs is determined by whether
   the LSR is operating with independent or ordered LSP control.  An LSR
   may support both types of control as a configurable option.

2.6.1.1. Independent Label Distribution Control

   When using independent LSP control, each LSR may advertise label
   mappings to its neighbors at any time it desires.  For example, when
   operating in independent Downstream on Demand mode, an LSR may answer
   requests for label mappings immediately, without waiting for a label
   mapping from the next hop.  When operating in independent Downstream
   Unsolicited mode, an LSR may advertise a label mapping for a FEC to
   its neighbors whenever it is prepared to label-switch that FEC.

   A consequence of using independent mode is that an upstream label can
   be advertised before a downstream label is received.

2.6.1.2. Ordered Label Distribution Control

   When using LSP ordered control, an LSR may initiate the transmission
   of a label mapping only for a FEC for which it has a label mapping
   for the FEC next hop, or for which the LSR is the egress.  For each
   FEC for which the LSR is not the egress and no mapping exists, the
   LSR MUST wait until a label from a downstream LSR is received before
   mapping the FEC and passing corresponding labels to upstream LSRs.
   An LSR may be an egress for some FECs and a non-egress for others.
   An LSR may act as an egress LSR, with respect to a particular FEC,
   under any of the following conditions:




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


      1. The FEC refers to the LSR itself (including one of its directly
         attached interfaces).

      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.