tech-invite   World Map     

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

RFC 5036

 
 
 

LDP Specification

Part 4 of 5, p. 78 to 94
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 78 
3.6.  Messages and TLVs for Extensibility

   Support for LDP extensibility includes the rules for the U- and F-
   bits that specify how an LSR handles unknown TLVs and messages.

   This section specifies TLVs and messages for vendor-private and
   experimental use.

3.6.1.  LDP Vendor-Private Extensions

   Vendor-private TLVs and messages are used to convey vendor-private
   information between LSRs.

3.6.1.1.  LDP Vendor-Private TLVs

   The Type range 0x3E00 through 0x3EFF is reserved for vendor-private
   TLVs.

   The encoding for a vendor-private TLV is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|    Type (0x3E00-0x3EFF)   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Vendor ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           Data....                            |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U-bit
      Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
      (=0), a notification MUST be returned to the message originator
      and the entire message MUST be ignored; if U is set (=1), the
      unknown TLV is silently ignored and the rest of the message is
      processed as if the unknown TLV did not exist.

Top      Up      ToC       Page 79 
      The determination as to whether a vendor-private message is
      understood is based on the Type and the mandatory Vendor ID field.

      Implementations that support vendor-private TLVs MUST support a
      user-accessible configuration interface that causes the U-bit to
      be set on all transmitted vendor-private TLVs; this requirement
      MAY be satisfied by a user-accessible configuration interface that
      prevents transmission of all vendor-private TLVs for which the U-
      bit is clear.

   F-bit
      Forward unknown TLV bit.  This bit only applies when the U-bit is
      set and the LDP message containing the unknown TLV is to be
      forwarded.  If F is clear (=0), the unknown TLV is not forwarded
      with the containing message; if F is set (=1), the unknown TLV is
      forwarded with the containing message.

   Type
      Type value in the range 0x3E00 through 0x3EFF.  Together, the Type
      and Vendor ID field specify how the Data field is to be
      interpreted.

   Length
      Specifies the cumulative length in octets of the Vendor ID and
      Data fields.

   Vendor ID
      802 Vendor ID as assigned by the IEEE.

   Data
      The remaining octets after the Vendor ID in the Value field are
      optional vendor-dependent data.

Top      Up      ToC       Page 80 
3.6.1.2.  LDP Vendor-Private Messages

   The Message Type range 0x3E00 through 0x3EFF is reserved for Vendor-
   Private messages.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|    Msg Type (0x3E00-0x3EFF) |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Vendor ID                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +                                                               +
   |                     Remaining Mandatory Parameters            |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     Optional Parameters                       |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U-bit
      Unknown message bit.  Upon receipt of an unknown message, if U is
      clear (=0), a notification is returned to the message originator;
      if U is set (=1), the unknown message is silently ignored.

      The determination as to whether a Vendor-Private message is
      understood is based on the Msg Type and the Vendor ID parameter.

      Implementations that support Vendor-Private messages MUST support
      a user-accessible configuration interface that causes the U-bit to
      be set on all transmitted Vendor-Private messages; this
      requirement MAY be satisfied by a user-accessible configuration
      interface that prevents transmission of all Vendor-Private
      messages for which the U-bit is clear.

   Msg Type
      Message Type value in the range 0x3E00 through 0x3EFF.  Together,
      the Msg Type and the Vendor ID specify how the message is to be
      interpreted.

Top      Up      ToC       Page 81 
   Message Length
      Specifies the cumulative length in octets of the Message ID,
      Vendor ID, Remaining Mandatory Parameters, and Optional
      Parameters.

   Message ID
      32-bit integer used to identify this message.  Used by the sending
      LSR to facilitate identifying Notification messages that may apply
      to this message.  An LSR sending a Notification message in
      response to this message will include this Message ID in the
      notification message; see Section "Notification Message".

   Vendor ID
      802 Vendor ID as assigned by the IEEE.

   Remaining Mandatory Parameters
      Variable length set of remaining required message parameters.

   Optional Parameters
      Variable length set of optional message parameters.

3.6.2.  LDP Experimental Extensions

   LDP support for experimentation is similar to support for vendor-
   private extensions with the following differences:

      -  The Type range 0x3F00 through 0x3FFF is reserved for
         experimental TLVs.

      -  The Message Type range 0x3F00 through 0x3FFF is reserved for
         experimental messages.

      -  The encodings for experimental TLVs and messages are similar to
         the vendor-private encodings with the following difference.

         Experimental TLVs and messages use an Experiment ID field in
         place of a Vendor ID field.  The Experiment ID field is used
         with the Type or Message Type field to specify the
         interpretation of the experimental TLV or Message.

         Administration of Experiment IDs is the responsibility of the
         experimenters.

3.7.  Message Summary

   The following are the LDP messages defined in this version of the
   protocol.

Top      Up      ToC       Page 82 
      Message Name            Type     Section Title

      Notification            0x0001   "Notification Message"
      Hello                   0x0100   "Hello Message"
      Initialization          0x0200   "Initialization Message"
      KeepAlive               0x0201   "KeepAlive Message"
      Address                 0x0300   "Address Message"
      Address Withdraw        0x0301   "Address Withdraw Message"
      Label Mapping           0x0400   "Label Mapping Message"
      Label Request           0x0401   "Label Request Message"
      Label Withdraw          0x0402   "Label Withdraw Message"
      Label Release           0x0403   "Label Release Message"
      Label Abort Request     0x0404   "Label Abort Request Message"
      Vendor-Private          0x3E00-  "LDP Vendor-Private Extensions"
                              0x3EFF
      Experimental            0x3F00-  "LDP Experimental Extensions"
                              0x3FFF

3.8.  TLV Summary

   The following are the TLVs defined in this version of the protocol.

      TLV                      Type      Section Title

      FEC                      0x0100    "FEC TLV"
      Address List             0x0101    "Address List TLV"
      Hop Count                0x0103    "Hop Count TLV"
      Path Vector              0x0104    "Path Vector TLV"
      Generic Label            0x0200    "Generic Label TLV"
      ATM Label                0x0201    "ATM Label TLV"
      Frame Relay Label        0x0202    "Frame Relay Label TLV"
      Status                   0x0300    "Status TLV"
      Extended Status          0x0301    "Notification Message"
      Returned PDU             0x0302    "Notification Message"
      Returned Message         0x0303    "Notification Message"
      Common Hello             0x0400    "Hello Message"
         Parameters
      IPv4 Transport Address   0x0401    "Hello Message"
      Configuration            0x0402    "Hello Message"
         Sequence Number
      IPv6 Transport Address   0x0403    "Hello Message"
      Common Session           0x0500    "Initialization Message"
         Parameters
      ATM Session Parameters   0x0501    "Initialization Message"
      Frame Relay Session      0x0502    "Initialization Message"
         Parameters
      Label Request            0x0600    "Label Mapping Message"
          Message ID

Top      Up      ToC       Page 83 
      Vendor-Private           0x3E00-   "LDP Vendor-Private Extensions"
                               0x3EFF
      Experimental             0x3F00-   "LDP Experimental Extensions"
                               0x3FFF

3.9.  Status Code Summary

   The following are the Status Codes defined in this version of the
   protocol.

   The "E" column is the required setting of the Status Code E-bit; the
   "Status Data" column is the value of the 30-bit Status Data field in
   the Status Code TLV.  Note that the setting of the Status Code F-bit
   is at the discretion of the LSR originating the Status TLV.

      Status Code           E   Status Data   Section Title

      Success               0   0x00000000    "Status TLV"
      Bad LDP Identifier    1   0x00000001    "Events Signaled by ..."
      Bad Protocol Version  1   0x00000002    "Events Signaled by ..."
      Bad PDU Length        1   0x00000003    "Events Signaled by ..."
      Unknown Message Type  0   0x00000004    "Events Signaled by ..."
      Bad Message Length    1   0x00000005    "Events Signaled by ..."
      Unknown TLV           0   0x00000006    "Events Signaled by ..."
      Bad TLV Length        1   0x00000007    "Events Signaled by ..."
      Malformed TLV Value   1   0x00000008    "Events Signaled by ..."
      Hold Timer Expired    1   0x00000009    "Events Signaled by ..."
      Shutdown              1   0x0000000A    "Events Signaled by ..."
      Loop Detected         0   0x0000000B    "Loop Detection"
      Unknown FEC           0   0x0000000C    "FEC Procedures"
      No Route              0   0x0000000D    "Label Request Mess ..."
      No Label Resources    0   0x0000000E    "Label Request Mess ..."
      Label Resources /     0   0x0000000F    "Label Request Mess ..."
          Available
      Session Rejected/     1   0x00000010    "Session Initialization"
         No Hello
      Session Rejected/     1   0x00000011    "Session Initialization"
         Parameters Advertisement Mode
      Session Rejected/     1   0x00000012    "Session Initialization"
         Parameters Max PDU Length
      Session Rejected/     1   0x00000013    "Session Initialization"
         Parameters Label Range
      KeepAlive Timer       1   0x00000014    "Events Signaled by ..."
          Expired
      Label Request Aborted 0   0x00000015    "Label Abort Request ..."
      Missing Message       0   0x00000016    "Events Signaled by ..."
          Parameters

Top      Up      ToC       Page 84 
      Unsupported Address   0   0x00000017    "FEC Procedures"
          Family                              "Address Message Proc ..."
      Session Rejected/     1   0x00000018    "Session Initialization"
         Bad KeepAlive Time
      Internal Error        1   0x00000019    "Events Signaled by ..."

3.10.  Well-Known Numbers

3.10.1.  UDP and TCP Ports

   The UDP port for LDP Hello messages is 646.

   The TCP port for establishing LDP session connections is 646.

3.10.2.  Implicit NULL Label

   The Implicit NULL label is defined in [RFC3031] as follows:

   "The Implicit NULL label is a label with special semantics which an
   LSR can bind to an address prefix.  If LSR Ru, by consulting its ILM
   (Incoming Label Map) sees that labeled packet P must be forwarded
   next to Rd, but that Rd has distributed a binding of Implicit NULL to
   the corresponding address prefix, then instead of replacing the value
   of the label on top of the label stack, Ru pops the label stack, and
   then forwards the resulting packet to Rd."

   The implicit NULL label is represented in LDP as a Generic Label TLV
   with a Label field value of 3, as defined in [RFC3032].

4.  IANA Considerations

   LDP defines the following name spaces that require management:

      -  Message Type Name Space
      -  TLV Type Name Space
      -  FEC Type Name Space
      -  Status Code Name Space
      -  Experiment ID Name Space

   The following sections provide guidelines for managing these name
   spaces.

4.1.  Message Type Name Space

   LDP divides the name space for message types into three ranges.  The
   following are the guidelines for managing these ranges:

Top      Up      ToC       Page 85 
      -  Message Types 0x0000 - 0x3DFF.  Message types in this range are
         part of the LDP base protocol.  Following the policies outlined
         in [IANA], Message types in this range are allocated through an
         IETF Consensus action.

      -  Message Types 0x3E00 - 0x3EFF.  Message types in this range are
         reserved for Vendor-Private extensions and are the
         responsibility of the individual vendors (see Section "LDP
         Vendor-Private Messages").  IANA management of this range of
         the Message Type Name Space is unnecessary.

      -  Message Types 0x3F00 - 0x3FFF.  Message types in this range are
         reserved for Experimental extensions and are the responsibility
         of the individual experimenters (see Sections "LDP Experimental
         Extensions" and "Experiment ID Name Space").  IANA management
         of this range of the Message Type Name Space is unnecessary;
         however, IANA is responsible for managing part of the
         Experiment ID Name Space (see below).

4.2.  TLV Type Name Space

   LDP divides the name space for TLV types into three ranges.  The
   following are the guidelines for managing these ranges:

      -  TLV Types 0x0000 - 0x3DFF.  TLV types in this range are part of
         the LDP base protocol.  Following the policies outlined in
         [IANA], TLV types in this range are allocated through an IETF
         Consensus action.

      -  TLV Types 0x3E00 - 0x3EFF.  TLV types in this range are
         reserved for Vendor-Private extensions and are the
         responsibility of the individual vendors (see Section "LDP
         Vendor-Private TLVs").  IANA management of this range of the
         TLV Type Name Space is unnecessary.

      -  TLV Types 0x3F00 - 0x3FFF.  TLV types in this range are
         reserved for Experimental extensions and are the responsibility
         of the individual experimenters (see Sections "LDP Experimental
         Extensions" and "Experiment ID Name Space").  IANA management
         of this range of the TLV Name Space is unnecessary; however,
         IANA is responsible for managing part of the Experiment ID Name
         Space (see below).

4.3.  FEC Type Name Space

   The range for FEC types is 0 - 255.

Top      Up      ToC       Page 86 
   Following the policies outlined in [IANA], FEC types in the range 0 -
   127 are allocated through an IETF Consensus action, types in the
   range 128 - 191 are allocated as First Come First Served, and types
   in the range 192 - 255 are reserved for Private Use.

4.4.  Status Code Name Space

   The range for Status Codes is 0x00000000 - 0x3FFFFFFF.

   Following the policies outlined in [IANA], Status Codes in the range
   0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus
   action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as
   First Come First Served, and codes in the range 0x3F000000 -
   0x3FFFFFFF are reserved for Private Use.

4.5.  Experiment ID Name Space

   The range for Experiment IDs is 0x00000000 - 0xffffffff.

   Following the policies outlined in [IANA], Experiment IDs in the
   range 0x00000000 - 0xefffffff are allocated as First Come First
   Served and Experiment IDs in the range 0xf0000000 - 0xffffffff are
   reserved for Private Use.

5.  Security Considerations

   This section identifies threats to which LDP may be vulnerable and
   discusses means by which those threats might be mitigated.

5.1.  Spoofing

   There are two types of LDP communication that could be the target of
   a spoofing attack.

   1. Discovery exchanges carried by UDP

      LSRs indicate their willingness to establish and maintain LDP
      sessions by periodically sending Hello messages.  Receipt of a
      Hello serves to create a new "Hello adjacency", if one does not
      already exist, or to refresh an existing one.  Spoofing a Hello
      packet for an existing adjacency can cause the adjacency to time
      out and that can result in termination of the associated session.
      This can occur when the spoofed Hello specifies a small Hold Time,
      causing the receiver to expect Hellos within this interval, while
      the true neighbor continues sending Hellos at the lower,
      previously agreed to, frequency.

Top      Up      ToC       Page 87 
      LSRs directly connected at the link level exchange Basic Hello
      messages over the link.  The threat of spoofed Basic Hellos can be
      reduced by:

         o  Accepting Basic Hellos only on interfaces to which LSRs that
            can be trusted are directly connected.

         o  Ignoring Basic Hellos not addressed to the All Routers on
            this Subnet multicast group.

      LSRs not directly connected at the link level may use Extended
      Hello messages to indicate willingness to establish an LDP
      session.  An LSR can reduce the threat of spoofed Extended Hellos
      by filtering them and accepting only those originating at sources
      permitted by an access list.

   2. Session communication carried by TCP

      LDP specifies use of the TCP MD5 Signature Option to provide for
      the authenticity and integrity of session messages.

      [RFC2385] asserts that MD5 authentication is now considered by
      some to be too weak for this application.  It also points out that
      a similar TCP option with a stronger hashing algorithm (it cites
      SHA-1 as an example) could be deployed.  To our knowledge, no such
      TCP option has been defined and deployed.  However, we note that
      LDP can use whatever TCP message digest techniques are available,
      and when one stronger than MD5 is specified and implemented,
      upgrading LDP to use it would be relatively straightforward.

5.2.  Privacy

   LDP provides no mechanism for protecting the privacy of label
   distribution.

   The security requirements of label distribution protocols are
   essentially identical to those of the protocols that distribute
   routing information.  By providing a mechanism to ensure the
   authenticity and integrity of its messages, LDP provides a level of
   security that is at least as good as, though no better than, that
   which can be provided by the routing protocols themselves.  The more
   general issue of whether privacy should be required for routing
   protocols is beyond the scope of this document.

   One might argue that label distribution requires privacy to address
   the threat of label spoofing.  However, that privacy would not
   protect against label spoofing attacks since data packets carry

Top      Up      ToC       Page 88 
   labels in the clear.  Furthermore, label spoofing attacks can be made
   without knowledge of the FEC bound to a label.

   To avoid label spoofing attacks, it is necessary to ensure that
   labeled data packets are labeled by trusted LSRs and that the labels
   placed on the packets are properly learned by the labeling LSRs.

5.3.  Denial of Service

   LDP provides two potential targets for Denial of Service (DoS)
   attacks:

   1. Well-known UDP Port for LDP Discovery

      An LSR administrator can address the threat of DoS attacks via
      Basic Hellos by ensuring that the LSR is directly connected only
      to peers that can be trusted to not initiate such an attack.
      Interfaces to peers interior to the administrator's domain should
      not represent a threat since interior peers are under the
      administrator's control.  Interfaces to peers exterior to the
      domain represent a potential threat since exterior peers are not.
      An administrator can reduce that threat by connecting the LSR only
      to exterior peers that can be trusted to not initiate a Basic
      Hello attack.

      DoS attacks via Extended Hellos are potentially a more serious
      threat.  This threat can be addressed by filtering Extended Hellos
      using access lists that define addresses with which Extended
      Discovery is permitted.  However, performing the filtering
      requires LSR resource.

      In an environment where a trusted MPLS cloud can be identified,
      LSRs at the edge of the cloud can be used to protect interior LSRs
      against DoS attacks via Extended Hellos by filtering out Extended
      Hellos originating outside of the trusted MPLS cloud, accepting
      only those originating at addresses permitted by access lists.
      This filtering protects LSRs in the interior of the cloud but
      consumes resources at the edges.

   2. Well-known TCP port for LDP Session Establishment

      Like other control plane protocols that use TCP, LDP may be the
      target of DoS attacks, such as SYN attacks.  LDP is no more or
      less vulnerable to such attacks than other control plane protocols
      that use TCP.

      The threat of such attacks can be mitigated somewhat by the
      following:

Top      Up      ToC       Page 89 
         o  An LSR SHOULD avoid promiscuous TCP listens for LDP session
            establishment.  It SHOULD use only listens that are specific
            to discovered peers.  This enables it to drop attack packets
            early in their processing since they are less likely to
            match existing or in-progress connections.

         o  The use of the MD5 option helps somewhat since it prevents a
            SYN from being accepted unless the MD5 segment checksum is
            valid.  However, the receiver must compute the checksum
            before it can decide to discard an otherwise acceptable SYN
            segment.

         o  The use of access list mechanisms applied at the boundary of
            the MPLS cloud in a manner similar to that suggested above
            for Extended Hellos can protect the interior against attacks
            originating from outside the cloud.

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 (Class of Service) 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.

      -  LDP support for signaling the maximum transmission unit is not
         specified in this version.  It is discussed in the experimental
         document [LDP-MTU].

      -  The current specification does not address basic peer discovery
         on Non-Broadcast Multi-Access (NBMA) media.  The solution
         available in the current specification is to use extended peer

Top      Up      ToC       Page 90 
         discovery in such setups.  The issue of defining a mechanism
         semantically similar to Basic Discovery (1 hop limit, bind the
         hello adjacency to an interface) that uses preconfigured
         neighbor addresses is left for further study.

      -  The current specification does not support shutting down an
         adjacency.  The motivation for doing it and the mechanisms for
         achieving it are left for further study.

      -  The current specification does not include a method for
         securing Hello messages, to detect spoofing of Hellos.  The
         scenarios where this is necessary, as well as the mechanism for
         achieving it are left for future study.

      -  The current specification does not have the ability to detect a
         stateless fast control plane restart.  The method for achieving
         this, possibly through an "incarnation/instance" number carried
         in the Hello message, is left for future study.

      -  The current specification does not support an "end of LIB"
         message, analogous to BGP's "end of RIB" message that an LDP
         LSR (operating in DU mode) would use following session
         establishment.  The discussion on the need for such a mechanism
         and its implementation is left for future study.

      -  The current specification does not deal with situations where
         different LSRs advertise the same address.  Such situations
         typically occur as the result of configuration errors, and the
         goal in this case is to provide the LSRs advertising the same
         address with enough information to enable operators to take
         corrective action.  The specification of this mechanism is left
         for a separate document.

7.  Changes from RFC 3036

   Here is a list of changes from RFC 3036

       1. Removed the Host Address FEC and references to it, since it is
          not used by any implementation.

       2. Split the reference list into normative and informative
          references

       3. Removed "MPLS using ATM VP Switching" from the list of
          normative references, and references to it.

        4. Removed reference to RFC 1700 and replaced it with a link to
          http://www.iana.org/assignments/address-family-numbers.

Top      Up      ToC       Page 91 
       5. Removed reference to RFC 1771 and replaced it with a reference
          to RFC 4271.

       6. Clarified the use of the F-bit.

       7. Added option to allow split horizon when doing Ordered
          Control.

       8. Clarified the processing of messages with the U-bit set during
          the session initialization procedures

       9. Clarified the processing of the E-bit during session
          initialization procedures.

      10. Added text explaining that the Shutdown message in the state
          transition diagram is implemented as a notification message
          with a Status TLV indicating a fatal error.

      11. Added case for TLV length too short in the specification for
          handling malformed TLVs.

      12. Explained the security threat posed by hello spoofing.

      13. Added reference to 4271 and 4278 and text for standards
          maturity variance with regards to the MD5 option.

      14. Added text from 3031 explaining the handling of implicit NULL
          label.

      15. Included the encoding of DLCIs to remove normative reference
          to 3034.

      16. Moved references to 3031, 3032, and 3034 to informative.

      17. In the section describing handling of unknown TLV, removed
          reference to inexistent section (errata in original document).

      18. Added text clarifying how to achieve interoperability when
          sending vendor-private TLVs and messages.

      19. In the "receive label request" procedures, if a loop is
          detected, changed the procedure to send a notification before
          aborting the rest of the processing.

      20. In "receive label release" procedures, clarified the behavior
          for merge-capable LSRs.

Top      Up      ToC       Page 92 
      21. In "receive label release" procedures, clarified the behavior
          for receipt of an unknown FEC.

      22. In note 4 of "Detect Change in FEC Next Hop", modified the
          text to reference the correct set of conditions for sending a
          label request procedure (typo in the original document).

      23. In the procedures for "LSR decides to no longer label switch a
          FEC", clarified the fact that the label must not be reused
          until a label release is received.

      24. In the routine "Prepare_Label_Mapping_Attributes", added a
          note regarding the treatment of unknown TLVs according to
          their U and F-bits.

      25. In the Address message processing procedures, clarified the
          behavior for the case where an LSR receives re-advertisement
          of an address previously advertised it, or withdrawal of an
          address from an LSR that has not previously advertised that
          address.

      26. In the routine "Receive Label Mapping", clarified the meaning
          of PrevAdvLabel when no label advertisement message has been
          sent previously.

      27. In the "Receive Label Mapping" procedures, if a loop is
          detected, modified the procedure to send a notification before
          aborting the rest of the processing.

      28. In the "Receive Label Mapping" procedures, corrected step
          LMp.10 to handle label mapping messages for additional (non-
          merged) LSPs for the FEC.

      29. In the "Receive Label Mapping" procedures, clarified behavior
          when receiving a duplicate label for the same FEC.

      30. In the routine "Receive Label Abort Request", clarified the
          behavior for non-merging LSRs.

      31. Added the following items to the section discussing areas for
          future study:

         o  extensions for communicating the maximum transmission unit
         o  basic peer discovery on NBMA media
         o  option of shutting down an adjacency
         o  mechanisms for securing Hello messages
         o  detection of a stateless fast control plane restart
         o  support of "end of LIB" message

Top      Up      ToC       Page 93 
         o  mechanisms for dealing with the case where different LSRs
            advertise the same address

8.  Acknowledgments

   This document is produced as part of advancing the LDP specification
   to draft standard status.  This document was originally published as
   RFC 3036 in January 2001.  It was produced by the MPLS Working Group
   of the IETF and was jointly authored by Loa Andersson, Paul Doolan,
   Nancy Feldman, Andre Fredette, and Bob Thomas.

   The ideas and text in RFC 3036 were 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 for their input for RFC 3036.

   The editors would like to thank Eric Gray, David Black, and Sam
   Hartman for their input to and review of the current document.

   In addition, the editors would like to thank the members of the MPLS
   Working Group for their ideas and the support they have given to this
   document, and in particular, to Eric Rosen, Luca Martini, Markus
   Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama
   Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis.

9.  References

9.1.  Normative References

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

   [ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers

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

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

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

Top      Up      ToC       Page 94 
   [RFC3037]     Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
                 January 2001.

9.2.  Informative References

   [CRLDP]       Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu,
                 R., Wu, L., Doolan, P., Worster, T., Feldman, N.,
                 Fredette, A., Girish, M., Gray, E., Heinanen, J.,
                 Kilty, T., and A. Malis, "Constraint-Based LSP Setup
                 using LDP", RFC 3212, January 2002.

   [LDP-MTU]     Black, B. and K. Kompella, "Maximum Transmission Unit
                 Signalling Extensions for the Label Distribution
                 Protocol", RFC 3988, January 2005.

   [RFC2328]     Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
                 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., Tappan, D., Fedorkow, G., Rekhter, Y.,
                 Farinacci, D., 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.

   [RFC4271]     Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
                 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
                 2006.

   [RFC4278]      Bellovin, S. and A. Zinin, "Standards Maturity
                 Variance Regarding the TCP MD5 Signature Option (RFC
                 2385) and the BGP-4 Specification", RFC 4278, January
                 2006.


Next RFC Part