rfc3036.txt

最新的RFC

         are directly connected at the link level.

      -  An extended discovery mechanism used to locate LSRs that are
         not directly connected at the link level.





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


2.4.1. Basic Discovery Mechanism

   To engage in LDP Basic Discovery on an interface an LSR periodically
   sends LDP Link Hellos out the interface.  LDP Link Hellos are sent as
   UDP packets addressed to the well-known LDP discovery port for the
   "all routers on this subnet" group multicast address.

   An LDP Link Hello sent by an LSR carries the LDP Identifier for the
   label space the LSR intends to use for the interface and possibly
   additional information.

   Receipt of an LDP Link Hello on an interface identifies a "Hello
   adjacency" with a potential LDP peer reachable at the link level on
   the interface as well as the label space the peer intends to use for
   the interface.

2.4.2. Extended Discovery Mechanism

   LDP sessions between non-directly connected LSRs are supported by LDP
   Extended Discovery.

   To engage in LDP Extended Discovery an LSR periodically sends LDP
   Targeted Hellos to a specific address.  LDP Targeted Hellos are sent
   as UDP packets addressed to the well-known LDP discovery port at the
   specific address.

   An LDP Targeted Hello sent by an LSR carries the LDP Identifier for
   the label space the LSR intends to use and possibly additional
   optional information.

   Extended Discovery differs from Basic Discovery in the following
   ways:

      -  A Targeted Hello is sent to a specific address rather than to
         the "all routers" group multicast address for the outgoing
         interface.

      -  Unlike Basic Discovery, which is symmetric, Extended Discovery
         is asymmetric.

         One LSR initiates Extended Discovery with another targeted LSR,
         and the targeted LSR decides whether to respond to or ignore
         the Targeted Hello.  A targeted LSR that chooses to respond
         does so by periodically sending Targeted Hellos to the
         initiating LSR.






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


   Receipt of an LDP Targeted Hello identifies a "Hello adjacency" with
   a potential LDP peer reachable at the network level and the label
   space the peer intends to use.

2.5. Establishing and Maintaining LDP Sessions

2.5.1. LDP Session Establishment

   The exchange of LDP Discovery Hellos between two LSRs triggers LDP
   session establishment.  Session establishment is a two step process:

            -  Transport connection establishment.
            -  Session initialization

   The following describes establishment of an LDP session between LSRs
   LSR1 and LSR2 from LSR1's point of view.  It assumes the exchange of
   Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b
   for LSR2.

2.5.2. Transport Connection Establishment

   The exchange of Hellos results in the creation of a Hello adjacency
   at LSR1 that serves to bind the link (L) and the label spaces LSR1:a
   and LSR2:b.

      1. If LSR1 does not already have an LDP session for the exchange
         of label spaces LSR1:a and LSR2:b it attempts to open a TCP
         connection for a new LDP session with LSR2.

         LSR1 determines the transport addresses to be used at its end
         (A1) and LSR2's end (A2) of the LDP TCP connection.  Address A1
         is determined as follows:

         a. If LSR1 uses the Transport Address optional object (TLV) in
            Hello's it sends to LSR2 to advertise an address, A1 is the
            address LSR1 advertises via the optional object;

         b. If LSR1 does not use the Transport Address optional object,
            A1 is the source address used in Hellos it sends to LSR2.

         Similarly, address A2 is determined as follows:

         a. If LSR2 uses the Transport Address optional object, A2 is
            the address LSR2 advertises via the optional object;

         b. If LSR2 does not use the Transport Address optional object,
            A2 is the source address in Hellos received from LSR2.




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


      2. LSR1 determines whether it will play the active or passive role
         in session establishment by comparing addresses A1 and A2 as
         unsigned integers.  If A1 > A2, LSR1 plays the active role;
         otherwise it is passive.

         The procedure for comparing A1 and A2 as unsigned integers is:

         -  If A1 and A2 are not in the same address family, they are
            incomparable, and no session can be established.

         -  Let U1 be the abstract unsigned integer obtained by treating
            A1 as a sequence of bytes, where the byte which appears
            earliest in the message is the most significant byte of the
            integer and the byte which appears latest in the message is
            the least significant byte of the integer.

            Let U2 be the abstract unsigned integer obtained from A2 in
            a similar manner.

         -  Compare U1 with U2.  If U1 > U2, then A1 > A2; if U1 < U2,
            then A1 < A2.

      3. If LSR1 is active, it attempts to establish the LDP TCP
         connection by connecting to the well-known LDP port at address
         A2.  If LSR1 is passive, it waits for LSR2 to establish the LDP
         TCP connection to its well-known LDP port.

   Note that when an LSR sends a Hello it selects the transport address
   for its end of the session connection and uses the Hello to advertise
   the address, either explicitly by including it in an optional
   Transport Address TLV or implicitly by omitting the TLV and using it
   as the Hello source address.

   An LSR MUST advertise the same transport address in all Hellos that
   advertise the same label space.  This requirement ensures that two
   LSRs linked by multiple Hello adjacencies using the same label spaces
   play the same connection establishment role for each adjacency.

2.5.3. Session Initialization

   After LSR1 and LSR2 establish a transport connection they negotiate
   session parameters by exchanging LDP Initialization messages.  The
   parameters negotiated include LDP protocol version, label
   distribution method, timer values, VPI/VCI ranges for label
   controlled ATM, DLCI ranges for label controlled Frame Relay, etc.






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


   Successful negotiation completes establishment of an LDP session
   between LSR1 and LSR2 for the advertisement of label spaces LSR1:a
   and LSR2:b.

   The following describes the session initialization from LSR1's point
   of view.

   After the connection is established, if LSR1 is playing the active
   role, it initiates negotiation of session parameters by sending an
   Initialization message to LSR2.  If LSR1 is passive, it waits for
   LSR2 to initiate the parameter negotiation.

   In general when there are multiple links between LSR1 and LSR2 and
   multiple label spaces to be advertised by each, the passive LSR
   cannot know which label space to advertise over a newly established
   TCP connection until it receives the LDP Initialization message on
   the connection.  The Initialization message carries both the LDP
   Identifier for the sender's (active LSR's) label space and the LDP
   Identifier for the receiver's (passive LSR's) label space.

   By waiting for the Initialization message from its peer the passive
   LSR can match the label space to be advertised by the peer (as
   determined from the LDP Identifier in the PDU header for the
   Initialization message) with a Hello adjacency previously created
   when Hellos were exchanged.

      1. When LSR1 plays the passive role:

         a. If LSR1 receives an Initialization message it attempts to
            match the LDP Identifier carried by the message PDU with a
            Hello adjacency.

         b. If there is a matching Hello adjacency, the adjacency
            specifies the local label space for the session.

            Next LSR1 checks whether the session parameters proposed in
            the message are acceptable.  If they are, LSR1 replies with
            an Initialization message of its own to propose the
            parameters it wishes to use and a KeepAlive message to
            signal acceptance of LSR2's parameters.  If the parameters
            are not acceptable, LSR1 responds by sending a Session
            Rejected/Parameters Error Notification message and closing
            the TCP connection.

         c. If LSR1 cannot find a matching Hello adjacency it sends a
            Session Rejected/No Hello Error Notification message and
            closes the TCP connection.




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


         d. If LSR1 receives a KeepAlive in response to its
            Initialization message, the session is operational from
            LSR1's point of view.

         e. If LSR1 receives an Error Notification message, LSR2 has
            rejected its proposed session and LSR1 closes the TCP
            connection.

      2. When LSR1 plays the active role:

         a. If LSR1 receives an Error Notification message, LSR2 has
            rejected its proposed session and LSR1 closes the TCP
            connection.

         b. If LSR1 receives an Initialization message, it checks
            whether the session parameters are acceptable.  If so, it
            replies with a KeepAlive message.  If the session parameters
            are unacceptable, LSR1 sends a Session Rejected/Parameters
            Error Notification message and closes the connection.

         c. If LSR1 receives a KeepAlive message, LSR2 has accepted its
            proposed session parameters.

         d. When LSR1 has received both an acceptable Initialization
            message and a KeepAlive message the session is operational
            from LSR1's point of view.

      It is possible for a pair of incompatibly configured LSRs that
      disagree on session parameters to engage in an endless sequence of
      messages as each NAKs the other's Initialization messages with
      Error Notification messages.

      An LSR must throttle its session setup retry attempts with an
      exponential backoff in situations where Initialization messages
      are being NAK'd.  It is also recommended that an LSR detecting
      such a situation take action to notify an operator.

      The session establishment setup attempt following a NAK'd
      Initialization message must be delayed no less than 15 seconds,
      and subsequent delays must grow to a maximum delay of no less than
      2 minutes.  The specific session establishment action that must be
      delayed is the attempt to open the session transport connection by
      the LSR playing the active role.








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


      The throttled sequence of Initialization NAKs is unlikely to cease
      until operator intervention reconfigures one of the LSRs.  After
      such a configuration action there is no further need to throttle
      subsequent session establishment attempts (until their
      initialization messages are NAK'd).

      Due to the asymmetric nature of session establishment,
      reconfiguration of the passive LSR will go unnoticed by the active
      LSR without some further action.  Section "Hello Message"
      describes an optional mechanism an LSR can use to signal potential