Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3036

LDP Specification

Pages: 132
Obsoleted by:  5036
Part 4 of 4 – Pages 89 to 132
First   Prev   None

ToP   noToC   RFC3036 - Page 89   prevText

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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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.