tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3036

 
 
 

LDP Specification

Part 4 of 4, p. 89 to 132
Prev RFC Part

 


prevText      Top      Up      ToC       Page 89 
6. Areas for Future Study

   The following topics not addressed in this version of LDP are
   possible areas for future study:

      -  Section 2.16 of the MPLS architecture [RFC3031] requires that
         the initial label distribution protocol negotiation between
         peer LSRs enable each LSR to determine whether its peer is
         capable of popping the label stack.  This version of LDP
         assumes that LSRs support label popping for all link types
         except ATM and Frame Relay.  A future version may specify means
         to make this determination part of the session initiation
         negotiation.

      -  LDP support for CoS is not specified in this version.  CoS
         support may be addressed in a future version.

      -  LDP support for multicast is not specified in this version.
         Multicast support may be addressed in a future version.

      -  LDP support for multipath label switching is not specified in
         this version.  Multipath support may be addressed in a future
         version.

7. Intellectual Property Considerations

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

8. Acknowledgments

   The ideas and text in this document have been collected from a number
   of sources.  We would like to thank Rick Boivie, Ross Callon, Alex
   Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
   Rekhter, and Arun Viswanathan.

9. References

   [ATM-VP]    N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T
               Worster, "MPLS using ATM VP Switching", Work in Progress.

   [CRLDP]     L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P.
               Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T.
               E. Kilty, A. G.  Malis, M. Girish, K. Sundell, P.
               Vaananen, T. Worster, L. Wu, R.  Dantu, "Constraint-Based
               LSP Setup using LDP", Work in Progress.

Top      Up      ToC       Page 90 
   [DIFFSERV]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
               and W. Weiss, "An Architecture for Differentiated
               Services", RFC 2475, December 1998.

   [IANA]      Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
               October 1998.

   [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
               April 1992.

   [RFC1483]   Heinanen, J., "Multiprotocol Encapsulation over ATM
               Adaptation Layer 5", RFC 1483, July 1993.

   [RFC2328]   Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC1700]   Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2,
               RFC 1700, October 1994.

   [RFC1771]   Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
               (BGP-4)", RFC 1771, March 1995.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2205]   Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
               Functional Specification", RFC 2205, September 1997.

   [RFC2385]   Heffernan, A., "Protection of BGP Sessions via the TCP
               MD5 Signature Option", RFC 2385, August 1998.

   [RFC2702]   Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
               McManus, "Requirements for Traffic Engineering over
               MPLS", RFC 2702, September 1999.

   [RFC3031]   Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
               Label Switching Architecture", RFC 3031, January 2001.

   [RFC3032]   Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
               Fedorkow, G.,  Li, T. and A. Conta, "MPLS Label Stack
               Encoding", RFC 3032, January 2001.

   [RFC3034]   Conta, A., Doolan, P. and A. Malis, "Use of Label
               Switching on Frame Relay Networks Specification", RFC
               3034, January 2001.

Top      Up      ToC       Page 91 
   [RFC3035]   Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
               Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and
               ATM VC Switching", RFC 3035, January 2001.

   [RFC3037]   Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
               January 2001.

Top      Up      ToC       Page 92 
10. Authors' Addresses

   Loa Andersson
   Nortel Networks Inc
   St Eriksgatan 115, PO Box 6701
   113 85 Stockholm
   Sweden

   Phone: +46 8 5088 36 34
   Mobile: +46 70 522 78 34
   EMail: loa.andersson@nortelnetworks.com


   Paul Doolan
   Ennovate Networks
   60 Codman Hill Rd
   Marlborough MA 01719

   Phone: 978-263-2002
   EMail: pdoolan@ennovatenetworks.com


   Nancy Feldman
   IBM Research
   30 Saw Mill River Road
   Hawthorne, NY 10532

   Phone:  914-784-3254
   EMail: nkf@us.ibm.com


   Andre Fredette
   PhotonEx Corporation
   8C Preston Court
   Bedford, MA 01730

   Phone: 781-301-4655
   EMail: fredette@photonex.com


   Bob Thomas
   Cisco Systems, Inc.
   250 Apollo Dr.
   Chelmsford, MA 01824

   Phone:  978-244-8078
   EMail: rhthomas@cisco.com

Top      Up      ToC       Page 93 
Appendix A. LDP Label Distribution Procedures

   This section specifies label distribution behavior in terms of LSR
   response to the following events:

      -  Receive Label Request Message;
      -  Receive Label Mapping Message;
      -  Receive Label Abort Request Message;
      -  Receive Label Release Message;
      -  Receive Label Withdraw Message;
      -  Recognize new FEC;
      -  Detect change in FEC next hop;
      -  Receive Notification Message / Label Request Aborted;
      -  Receive Notification Message / No Label Resources;
      -  Receive Notification Message / No Route;
      -  Receive Notification Message / Loop Detected;
      -  Receive Notification Message / Label Resources Available;
      -  Detect local label resources have become available;
      -  LSR decides to no longer label switch a FEC;
      -  Timeout of deferred label request.

   The specification of LSR behavior in response to an event has three
   parts:

      1. Summary.  Prose that describes LSR response to the event in
         overview.

      2. Context.  A list of elements referred to by the Algorithm part
         of the specification.  (See 3.)

      3. Algorithm.  An algorithm for LSR response to the event.

   The Summary may omit details of the LSR response, such as bookkeeping
   action or behavior dependent on the LSR label advertisement mode,
   control mode, or label retention mode in use.  The intent is that the
   Algorithm fully and unambiguously specify the LSR response.

   The algorithms in this section use procedures defined in the MPLS
   architecture specification [RFC3031] for hop-by-hop routed traffic.
   These procedures are:

      -  Label Distribution procedure, which is performed by a
         downstream LSR to determine when to distribute a label for a
         FEC to LDP peers.  The architecture defines four Label
         Distribution procedures:

Top      Up      ToC       Page 94 
         .  Downstream Unsolicited Independent Control, called
            PushUnconditional in [RFC3031].

         .  Downstream Unsolicited Ordered Control, called
            PushConditional in [RFC3031].

         .  Downstream On Demand Independent Control, called
            PulledUnconditional in [RFC3031].

         .  Downstream On Demand Ordered Control, called
            PulledConditional in [RFC3031].

      -  Label Withdrawal procedure, which is performed by a downstream
         LSR to determine when to withdraw a FEC label mapping
         previously distributed to LDP peers.  The architecture defines
         a single Label Withdrawal procedure.  Whenever an LSR breaks
         the binding between a label and a FEC, it must withdraw the FEC
         label mapping from all LDP peers to which it has previously
         sent the mapping.

      -  Label Request procedure, which is performed by an upstream LSR
         to determine when to explicitly request that a downstream LSR
         bind a label to a FEC and send it the corresponding label
         mapping.  The architecture defines three Label Request
         procedures:

         .  Request Never.  The LSR never requests a label.

         .  Request When Needed.  The LSR requests a label whenever
            it needs one.

         .  Request On Request.  This procedure is used by
            non-label merging LSRs.  The LSR requests a label
            when it receives a request for one, in addition
            to whenever it needs one.

      -  Label Release procedure, which is performed by an upstream LSR
         to determine when to release a previously received label
         mapping for a FEC.  The architecture defines two Label Release
         procedures:

         .  Conservative label retention, called Release On Change in
            [RFC3031].

         .  Liberal label retention, called No Release On Change in
            [RFC3031].

Top      Up      ToC       Page 95 
      -  Label Use procedure, which is performed by an LSR to determine
         when to start using a FEC label for forwarding/switching.  The
         architecture defines three Label Use procedures:

         .  Use Immediate.  The LSR immediately uses a label received
            from a FEC next hop for forwarding/switching.

         .  Use If Loop Free.  The LSR uses a FEC label received from a
            FEC next hop for forwarding/switching only if it has
            determined that by doing so it will not cause a forwarding
            loop.

         .  Use If Loop Not Detected.  This procedure is the same as Use
            Immediate unless the LSR has detected a loop in the FEC LSP.
            Use of the FEC label for forwarding/switching will continue
            until the next hop for the FEC changes or the loop is no
            longer detected.

         This version of LDP does not include a loop prevention
         mechanism; therefore, the procedures below do not make use of
         the Use If Loop Free procedure.

      -  Label No Route procedure (called Label Not Available procedure
         in [RFC3031]), which is performed by an upstream LSR to
         determine how to respond to a No Route notification from a
         downstream LSR in response to a request for a FEC label
         mapping.  The architecture specification defines two Label No
         Route procedures:

         .  Request Retry.  The LSR should issue the label request at a
            later time.

         .  No Request Retry.  The LSR should assume the downstream LSR
            will provide a label mapping when the downstream LSR has a
            next hop and it should not reissue the request.

A.1. Handling Label Distribution Events

   This section defines LDP label distribution procedures by specifying
   an algorithm for each label distribution event.  The requirement on
   an LDP implementation is that its event handling must have the effect
   specified by the algorithms.  That is, an implementation need not
   follow exactly the steps specified by the algorithms as long as the
   effect is identical.

Top      Up      ToC       Page 96 
   The algorithms for handling label distribution events share common
   actions.  The specifications below package these common actions into
   procedure units.  Specifications for these common procedures are in
   their own section "Common Label Distribution Procedures", which
   follows this.

   An implementation would use data structures to store information
   about protocol activity.  This appendix specifies the information to
   be stored in sufficient detail to describe the algorithms, and
   assumes the ability to retrieve the information as needed.  It does
   not specify the details of the data structures.

A.1.1. Receive Label Request

   Summary:

      The response by an LSR to receipt of a FEC label request from an
      LDP peer may involve one or more of the following actions:

      -  Transmission of a notification message to the requesting LSR
         indicating why a label mapping for the FEC cannot be provided;

      -  Transmission of a FEC label mapping to the requesting LSR;

      -  Transmission of a FEC label request to the FEC next hop;

      -  Installation of labels for forwarding/switching use by the LSR.

   Context:

      -  LSR.  The LSR handling the event.

      -  MsgSource.  The LDP peer that sent the message.

      -  FEC.  The FEC specified in the message.

      -  RAttributes.  Attributes received with the message.  E.g., Hop
         Count, Path Vector.

      -  SAttributes.  Attributes to be included in Label Request
         message, if any, propagated to FEC Next Hop.

      -  StoredHopCount.  The hop count, if any, previously recorded for
         the FEC.

Top      Up      ToC       Page 97 
   Algorithm:

      LRq.1   Execute procedure Check_Received_Attributes (MsgSource,
              LabelRequest, RAttributes).
              If Loop Detected, goto LRq.13.

      LRq.2   Is there a Next Hop for FEC?
              If not, goto LRq.5.

      LRq.3   Is MsgSource the Next Hop?
              Ifnot, goto LRq.6.

      LRq.4   Execute procedure Send_Notification (MsgSource, Loop
              Detected).
              Goto LRq.13

      LRq.5   Execute procedure Send_Notification (MsgSource, No Route).
              Goto LRq.13.

      LRq.6   Has LSR previously received a label request for FEC from
              MsgSource?
              If not, goto LRq.8.  (See Note 1.)

      LRq.7   Is the label request a duplicate request?
              If so, Goto LRq.13.  (See Note 2.)

      LRq.8   Record label request for FEC received from MsgSource and
              mark it pending.

      LRq.9   Perform LSR Label Distribution procedure:

            For Downstream Unsolicited Independent Control OR
            For Downstream On Demand Independent Control

               1. Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?.
                  Is so, set Propagating to IsPropagating.
                  If not, set Propagating to NotPropagating.

               2. Execute procedure
                  Prepare_Label_Mapping_Attributes(MsgSource, FEC,
                  RAttributes, SAttributes, Propagating,
                  StoredHopCount).

               3. Execute procedure Send_Label (MsgSource, FEC,
                  SAttributes).

Top      Up      ToC       Page 98 
               4. Is LSR egress for FEC? OR
                  Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?
                  If so, goto LRq.11.
                  If not, goto LRq.10.

            For Downstream Unsolicited Ordered Control OR
            For Downstream On Demand Ordered Control

               1. Is LSR egress for FEC? OR
                  Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?  (See Note 3.)
                  If not, goto LRq.10.

               2. Execute procedure
                  Prepare_Label_Mapping_Attributes(MsgSource, FEC,
                  RAttributes, SAttributes, IsPropagating,
                  StoredHopCount)

               3. Execute procedure Send_Label (MsgSource, FEC,
                  SAttributes).
                  Goto LRq.11.

      LRq.10  Perform LSR Label Request procedure:

            For Request Never

               1. Goto LRq.13.

            For Request When Needed OR
            For Request On Request

               1. Execute procedure Prepare_Label_Request_Attributes
                  (Next Hop, FEC, RAttributes, SAttributes);

               2. Execute procedure Send_Label_Request (Next Hop, FEC,
                  SAttributes).
                  Goto LRq.13.

      LRq.11  Has LSR successfully sent a label for FEC to MsgSource?
              If not, goto LRq.13.  (See Note 4.)

      LRq.12  Perform LSR Label Use procedure.

            For Use Immediate OR
            For Use If Loop Not Detected

Top      Up      ToC       Page 99 
               1. Install label sent to MsgSource and label from Next
                  Hop (if LSR is not egress) for forwarding/switching
                  use.

      LRq.13  DONE

   Notes:

      1. In the case where MsgSource is a non-label merging LSR it will
         send a label request for each upstream LDP peer that has
         requested a label for FEC from it.  The LSR must be able to
         distinguish such requests from a non-label merging MsgSource
         from duplicate label requests.

         The LSR uses the message ID of received Label Request messages
         to detect duplicate requests.  This means that an LSR (the
         upstream peer) may not reuse the message ID used for a Label
         Request until the Label Request transaction has completed.

      2. When an LSR sends a label request to a peer it records that the
         request has been sent and marks it as outstanding.  As long as
         the request is marked outstanding the LSR should not send
         another request for the same label to the peer.  Such a second
         request would be a duplicate.  The Send_Label_Request procedure
         described below obeys this rule.

         A duplicate label request is considered a protocol error and
         should be dropped by the receiving LSR (perhaps with a suitable
         notification returned to MsgSource).

      3. If LSR is not merge-capable, this test will fail.

      4. The Send_Label procedure may fail due to lack of label
         resources, in which case the LSR should not perform the Label
         Use procedure.

A.1.2. Receive Label Mapping

   Summary:

      The response by an LSR to receipt of a FEC label mapping from an
      LDP peer may involve one or more of the following actions:

      -  Transmission of a label release message for the FEC label to
         the LDP peer;

      -  Transmission of label mapping messages for the FEC to one or
         more LDP peers,

Top      Up      ToC       Page 100 
      -  Installation of the newly learned label for
         forwarding/switching use by the LSR.

   Context:

      -  LSR.  The LSR handling the event.

      -  MsgSource.  The LDP peer that sent the message.

      -  FEC.  The FEC specified in the message.

      -  Label.  The label specified in the message.

      -  PrevAdvLabel.  The label for FEC, if any, previously advertised
         to an upstream peer.

      -  StoredHopCount.  The hop count previously recorded for the FEC.

      -  RAttributes.  Attributes received with the message.  E.g., Hop
         Count, Path Vector.

      -  SAttributes to be included in Label Mapping message, if any,
         propagated to upstream peers.

   Algorithm:

      LMp.1   Does the received label mapping match an outstanding
              label request for FEC previously sent to MsgSource.
              If not, goto LMp.3.

      LMp.2   Delete record of outstanding FEC label request.

      LMp.3   Execute procedure Check_Received_Attributes (MsgSource,
              LabelMapping, RAttributes).
              If No Loop Detected, goto LMp.9.

      LMp.4   Does the LSR have a previously received label mapping for
              FEC from MsgSource? (See Note 1.)
              If not, goto LMp.8.  (See Note 2.)

      LMp.5   Does the label previously received from MsgSource match
              Label (i.e., the label received in the message)?
              (See Note 3.)
              If not, goto LMp.8.  (See Note 4.)

      LMp.6   Delete matching label mapping for FEC previously
              received from MsgSource.

Top      Up      ToC       Page 101 
      LMp.7   Remove Label from forwarding/switching use.  (See Note 5.)
              Goto LMp.33.

      LMp.8   Execute procedure Send_Message (MsgSource, Label Release,
              FEC, Label, Loop Detected Status code).  Goto LMp.33.

      LMp.9   Does LSR have a previously received label mapping for FEC
              from MsgSource for the LSP in question?  (See Note 6.)
              If not, goto LMp.11.

      LMp.10  Does the label previously received from MsgSource match
              Label (i.e., the label received in the message)?
              (See Note 3.)
              If not, goto LMp.32.  (See Note 4.)

      LMp.11  Determine the Next Hop for FEC.

      LMp.12  Is MsgSource the Next Hop for FEC?
              If so, goto LMp.14.

      LMp.13  Perform LSR Label Release procedure:

            For Conservative Label retention:

              1. Goto LMp.32.

            For Liberal Label retention:

              1. Record label mapping for FEC with Label and
                 RAttributes has been received from MsgSource.
                 Goto LMp.33.

      LMp.14  Is LSR an ingress for FEC?
              If not, goto LMp.16.

      LMp.15  Install Label for forwarding/switching use.

      LMp.16  Record label mapping for FEC with Label and RAttributes
              has been received from MsgSource.

      LMp.17  Iterate through LMp.31 for each Peer.  (See Note 7).

      LMp.18  Has LSR previously sent a label mapping for FEC to Peer
              for the LSP in question?  (See Note 8.)
              If so, goto LMp.22.

Top      Up      ToC       Page 102 
      LMp.19  Is the Downstream Unsolicited Ordered Control Label
              Distribution procedure being used by LSR?  If not, goto
              LMp.28.

      LMp.20  Execute procedure Prepare_Label_Mapping_Attributes(Peer,
              FEC, RAttributes, SAttributes, IsPropagating,
              StoredHopCount).

      LMp.21  Execute procedure Send_Message (Peer, Label Mapping, FEC,
              PrevAdvLabel, SAttributes).
              Goto LMp.28

      LMp.22  Iterate through LMp.27 for each label mapping for FEC
              previously sent to Peer.

      LMp.23  Are RAttributes in the received label mapping consistent
              with those previously sent to Peer?
              If so, continue iteration from LMp.22 for next label
              mapping. (See Note 9.)

      LMp.24  Execute procedure Prepare_Label_Mapping_Attributes(Peer,
              FEC, RAttributes, SAttributes, IsPropagating,
              StoredHopCount).

      LMp.25  Execute procedure Send_Message (Peer, Label Mapping, FEC,
              PrevAdvLabel, SAttributes).  (See Note 10.)

      LMp.26  Update record of label mapping for FEC previously sent to
              Peer to include the new attributes sent.

      LMp.27  End iteration from LMp.22.

      LMp.28  Does LSR have any label requests for FEC from Peer marked
              as pending?
              If not, goto LMp.30.

      LMp.29  Perform LSR Label Distribution procedure:

            For Downstream Unsolicited Independent Control OR
            For Downstream Unsolicited Ordered Control

              1. Execute procedure
                 Prepare_Label_Mapping_Attributes(Peer, FEC,
                 RAttributes, SAttributes, IsPropagating,
                 UnknownHopCount).

Top      Up      ToC       Page 103 
              2. Execute procedure Send_Label (Peer, FEC, SAttributes).
                 If the procedure fails, continue iteration for
                 next Peer at LMp.17.

              3. If no pending requests exist for Peer goto LMp.30.
                 (See Note 11.)

            For Downstream On Demand Independent Control OR
            For Downstream On Demand Ordered Control

              1. Iterate through Step 5 for each pending label
                 request for FEC from Peer marked as pending.

              2. Execute procedure
                 Prepare_Label_Mapping_Attributes(Peer, FEC,
                 RAttributes, SAttributes, IsPropagating,
                 UnknownHopCount)

              3. Execute procedure Send_Label (Peer, FEC,
                 SAttributes).
                 If the procedure fails, continue iteration for next
                 Peer at LMp.17.

              4. Delete record of pending request.

              5. End iteration from Step 1.

              6. Goto LMp.30.

      LMp.30  Perform LSR Label Use procedure:

            For Use Immediate OR
            For Use If Loop Not Detected

              1. Iterate through Step 3 for each label mapping for
                 FEC previously sent to Peer.

              2. Install label received and label sent to Peer for
                 forwarding/switching use.

              3. End iteration from Step 1.

              4. Goto LMp.31.

      LMp.31  End iteration from LMp.17.
              Go to LMp.33.

Top      Up      ToC       Page 104 
      LMp.32  Execute procedure Send_Message (MsgSource, Label Release,
              FEC, Label).

      LMp.33  DONE.

   Notes:

      1.  If the LSR is merging there should be at most 1 received
          mapping for the FEC for the LSP in question.  In the non-
          merging case there could be multiple received mappings for the
          FEC for the LSP in question.

      2.  If LSR has detected a loop and it has not previously received
          a label mapping from MsgSource for the FEC, it simply releases
          the label.

      3.  Does the Label received in the message match any of the 1 or
          more label mappings identified in the previous step (LMp.4 or
          LMp.9)?

      4.  An unsolicited mapping with a different label from the same
          peer would be an attempt to establish multipath label
          switching, which is not supported in this version of LDP.

      5.  If Label is not in forwarding/switching use, LMp.7 has no
          effect.

      6.  If the received label mapping message matched an outstanding
          label request in LMp.1, then (by definition) LSR has not
          previously received a label mapping for FEC for the LSP in
          question.  If the LSR is merging upstream labels for the LSP
          in question, there should be at most 1 received mapping.  In
          the non-merging case, there could be multiple received label
          mappings for the same FEC, one for each resulting LSP.

      7.  The LMp.17 iteration includes MsgSource in order to handle the
          case where LSR is operating in Downstream Unsolicited ordered
          control mode.  Ordered control prevents LSR from advertising a
          label for FEC until it has received a label mapping from its
          next hop (MsgSource) for FEC.

      8.  If LSR is merging the LSP it may have previously sent label
          mappings for the FEC LSP to one or more peers.  If LSR is not
          merging, it may have sent a label mapping for the LSP in
          question to at most one LSR.

Top      Up      ToC       Page 105 
      9.  The loop detection Path Vector attribute is considered in this
          check.  If the received RAttributes include a Path Vector and
          no Path Vector had been previously sent to the Peer, or if the
          received Path Vector is inconsistent with the Path Vector
          previously sent to the Peer, then the attributes are
          considered to be inconsistent.  Note that an LSR is not
          required to store a received Path Vector after it propagates
          the Path Vector in a mapping message.  If an LSR does not
          store the Path Vector, it has no way to check the consistency
          of a newly received Path Vector.  This means that whenever
          such an LSR receives a mapping message carrying a Path Vector
          it must always propagate the Path Vector.

      10. LMp.22 through LMp.27 deal with a situation that can arise
          when the LSR is using independent control and it receives a
          mapping from the downstream peer after it has sent a mapping
          to an upstream peer.  In this situation the LSR needs to
          propagate any changed attributes, such as Hop Count, upstream.
          If Loop Detection is configured on, the propagated attributes
          must include the Path Vector

      11. An LSR operating in Downstream Unsolicited mode must process
          any Label Request messages it receives.  If there are pending
          label requests, fall through into the Downstream on Demand
          procedures in order to satisfy the pending requests.

A.1.3. Receive Label Abort Request

   Summary:

      When an LSR receives a label abort request message from a peer, it
      checks whether it has already responded to the label request in
      question. If it has, it silently ignores the message.  If it has
      not, it sends the peer a Label Request Aborted Notification.  In
      addition, if it has a label request outstanding for the LSP in
      question to a downstream peer, it sends a Label Abort Request to
      the downstream peer to abort the LSP.

   Context:

      -  LSR.  The LSR handling the event.

      -  MsgSource.  The LDP peer that sent the message.

      -  FEC.  The FEC specified in the message.

      -  RequestMessageID.  The message ID of the label request message
         to be aborted.

Top      Up      ToC       Page 106 
      -  Next Hop.  The next hop for the FEC.

   Algorithm:

      LAbR.1  Does the message match a previously received label request
              message from MsgSource? (See Note 1.)
              If not, goto LAbR.12.

      LAbR.2  Has LSR responded to the previously received label
              request?
              If so, goto LAbR.12.

      LAbR.3  Execute procedure Send_Message(MsgSource, Notification,
              Label Request Aborted, TLV), where TLV is the Label
              Request Message ID TLV received in the label abort
              request message.

      LAbR.4  Does LSR have a label request message outstanding for
              FEC?
              If so, goto LAbR.7

      LAbR.5  Does LSR have a label mapping for FEC?
              If not, goto LAbR.11

      LAbR.6  Generate Event: Received Label Release Message for FEC
              from MsgSource.  (See Note 2.)
              Goto LAbR.11.

      LAbR.7  Is LSR merging the LSP for FEC?
              If not, goto LAbR.9.

      LAbR.8  Are there upstream peers other than MsgSource that have
              requested a label for FEC?
              If so, goto LAbR.11.

      LAbR.9  Execute procedure Send_Message (Next Hop, Label Abort
              Request, FEC, TLV), where TLV is a Label Request Message
              ID TLV containing the Message ID used by the LSR in the
              outstanding Label Request message.

      LAbR.10  Record that a label abort request for FEC is pending.

      LAbR.11  Delete record of label request for FEC from MsgSource.

      LAbR.12  DONE

Top      Up      ToC       Page 107 
   Notes:

      1. LSR uses FEC and the Label Request Message ID TLV carried by
         the label abort request to locate its record (if any) for the
         previously received label request from MsgSource.

      2. If LSR has received a label mapping from NextHop, it should
         behave as if it had advertised a label mapping to MsgSource and
         MsgSource has released it.

A.1.4. Receive Label Release

   Summary:

      When an LSR receives a label release message for a FEC from a
      peer, it checks whether other peers hold the released label.  If
      none do, the LSR removes the label from forwarding/switching use,
      if it has not already done so, and if the LSR holds a label
      mapping from the FEC next hop, it releases the label mapping.

   Context:

      -  LSR.  The LSR handling the event.

      -  MsgSource.  The LDP peer that sent the message.

      -  Label.  The label specified in the message.

      -  FEC.  The FEC specified in the message.

   Algorithm:

      LRl.1   Remove MsgSource from record of peers that hold Label for
              FEC.  (See Note 1.)

      LRl.2   Does message match an outstanding label withdraw for FEC
              previously sent to MsgSource?
              If not, goto LRl.4

      LRl.3   Delete record of outstanding label withdraw for FEC
              previously sent to MsgSource.

      LRl.4   Is LSR merging labels for this FEC?
              If not, goto LRl.6.  (See Note 2.)

      LRl.5   Has LSR previously advertised a label for this FEC to
              other peers?
              If so, goto LRl.10.

Top      Up      ToC       Page 108 
      LRl.6   Is LSR egress for the FEC?
              If so, goto LRl.10

      LRl.7   Is there a Next Hop for FEC? AND
              Does LSR have a previously received label mapping for FEC
              from Next Hop?
              If not, goto LRl.10.

      LRl.8   Is LSR configured to propagate releases?
              If not, goto LRl.10.  (See Note 3.)

      LRl.9   Execute procedure Send_Message (Next Hop, Label Release,
              FEC, Label from Next Hop).

      LRl.10  Remove Label from forwarding/switching use for traffic
              from MsgSource.

      LRl.11  Do any peers still hold Label for FEC?
              If so, goto LRl.13.

      LRl.12  Free the Label.

      LRl.13  DONE.

   Notes:

      1. If LSR is using Downstream Unsolicited label distribution, it
         should not re-advertise a label mapping for FEC to MsgSource
         until MsgSource requests it.

      2. LRl.4 through LRl.8 deal with determining whether where the LSR
         should propagate the label release to a downstream peer
         (LRl.9).

      3. If LRl.8 is reached, no upstream LSR holds a label for the FEC,
         and the LSR holds a label for the FEC from the FEC Next Hop.
         The LSR could propagate the Label Release to the Next Hop.  By
         propagating the Label Release the LSR releases a potentially
         scarce label resource.  In doing so, it also increases the
         latency for re-establishing the LSP should MsgSource or some
         other upstream LSR send it a new Label Request for FEC.

         Whether or not to propagate the release is not a protocol
         issue.  Label distribution will operate properly whether or not
         the release is propagated.  The decision to propagate or not
         should take into consideration factors such as: whether labels
         are a scarce resource in the operating environment; the
         importance of keeping LSP setup latency low by keeping the

Top      Up      ToC       Page 109 
         amount of signaling required small; whether LSP setup is
         ingress-controlled or egress-controlled in the operating
         environment.

A.1.5. Receive Label Withdraw

   Summary:

      When an LSR receives a label withdraw message for a FEC from an
      LDP peer, it responds with a label release message and it removes
      the label from any forwarding/switching use.  If ordered control
      is in use, the LSR sends a label withdraw message to each LDP peer
      to which it had previously sent a label mapping for the FEC.  If
      the LSR is using Downstream on Demand label advertisement with
      independent control, it then acts as if it had just recognized the
      FEC.

   Context:

      -  LSR.  The LSR handling the event.

      -  MsgSource.  The LDP peer that sent the message.

      -  Label.  The label specified in the message.

      -  FEC.  The FEC specified in the message.

   Algorithm:

      LWd.1   Remove Label from forwarding/switching use.  (See Note 1.)

      LWd.2   Execute procedure Send_Message (MsgSource, Label Release,
              FEC, Label)

      LWd.3   Has LSR previously received and retained a matching label
              mapping for FEC from MsgSource?
              If not, goto LWd.13.

      LWd.4   Delete matching label mapping for FEC previously received
              from MsgSource.

      LWd.5   Is LSR using ordered control?
              If so, goto LWd.8.

      LWd.6   Is MsgSource using Downstream On Demand label
              advertisement?
              If not, goto LWd.13.

Top      Up      ToC       Page 110 
      LWd.7   Generate Event: Recognize New FEC for FEC.
              Goto LWd.13.  (See Note 2.)

      LWd.8   Iterate through LWd.12 for each Peer, other than
              MsgSource.

      LWd.9   Has LSR previously sent a label mapping for FEC to Peer?
              If not, continue iteration for next Peer at LWd.8.

      LWd.10  Does the label previously sent to Peer "map" to the
              withdrawn Label?
              If not, continue iteration for next Peer at LWd.8.
              (See Note 3.)

      LWd.11  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
              previously sent to Peer).

      LWd.12  End iteration from LWd.8.

      LWd.13  DONE

   Notes:

      1. If Label is not in forwarding/switching use, LWd.1 has no
         effect.

      2. LWd.7 handles the case where the LSR is using Downstream On
         Demand label distribution with independent control.  In this
         situation the LSR should send a label request to the FEC next
         hop as if it had just recognized the FEC.

      3. LWd.10 handles both label merging (one or more incoming labels
         map to the same outgoing label) and no label merging (one label
         maps to the outgoing label) cases.

A.1.6. Recognize New FEC

   Summary:

      The response by an LSR to learning a new FEC via the routing table
      may involve one or more of the following actions:

      -  Transmission of label mappings for the FEC to one or more LDP
         peers;

      -  Transmission of a label request for the FEC to the FEC next
         hop;

Top      Up      ToC       Page 111 
      -  Any of the actions that can occur when the LSR receives a label
         mapping for the FEC from the FEC next hop.

   Context:

      -  LSR.  The LSR handling the event.

      -  FEC. The newly recognized FEC.

      -  Next Hop.  The next hop for the FEC.

      -  InitAttributes.  Attributes to be associated with the new FEC.
         (See Note 1.)

      -  SAttributes.  Attributes to be included in Label Mapping or
         Label Request messages, if any, sent to peers.

      -  StoredHopCount.  Hop count associated with FEC label mapping,
         if any, previously received from Next Hop.

   Algorithm:

      FEC.1   Perform LSR Label Distribution procedure:

            For Downstream Unsolicited Independent Control

               1. Iterate through 5 for each Peer.

               2. Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?
                  If so, set Propagating to IsPropagating.
                  If not, set Propagating to NotPropagating.

               3. Execute procedure Prepare_Label_Mapping_Attributes
                  (Peer, FEC, InitAttributes, SAttributes, Propagating,
                  Unknown hop count(0)).

               4. Execute procedure Send_Label (Peer, FEC, SAttributes)

               5. End iteration from 1.
                  Goto FEC.2.

            For Downstream Unsolicited Ordered Control

               1. Iterate through 5 for each Peer.

Top      Up      ToC       Page 112 
               2. Is LSR egress for the FEC? OR
                  Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?
                  If not, continue iteration for next Peer.

               3. Execute procedure Prepare_Label_Mapping_Attributes
                  (Peer, FEC, InitAttributes, SAttributes, Propagating,
                  StoredHopCount).

               4. Execute procedure Send_Label (Peer, FEC, SAttributes)

               5. End iteration from 1.
                  Goto FEC.2.

            For Downstream On Demand Independent Control OR
            For Downstream On Demand Ordered Control

               1. Goto FEC.2.  (See Note 2.)

      FEC.2   Has LSR previously received and retained a label
              mapping for FEC from Next Hop?
              If so, goto FEC.5

      FEC.3   Is Next Hop an LDP peer?
              If not, Goto FEC.6

      FEC.4   Perform LSR Label Request procedure:

            For Request Never

              1. Goto FEC.6

            For Request When Needed OR
            For Request On Request

              1. Execute procedure
                 Prepare_Label_Request_Attributes
                 (Next Hop, FEC, InitAttributes, SAttributes);

              2. Execute procedure Send_Label_Request (Next
                 Hop, FEC, SAttributes).
                 Goto FEC.6.

      FEC.5   Generate Event: Received Label Mapping from Next Hop.
              (See Note 3.)

      FEC.6   DONE.

Top      Up      ToC       Page 113 
   Notes:

      1. An example of an attribute that might be part of InitAttributes
         is one which specifies desired LSP characteristics, such as
         class of service (CoS).  (Note that while the current version
         of LDP does not specify a CoS attribute, LDP extensions may.)

         The means by which FEC InitAttributes, if any, are specified is
         beyond the scope of LDP.  Note that the InitAttributes will not
         include a known Hop Count or a Path Vector.

      2. An LSR using Downstream On Demand label distribution would send
         a label only if it had a previously received label request
         marked as pending.  The LSR would have no such pending requests
         because it responds to any label request for an unknown FEC by
         sending the requesting LSR a No Route notification and
         discarding the label request; see LRq.3

      3. If the LSR has a label for the FEC from the Next Hop, it should
         behave as if it had just received the label from the Next Hop.
         This occurs in the case of Liberal label retention mode.

A.1.7. Detect Change in FEC Next Hop

   Summary:

      The response by an LSR to a change in the next hop for a FEC may
      involve one or more of the following actions:

      -  Removal of the label from the FEC's old next hop from
         forwarding/switching use;

      -  Transmission of label mapping messages for the FEC to one or
         more LDP peers;

      -  Transmission of a label request to the FEC's new next hop;

      -  Any of the actions that can occur when the LSR receives a label
         mapping from the FEC's new next hop.

   Context:

      -  LSR.  The LSR handling the event.

      -  FEC.  The FEC whose next hop changed.

      -  New Next Hop.  The current next hop for the FEC.

Top      Up      ToC       Page 114 
      -  Old Next Hop.  The previous next hop for the FEC.

      -  OldLabel.  Label, if any, previously received from Old Next
         Hop.

      -  CurAttributes.  The attributes, if any, currently associated
         with the FEC.

      -  SAttributes.  Attributes to be included in Label Label Request
         message, if any, sent to New Next Hop.

   Algorithm:

      NH.1   Has LSR previously received and retained a label mapping
             for FEC from Old Next Hop?
             If not, goto NH.6.

      NH.2   Remove label from forwarding/switching use.  (See Note 1.)

      NH.3   Is LSR using Liberal label retention?
             If so, goto NH.6.

      NH.4   Execute procedure Send_Message (Old Next Hop, Label
             Release, OldLabel).

      NH.5   Delete label mapping for FEC previously received from Old
             Next Hop.

      NH.6   Does LSR have a label request pending with Old Next Hop?
             If not, goto NH.10.

      NH.7   Is LSR using Conservative label retention?
             If not, goto NH.10.

      NH.8   Execute procedure Send_Message (Old Next Hop, Label Abort
             Request, FEC, TLV), where TLV is a Label Request Message
             ID TLV that carries the message ID of the pending label
             request.

      NH.9   Record a label abort request is pending for FEC with Old
             Next Hop.

      NH.10  Is there a New Next Hop for the FEC?
             If not, goto NH.16.

      NH.11  Has LSR previously received and retained a label mapping
             for FEC from New Next Hop?
             If not, goto NH.13.

Top      Up      ToC       Page 115 
      NH.12  Generate Event: Received Label Mapping from New Next Hop.
             Goto NH.20.  (See Note 2.)

      NH.13  Is LSR using Downstream on Demand advertisement? OR
             Is Next Hop using Downstream on Demand advertisement? OR
             Is LSR using Conservative label retention? (See Note 3.)
             If so, goto NH.14.
             If not, goto NH.20.

      NH.14  Execute procedure Prepare_Label_Request_Attributes (Next
             Hop, FEC, CurAttributes, SAttributes)

      NH.15  Execute procedure Send_Label_Request (New Next Hop, FEC,
             SAttributes).  (See Note 4.)
             Goto NH.20.

      NH.16  Iterate through NH.19 for each Peer.

      NH.17  Has LSR previously sent a label mapping for FEC to Peer?
             If not, continue iteration for next Peer at NH.16.

      NH.18  Execute procedure Send_Label_Withdraw (Peer, FEC, Label
             previously sent to Peer).

      NH.19  End iteration from NH.16.

      NH.20  DONE.

   Notes:

      1. If Label is not in forwarding/switching use, NH.2 has no
         effect.

      2. If the LSR has a label for the FEC from the New Next Hop, it
         should behave as if it had just received the label from the New
         Next Hop.

      3. The purpose of the check on label retention mode is to avoid a
         race with steps LMp.12-LMp.13 of the procedure for handling a
         Label Mapping message where the LSR operating in Conservative
         Label retention mode may have released a label mapping received
         from the New Next Hop before it detected the FEC next hop had
         changed.

      4. Regardless of the Label Request procedure in use by the LSR, it
         must send a label request if the conditions in NH.8 hold.
         Therefore it executes the Send_Label_Request procedure directly
         rather than perform LSR Label Request procedure.

Top      Up      ToC       Page 116 
A.1.8. Receive Notification / Label Request Aborted

   Summary:

      When an LSR receives a Label Request Aborted notification from an
      LDP peer it records that the corresponding label request
      transaction, if any, has completed.

   Context:

      -  LSR.  The LSR handling the event.

      -  FEC.  The FEC for which a label was requested.

      -  RequestMessageID.  The message ID of the label request message
         to be aborted.

      -  MsgSource.  The LDP peer that sent the Notification message.

   Algorithm:

      LRqA.1  Does the notification correspond to an outstanding label
              request abort for FEC? (See Note 1).
              If not, goto LRqA.3.

      LRqA.2  Record that the label request for FEC has been aborted.

      LRqA.3  DONE

   Notes:

      1. The LSR uses the FEC and RequestMessageID to locate its record,
         if any, of the outstanding label request abort.

A.1.9. Receive Notification / No Label Resources

   Summary:

      When an LSR receives a No Label Resources notification from an LDP
      peer, it stops sending label request messages to the peer until it
      receives a Label Resources Available Notification from the peer.

   Context:

      -  LSR.  The LSR handling the event.

      -  FEC.  The FEC for which a label was requested.

Top      Up      ToC       Page 117 
      -  MsgSource.  The LDP peer that sent the Notification message.

   Algorithm:

      NoRes.1 Delete record of outstanding label request for FEC sent
              to MsgSource.

      NoRes.2 Record label mapping for FEC from MsgSource is needed but
              that no label resources are available.

      NoRes.3 Set status record indicating it is not OK to send label
              requests to MsgSource.

      NoRes.4 DONE.

A.1.10. Receive Notification / No Route

   Summary:

      When an LSR receives a No Route notification from an LDP peer in
      response to a Label Request message, the Label No Route procedure
      in use dictates its response. The LSR either will take no further
      action, or it will defer the label request by starting a timer and
      send another Label Request message to the peer when the timer
      later expires.

   Context:

      -  LSR.  The LSR handling the event.

      -  FEC.  The FEC for which a label was requested.

      -  Attributes.  The attributes associated with the label request.

      -  MsgSource.  The LDP peer that sent the Notification message.

   Algorithm:

      NoNH.1  Delete record of outstanding label request for FEC sent
              to MsgSource.

      NoNH.2  Perform LSR Label No Route procedure.

            For Request No Retry

              1. Goto NoNH.3.

Top      Up      ToC       Page 118 
            For Request Retry

              1. Record deferred label request for FEC and Attributes
                 to be sent to MsgSource.

              2. Start timeout.  Goto NoNH.3.

      NoNH.3  DONE.

A.1.11. Receive Notification / Loop Detected

   Summary:

      When an LSR receives a Loop Detected Status Code from an LDP peer
      in response to a Label Request message or a Label Mapping message,
      it behaves as if it had received a No Route notification.

   Context:

      See "Receive Notification / No Route".

   Algorithm:

      See "Receive Notification / No Route"

   Notes:

      1. When the Loop Detected notification is in response to a Label
         Request message, it arrives in a Status Code TLV in a
         Notification message.  When it is in response to a Label
         Mapping message, it arrives in a Status Code TLV in a Label
         Release message.

A.1.12. Receive Notification / Label Resources Available

   Summary:

      When an LSR receives a Label Resources Available notification from
      an LDP peer, it resumes sending label requests to the peer.

   Context:

      -  LSR.  The LSR handling the event.

      -  MsgSource.  The LDP peer that sent the Notification message.

      -  SAttributes.  Attributes stored with postponed Label Request
         message.

Top      Up      ToC       Page 119 
   Algorithm:

      Res.1   Set status record indicating it is OK to send label
              requests to MsgSource.

      Res.2   Iterate through Res.6 for each record of a FEC label
              mapping needed from MsgSource for which no label
              resources are available.

      Res.3   Is MsgSource the next hop for FEC?
              If not, goto Res.5.

      Res.4   Execute procedure Send_Label_Request (MsgSource, FEC,
              SAttributes).  If the procedure fails, terminate
              iteration.

      Res.5   Delete record that no resources are available for a label
              mapping for FEC needed from MsgSource.

      Res.6   End iteration from Res.2

      Res.7   DONE.

A.1.13. Detect local label resources have become available

   Summary:

      After an LSR has sent a No Label Resources notification to an LDP
      peer, when label resources later become available it sends a Label
      Resources Available notification to each such peer.

   Context:

      -  LSR.  The LSR handling the event.

      -  Attributes.  Attributes stored with postponed Label Mapping
         message.

   Algorithm:

      ResA.1  Iterate through ResA.4 for each Peer to which LSR has
              previously sent a No Label Resources notification.

      ResA.2  Execute procedure Send_Notification (Peer, Label
              Resources Available)

      ResA.3  Delete record that No Label Resources notification was
              previously sent to Peer.

Top      Up      ToC       Page 120 
      ResA.4  End iteration from ResA.1

      ResA.5  Iterate through ResA.8 for each record of a label mapping
              needed for FEC for Peer but no-label-resources.  (See Note
              1.)

      ResA.6  Execute procedure Send_Label (Peer, FEC, Attributes).  If
              the procedure fails, terminate iteration.

      ResA.7  Clear record of FEC label mapping needed for peer but no-
              label-resources.

      ResA.8  End iteration from ResA.5

      ResA.9  DONE.

   Notes:

      1. Iteration ResA.5 through ResA.8 handles the situation where the
         LSR is using Downstream Unsolicited label distribution and was
         previously unable to allocate a label for a FEC.

A.1.14. LSR decides to no longer label switch a FEC

   Summary:

      An LSR may unilaterally decide to no longer label switch a FEC for
      an LDP peer.  An LSR that does so must send a label withdraw message
      for the FEC to the peer.

   Context:

      -  Peer.  The peer.

      -  FEC.  The FEC.

      -  PrevAdvLabel.  The label for FEC previously advertised to Peer.

   Algorithm:

      NoLS.1  Execute procedure Send_Label_Withdraw (Peer, FEC,
              PrevAdvLabel).  (See Note 1.)

      NoLS.2  DONE.

Top      Up      ToC       Page 121 
   Notes:

      1. The LSR may remove the label from forwarding/switching use as
         part of this event or as part of processing the label release
         from the peer in response to the label withdraw.

A.1.15. Timeout of deferred label request

   Summary:

      Label requests are deferred in response to No Route and Loop
      Detected notifications.  When a deferred FEC label request for a
      peer times out, the LSR sends the label request.

   Context:

      -  LSR.  The LSR handling the event.

      -  FEC.  The FEC associated with the timeout event.

      -  Peer.  The LDP peer associated with the timeout event.

      -  Attributes.  Attributes stored with deferred Label Request
         message.

   Algorithm:

      TO.1    Retrieve the record of the deferred label request.

      TO.2    Is Peer the next hop for FEC?
              If not, goto TO.4.

      TO.3    Execute procedure Send_Label_Request (Peer, FEC).

      TO.4    DONE.

A.2. Common Label Distribution Procedures

      This section specifies utility procedures used by the algorithms
      that handle label distribution events.

A.2.1. Send_Label

   Summary:

      The Send_Label procedure allocates a label for a FEC for an LDP
      peer, if possible, and sends a label mapping for the FEC to the
      peer.  If the LSR is unable to allocate the label and if it has a

Top      Up      ToC       Page 122 
      pending label request from the peer, it sends the LDP peer a No
      Label Resources notification.

   Parameters:

      -  Peer.  The LDP peer to which the label mapping is to be sent.

      -  FEC.  The FEC for which a label mapping is to be sent.

      -  Attributes.  The attributes to be included with the label
         mapping.

   Additional Context:

      -  LSR.  The LSR executing the procedure.

      -  Label.  The label allocated and sent to Peer.

   Algorithm:

      SL.1   Does LSR have a label to allocate?
             If not, goto SL.9.

      SL.2   Allocate Label and bind it to the FEC.

      SL.3   Install Label for forwarding/switching use.

      SL.4   Execute procedure Send_Message (Peer, Label Mapping, FEC,
             Label, Attributes).

      SL.5   Record label mapping for FEC with Label and Attributes has
             been sent to Peer.

      SL.6   Does LSR have a record of a FEC label request from Peer
             marked as pending?
             If not, goto SL.8.

      SL.7   Delete record of pending label request for FEC from Peer.

      SL.8   Return success.

      SL.9   Does LSR have a label request for FEC from Peer marked as
             pending?
             If not, goto SL.13.

      SL.10  Execute procedure Send_Notification (Peer, No Label
             Resources).

Top      Up      ToC       Page 123 
      SL.11  Delete record of pending label request for FEC from Peer.

      SL.12  Record No Label Resources notification has been sent to
             Peer.
             Goto SL.14.

      SL.13  Record label mapping needed for FEC and Attributes for
             Peer, but no-label-resources.  (See Note 1.)

      SL.14  Return failure.

   Notes:

      1. SL.13 handles the case of Downstream Unsolicited label
         distribution when the LSR is unable to allocate a label for a
         FEC to send to a Peer.

A.2.2. Send_Label_Request

   Summary:

      An LSR uses the Send_Label_Request procedure to send a request for
      a label for a FEC to an LDP peer if currently permitted to do so.

   Parameters:

      -  Peer.  The LDP peer to which the label request is to be sent.

      -  FEC.  The FEC for which a label request is to be sent.

      -  Attributes.  Attributes to be included in the label request.
         E.g., Hop Count, Path Vector.

   Additional Context:

      -  LSR.  The LSR executing the procedure.

   Algorithm:

      SLRq.1  Has a label request for FEC previously been sent to Peer
              and is it marked as outstanding?
              If so, Return success.  (See Note 1.)

      SLRq.2  Is status record indicating it is OK to send label
              requests to Peer set?
              If not, goto SLRq.6

Top      Up      ToC       Page 124 
      SLRq.3  Execute procedure Send_Message (Peer, Label Request, FEC,
              Attributes).

      SLRq.4  Record label request for FEC has been sent to Peer and
              mark it as outstanding.

      SLRq.5  Return success.

      SLRq.6  Postpone the label request by recording label mapping for
              FEC and Attributes from Peer is needed but that no label
              resources are available.

      SLRq.7  Return failure.

   Notes:

      1. If the LSR is a non-merging LSR it must distinguish between
         attempts to send label requests for a FEC triggered by
         different upstream LDP peers from duplicate requests.  This
         procedure will not send a duplicate label request.

A.2.3. Send_Label_Withdraw

   Summary:

      An LSR uses the Send_Label_Withdraw procedure to withdraw a label
      for a FEC from an LDP peer.  To do this the LSR sends a Label
      Withdraw message to the peer.

   Parameters:

      -  Peer.  The LDP peer to which the label withdraw is to be sent.

      -  FEC.  The FEC for which a label is being withdrawn.

      -  Label.  The label being withdrawn

   Additional Context:

      -  LSR.  The LSR executing the procedure.

   Algorithm:

      SWd.1  Execute procedure Send_Message (Peer, Label Withdraw, FEC,
             Label)

      SWd.2  Record label withdraw for FEC has been sent to Peer and
             mark it as outstanding.

Top      Up      ToC       Page 125 
A.2.4. Send_Notification

   Summary:

      An LSR uses the Send_Notification procedure to send an LDP peer a
      notification message.

   Parameters:

      -  Peer.  The LDP peer to which the Notification message is to be
         sent.

      -  Status.  Status code to be included in the Notification
         message.

   Additional Context:

      None.

   Algorithm:

      SNt.1  Execute procedure Send_Message (Peer, Notification, Status)

A.2.5. Send_Message

   Summary:

      An LSR uses the Send_Message procedure to send an LDP peer an LDP
      message.

   Parameters:

      -  Peer.  The LDP peer to which the message is to be sent.

      -  Message Type.  The type of message to be sent.

      -  Additional message contents . . .  .

   Additional Context:

      None.

   Algorithm:

      This procedure is the means by which an LSR sends an LDP message
      of the specified type to the specified LDP peer.

Top      Up      ToC       Page 126 
A.2.6. Check_Received_Attributes

   Summary:

      Check the attributes received in a Label Mapping or Label Request
      message.  If the attributes include a Hop Count or Path Vector,
      perform a loop detection check.  If a loop is detected, cause a
      Loop Detected Notification message to be sent to MsgSource.

   Parameters:

      -  MsgSource.  The LDP peer that sent the message.

      -  MsgType.  The type of message received.

      -  RAttributes.  The attributes in the message.

   Additional Context:

      -  LSR Id.  The unique LSR Id of this LSR.

      -  Hop Count.  The Hop Count, if any, in the received attributes.

      -  Path Vector.  The Path Vector, if any in the received
         attributes.

   Algorithm:

      CRa.1   Do RAttributes include Hop Count?
              If not, goto CRa.5.

      CRa.2   Does Hop Count exceed Max allowable hop count?
              If so, goto CRa.6.

      CRa.3   Do RAttributes include Path Vector?
              If not, goto CRa.5.

      CRa.4   Does Path Vector Include LSR Id? OR
              Does length of Path Vector exceed Max allowable length?
              If so, goto CRa.6

      CRa.5   Return No Loop Detected.

      CRa.6   Is MsgType LabelMapping?
              If so, goto CRa.8.  (See Note 1.)

      CRa.7   Execute procedure Send_Notification (MsgSource, Loop
              Detected)

Top      Up      ToC       Page 127 
      CRa.8   Return Loop Detected.

      CRa.9   DONE

   Notes:

      1. When the attributes being checked were received in a Label
         Mapping message, the LSR sends the Loop Detected notification
         in a Status Code TLV in a Label Release message.  (See Section
         "Receive Label Mapping").

A.2.7. Prepare_Label_Request_Attributes

   Summary:

      This procedure is used whenever a Label Request is to be sent to a
      Peer to compute the Hop Count and Path Vector, if any, to include
      in the message.

   Parameters:

      -  Peer.  The LDP peer to which the message is to be sent.

      -  FEC.  The FEC for which a label request is to be sent.

      -  RAttributes.  The attributes this LSR associates with the LSP
         for FEC.

      -  SAttributes.  The attributes to be included in the Label
         Request message.

   Additional Context:

      -  LSR Id.  The unique LSR Id of this LSR.

   Algorithm:

      PRqA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
              Do RAttributes include a Hop Count? OR
              Is Loop Detection configured on LSR?
              If not, goto PRqA.14.

      PRqA.2  Is LSR ingress for FEC?
              If not, goto PRqA.6.

      PRqA.3  Include Hop Count of 1 in SAttributes.

Top      Up      ToC       Page 128 
      PRqA.4  Is Loop Detection configured on LSR?
              If not, goto PRqA.14.

      PRqA.5  Is LSR merge-capable?
              If so, goto PRqA.14.
              If not, goto PRqA.13.

      PRqA.6  Do RAttributes include a Hop Count?
              If not, goto PRqA.8.

      PRqA.7  Increment RAttributes Hop Count and copy the resulting Hop
              Count to SAttributes.  (See Note 2.)
              Goto PRqA.9.

      PRqA.8  Include Hop Count of unknown (0) in SAttributes.

      PRqA.9  Is Loop Detection configured on LSR?
              If not, goto PRqA.14.

      PRqA.10 Do RAttributes have a Path Vector?
              If so, goto PRqA.12.

      PRqA.11 Is LSR merge-capable?
              If so, goto PRqA.14.
              If not, goto PRqA.13.

      PRqA.12 Add LSR Id to beginning of Path Vector from RAttributes
              and copy the resulting Path Vector into SAttributes.
              Goto PRqA.14.

      PRqA.13 Include Path Vector of length 1 containing LSR Id in
              SAttributes.

      PRqA.14 DONE.

   Notes:

      1. The link with Peer may require that Hop Count be included in
         Label Request messages; for example, see [RFC3035] and
         [RFC3034].

      2. For hop count arithmetic, unknown + 1 = unknown.

Top      Up      ToC       Page 129 
A.2.8.  Prepare_Label_Mapping_Attributes

   Summary:

      This procedure is used whenever a Label Mapping is to be sent to a
      Peer to compute the Hop Count and Path Vector, if any, to include
      in the message.

   Parameters:

      -  Peer.  The LDP peer to which the message is to be sent.

      -  FEC.  The FEC for which a label request is to be sent.

      -  RAttributes.  The attributes this LSR associates with the LSP
         for FEC.

      -  SAttributes.  The attributes to be included in the Label
         Mapping message.

      -  IsPropagating.  The LSR is sending the Label Mapping message to
         propagate one received from the FEC next hop.

      -  PrevHopCount.  The Hop Count, if any, this LSR associates with
         the LSP for the FEC.

   Additional Context:

      -  LSR Id.  The unique LSR Id of this LSR.

   Algorithm:

      PMpA.1  Is Hop Count required for this Peer (see Note 1.) ? OR
              Do RAttributes include a Hop Count? OR
              Is Loop Detection configured on LSR?
              If not, goto PMpA.21.

      PMpA.2  Is LSR egress for FEC?
              If not, goto PMpA.4.

      PMpA.3  Include Hop Count of 1 in SAttributes.  Goto PMpA.21.

      PMpA.4  Do RAttributes have a Hop Count?
              If not, goto PMpA.8.

Top      Up      ToC       Page 130 
      PMpA.5  Is LSR member of edge set for an LSR domain whose LSRs do
              not perform TTL decrement AND
              Is Peer in that domain (See Note 2.).
              If not, goto PMpA.7.

      PMpA.6  Include Hop Count of 1 in SAttributes.  Goto PMpA.9.

      PMpA.7  Increment RAttributes Hop Count and copy the resulting
              Hop Count to SAttributes.  See Note 2.  Goto PMpA.9.

      PMpA.8  Include Hop Count of unknown (0) in SAttributes.

      PMpA.9  Is Loop Detection configured on LSR?
              If not, goto PMpA.21.

      PMpA.10 Do RAttributes have a Path Vector?
              If so, goto PMpA.19.

      PMpA.11 Is LSR propagating a received Label Mapping?
              If not, goto PMpA.20.

      PMpA.12 Does LSR support merging?
              If not, goto PMpA.14.

      PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
              If not, goto PMpA.20.

      PMpA.14 Do RAttributes include a Hop Count?
              If not, goto PMpA.21.

      PMpA.15 Is Hop Count in Rattributes unknown(0)?
              If so, goto PMpA.20.

      PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
              If not goto PMpA.21.

      PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ?
              If not goto PMpA.21.

      PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR
              Is PrevHopCount unknown(0)
              If not, goto PMpA.21.

      PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes
              and copy the resulting Path Vector into SAttributes.
              Goto PMpA.21.

Top      Up      ToC       Page 131 
      PMpA.20 Include Path Vector of length 1 containing LSR Id in
              SAttributes.

      PMpA.21 DONE.

   Notes:

      1. The link with Peer may require that Hop Count be included in
         Label Mapping messages; for example, see [RFC3035] and
         [RFC3034].

      2. If the LSR is at the edge of a cloud of LSRs that do not
         perform TTL-decrement and it is propagating the Label Mapping
         message upstream into the cloud, it sets the Hop Count to 1 so
         that Hop Count across the cloud is calculated properly.  This
         ensures proper TTL management for packets forwarded across the
         part of the LSP that passes through the cloud.

      3. For hop count arithmetic, unknown + 1 = unknown.

Top      Up      ToC       Page 132 
Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.