Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5036

LDP Specification

Pages: 135
Draft Standard
Errata
Obsoletes:  3036
Updated by:  6720679073587552
Part 5 of 5 – Pages 95 to 135
First   Prev   None

Top   ToC   RFC5036 - Page 95   prevText

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: . Downstream Unsolicited Independent Control, called PushUnconditional in [RFC3031].
Top   ToC   RFC5036 - Page 96
         .  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 ReleaseOnChange in
            [RFC3031].

         .  Liberal Label retention, called NoReleaseOnChange in
            [RFC3031].

      -  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:
Top   ToC   RFC5036 - Page 97
         .  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 the NotAvailable 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 that 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. 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.
Top   ToC   RFC5036 - Page 98
   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 the Label Request message, if any, propagated to FEC Next Hop. - StoredHopCount. The hop count, if any, previously recorded for the FEC. Algorithm: LRq.1 Execute procedure Check_Received_Attributes (MsgSource, LabelRequest, RAttributes). If Loop Detected, goto LRq.4. LRq.2 Is there a Next Hop for FEC? If not, goto LRq.5.
Top   ToC   RFC5036 - Page 99
      LRq.3   Is MsgSource the Next Hop?
              If not, 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).

               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.
Top   ToC   RFC5036 - Page 100
               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

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

      LRq.13  DONE.
Top   ToC   RFC5036 - Page 101
      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 the 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; - Installation of the newly learned label for forwarding/switching use by the LSR.
Top   ToC   RFC5036 - Page 102
   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 the FEC, if any, previously
         advertised to an upstream peer.  Assuming no label was
         previously advertised, this is the same label as the one in the
         Label Mapping message being processed.

      -  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 the 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.

      LMp.7   Remove Label from forwarding/switching use.  (See Note 5.)
Top   ToC   RFC5036 - Page 103
      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.)
              OR
              Is the received label mapping in response to a previously
              outstanding label request sent to MsgSource?  (See Note
              12.)
              If so, goto LMp.11.

      LMp.10a Is LSR operating in Downstream Unsolicited mode?  If so,
              delete the label mapping for the label previously received
              from MsgSource and remove it from forwarding/switching
              use.
              Execute procedure Send_Message (MsgSource, Label Release,
              FEC, label previously received from MsgSource).

      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.
Top   ToC   RFC5036 - Page 104
      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.

      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).  (See Note 13.)
              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:
Top   ToC   RFC5036 - Page 105
            For Downstream Unsolicited Independent Control OR For
            Downstream Unsolicited Ordered Control

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

               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.
Top   ToC   RFC5036 - Page 106
               4. Goto LMp.31.

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

      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 the 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 the 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) the 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 the LSR is operating in Downstream Unsolicited
          Ordered Control mode.  Ordered Control prevents the LSR from
          advertising a label for the FEC until it has received a label
          mapping from its next hop (MsgSource) for the FEC.

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

      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.

      12. As determined by step LMp.1.

      13. An LSR operating in Ordered Control mode may choose to skip at
          this stage the peer from which it received the advertisement
          that caused it to generate the label-map message.  Doing so
          will in effect provide a form of split-horizon.

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.
Top   ToC   RFC5036 - Page 108
   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.

      -  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 outstanding label requests for this 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.
Top   ToC   RFC5036 - Page 109
      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.

   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 Does FEC match a known FEC? If not, goto LRl.14. LRl.2 Remove MsgSource from record of peers that hold Label for FEC. (See Note 1.) LRl.3 Does message match an outstanding label withdraw for FEC previously sent to MsgSource? If not, goto LRl.5
Top   ToC   RFC5036 - Page 110
      LRl.4   Delete record of outstanding label withdraw for FEC
              previously sent to MsgSource.

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

      LRl.6   Does LSR have outstanding label advertisements for this
              FEC?
              If so, goto LRl.11.

      LRl.7   Is LSR egress for the FEC?
              If so, goto LRl.11.

      LRl.8   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.11.

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

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

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

      LRl.12  Do any peers still hold Label for FEC?
              If so, goto LRl.14.

      LRl.13  Free the Label.

      LRl.14  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.5 through LRl.9 deal with determining whether where the LSR
         should propagate the Label Release to a downstream peer
         (LRl.9).

      3. If LRl.9 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
Top   ToC   RFC5036 - Page 111
         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
         amount of signaling required small, and 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.
Top   ToC   RFC5036 - Page 112
      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.

      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 the 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.
Top   ToC   RFC5036 - Page 113

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; - 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.
Top   ToC   RFC5036 - Page 114
               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.

               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
Top   ToC   RFC5036 - Page 115
            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.

   Notes:

      1. An example of an attribute that might be part of InitAttributes
         is one that 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;
Top   ToC   RFC5036 - Page 116
      -  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.

      -  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 the 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.
Top   ToC   RFC5036 - Page 117
      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 that a label abort request is pending for FEC with
             Old Next Hop.

      NH.10  Is there a New Next Hop for 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.

      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 the Label is not in forwarding/switching use, NH.2 has no
         effect.
Top   ToC   RFC5036 - Page 118
      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 that 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.13 hold.
         Therefore, it executes the Send_Label_Request procedure
         directly rather than perform the LSR Label Request procedure.

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.
Top   ToC   RFC5036 - Page 119
   Note:

      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. - 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 that 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.
Top   ToC   RFC5036 - Page 120
   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.

            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".
Top   ToC   RFC5036 - Page 121
   Note:

      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 the postponed Label Request message. 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.
Top   ToC   RFC5036 - Page 122

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 the 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. 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. Note: 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.
Top   ToC   RFC5036 - Page 123

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 the FEC previously advertised to the Peer. Algorithm: NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, PrevAdvLabel). (See Note 1.) NoLS.2 DONE. Note: 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. If the LSR doesn't wait for the Label Release message from the peer, it SHOULD NOT reuse the label until it receives the Label Release.

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.
Top   ToC   RFC5036 - Page 124
      -  Attributes.  Attributes stored with the 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 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. 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.
Top   ToC   RFC5036 - Page 125
      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).

      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.

   Note:

      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.
Top   ToC   RFC5036 - Page 126
   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

      SLRq.3  Execute procedure Send_Message (Peer, Label Request, FEC,
              Attributes).

      SLRq.4  Record that 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 that label mapping
              for FEC and Attributes from Peer is needed but that no
              label resources are available.

      SLRq.7  Return failure.

   Note:

      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.
Top   ToC   RFC5036 - Page 127

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 that label withdraw for FEC has been sent to Peer and mark it as outstanding.

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.
Top   ToC   RFC5036 - Page 128
   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.

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.
Top   ToC   RFC5036 - Page 129
      -  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).

      CRa.8   Return Loop Detected.

      CRa.9   DONE.

   Note:

      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.
Top   ToC   RFC5036 - Page 130
   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.

      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.
Top   ToC   RFC5036 - Page 131
      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.

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.
Top   ToC   RFC5036 - Page 132
      -  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  Do the RAttributes include any unknown TLVs?
              If not, goto PMpA.4.

      PMpA.2  Do the settings of the U- and F-bits require forwarding of
              these TLVs?
              If not, goto PMpA.4.

      PMpA.3  Copy the unknown TLVs in SAttributes.

      PMpA.4  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.24.

      PMpA.5  Is LSR egress for FEC?
              If not, goto PMpA.7.

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

      PMpA.7  Do RAttributes have a Hop Count?
              If not, goto PMpA.11.

      PMpA.8  Is LSR a member of the 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.10.

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

      PMpA.10 Increment RAttributes Hop Count and copy the resulting Hop
              Count to SAttributes.  (See Note 2.)  Goto PMpA.12.

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

      PMpA.12 Is Loop Detection configured on LSR?
              If not, goto PMpA.24.

      PMpA.13 Do RAttributes have a Path Vector?
              If so, goto PMpA.22.
Top   ToC   RFC5036 - Page 133
      PMpA.14 Is LSR propagating a received Label Mapping?
              If not, goto PMpA.23.

      PMpA.15 Does LSR support merging?
              If not, goto PMpA.17.

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

      PMpA.17 Do RAttributes include a Hop Count?
              If not, goto PMpA.24.

      PMpA.18 Is Hop Count in RAttributes unknown(0)?
              If so, goto PMpA.23.

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

      PMpA.20 Is Hop Count in RAttributes different from PrevHopCount?
              If not, goto PMpA.24.

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

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

      PMpA.23 Include Path Vector of length 1 containing LSR Id in
              SAttributes.

      PMpA.24 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   ToC   RFC5036 - Page 134

Editors' Addresses

Loa Andersson Acreo AB Isafjordsgatan 22 Kista, Sweden EMail: loa.andersson@acreo.se loa@pi.se Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 EMail: ina@juniper.net Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: rhthomas@cisco.com
Top   ToC   RFC5036 - Page 135
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.