Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5036

LDP Specification

Pages: 135
Draft Standard
Errata
Obsoletes:  3036
Updated by:  6720679073587552
Part 4 of 5 – Pages 78 to 94
First   Prev   Next

Top   ToC   RFC5036 - Page 78   prevText

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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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   ToC   RFC5036 - 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 page on part 5)

Next Section