[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-thomas-mpls-ldp-capabilities) 00 01 02 03 04 RFC 5561

Network Working Group                                         Bob Thomas
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: August 2008
Intended Status: Proposed Standard                           S. Aggarwal
                                                        Juniper Networks

                                                             R. Aggarwal
                                                        Juniper Networks

                                                            J.L. Le Roux
                                                          France Telecom

                                                           February 2008


                            LDP Capabilities


                draft-ietf-mpls-ldp-capabilities-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.









Thomas, et al.                                                  [Page 1]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


Copyright Notice

   Copyright (C) The IETF TRUST (2008).


Abstract

   A number of enhancements to the Label Distribution Protocol (LDP)
   have been proposed.  Some have been implemented, and some are
   advancing toward standardization.  It is likely that additional
   enhancements will be proposed in the future.  At present LDP has no
   guidelines for advertising such enhancements at LDP session
   initialization time.  There is also no mechanism to enable and
   disable enhancements after the session is established.  This document
   provides guidelines for advertising LDP enhancements at session
   initialization time.  It also defines a mechanism to enable and
   disable enhancements after LDP session establishment.



Table of Contents

  1  Introduction ..................................................  3
  2  Specification Language ........................................  3
  3  The LDP Capability Mechanism ..................................  3
  4  Specifying Capabilities in LDP Messages .......................  5
  5  Capability Message ............................................  6
  6  Note on Terminology ...........................................  7
  7  Procedures for Capability Parameters in Initialization Messages  7
  8  Procedures for Capability Parameters in Capability Messages ...  8
  9  Extensions to Error Handling ..................................  8
 10  Dynamic Capability Announcement TLV ...........................  9
 11  Backward Compatibility ........................................ 10
 12  Security Considerations ....................................... 10
 13  IANA Considerations ........................................... 10
 14  Acknowledgements .............................................. 11
 15  References .................................................... 11
 16  Author Information ............................................ 12
 17  Intellectual Property Statement ............................... 12
 18  Full Copyright Statement ...................................... 13









Thomas, et al.                                                  [Page 2]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


1. Introduction

   A number of enhancements to LDP as specified in [RFC5036] have been
   proposed.  These include LDP Graceful Restart [RFC3478], Fault
   Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for
   layer 2 circuits [RFC4447], a method for learning labels advertised
   by next next hop routers in support of fast reroute node protection
   [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for
   signaling inter-area LSPs [IALDP].  Some have been implemented, and
   some are advancing toward standardization.  It is likely that
   additional enhancements will be proposed in the future.

   At present LDP has no guidelines for advertising such enhancements at
   LDP session initialization time.  There is also no mechanism to
   enable and disable enhancements after the session is established.

   This document provides guidelines for advertising LDP enhancements at
   session initialization time.  It also defines a mechanism to enable
   and disable enhancements after LDP session establishment.

   LDP capability advertisement provides means for an LDP speaker to
   announce what it can receive and process.  It also provides means for
   a speaker to inform peers of deviations from behavior specified by
   [RFC5036].  An example of such a deviation is LDP graceful restart
   where a speaker retains MPLS forwarding state for LDP-signaled LSPs
   when its LDP control plane goes down.  It is important to point out
   that not all LDP enhancements require capability advertisement.  For
   example, upstream label allocation does but inbound label filtering,
   where a speaker installs forwarding state for only certain FECs, does
   not.


2. Specification Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3. The LDP Capability Mechanism

   Enhancements are likely to be announced during LDP session
   establishment as each LDP speaker advertises capabilities
   corresponding to the enhancements it desires.

   Beyond that, capability advertisements may be used to dynamically
   modify the characteristics of the session to suit changing
   conditions.  For example, an LSR capable of a particular enhancement



Thomas, et al.                                                  [Page 3]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


   in support of some "feature" may not have advertised the
   corresponding capability to its peers at session establishment time
   because the feature was disabled at that time.  Later an operator may
   enable the feature, at which time the LSR would react by advertising
   the corresponding capability to its peers.  Similarly, when an
   operator disables a feature associated with a capability the LSR
   reacts by withdrawing the capability advertisement from its peers.

   The LDP capability advertisement mechanism operates as follows:

     - Each LDP speaker is assumed to implement a set of enhancements
       each of which has an associated capability.  At any time a
       speaker may have none, one or more of those enhancements
       "enabled".  When an enhancement is enabled the speaker advertises
       the associated capability to its peers.  By advertising the
       capability to a peer the speaker asserts that it shall perform
       the protocol actions specified for the associated enhancement.
       For example, the actions may involve receiving and processing
       messages from a peer that the enhancement requires.  Unless the
       capability has been advertised the speaker will not perform
       protocol actions specified for the corresponding enhancement.

     - At session establishment time an LDP speaker MAY advertise a
       particular capability by including an optional parameter
       associated with the capability in its Initialization message.

     - There is a well-known capability called Dynamic Capability
       Announcement which an LDP speaker MAY advertise in its
       Initialization message to indicate that it is capable of
       processing capability announcements following session
       establishment.

       If a peer had advertised the Dynamic Capability Announcement
       capability in its Initialization message then at any time
       following session establishment an LDP speaker MAY announce
       changes in its advertised capabilities to that peer.  To do this
       the LDP speaker sends the peer a Capability message that
       specifies the capabilities being advertised or withdrawn.

   When the capability advertisement mechanism is in place an LDP
   enhancement requiring LDP capability advertisement will be specified
   by a document that:

     - Describes the motivation for the enhancement;







Thomas, et al.                                                  [Page 4]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


     - Specifies the behavior of LDP when the enhancement is enabled.
       This includes the procedures, parameters, messages, and TLVs
       required by the enhancement;

     - Includes an IANA considerations section that notes that an IANA-
       assigned code point for the optional parameter corresponding to
       the enhancement is required.


4. Specifying Capabilities in LDP Messages

   This document uses the term "Capability Parameter" to refer to an
   optional parameter that may be included in Initialization and
   Capability messages to advertise a capability.

   The format of a TLV that is a Capability Parameter 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| TLV Code Point            |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |                                               |
      +-+-+-+-+-+-+-+-+       Capability Data                         |
      |                                               +-+-+-+-+-+-+-+-+
      |                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:
     U and F bits:
       As specified in [RFC5036].

     TLV Code Point:
       The TLV type, which identifies a specific capability.  The "IANA
       Considerations" section of [RFC5036] specifies the assignment of
       code points for LDP TLVs.

     S-bit:
       The State Bit indicates whether the sender is advertising or
       withdrawing the capability corresponding to the TLV Code Point.
       The State bit is used as follows:

           1 - The TLV is advertising the capability specified by the
               TLV Code Point.
           0 - The TLV is withdrawing the capability specified by the
               TLV Code Point.

     Capability Data:



Thomas, et al.                                                  [Page 5]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


       Information, if any, about the capability in addition to the TLV
       Code Point required to fully specify the capability.

   An LDP speaker MAY include more than one instance of a Capability
   Parameter (as identified by the TLV Code Point) with different non-
   empty Capability Data in an Initialization or Capability message.
   The method for processing such Capability Parameters is specific to
   the TLV Code Point and MUST be described in the document specifying
   the capability.

   To ensure backward compatibility with existing implementations the
   following TLVs play the role of a Capability Parameter when included
   in Initialization messages:

       - FT Session TLV [RFC3479]

   This document refers to such TLVs as Backward Compatibility TLVs.


5. Capability Message

   The LDP Capability message is used by an LDP speaker subsequent to
   session establishment to announce changes in the state for one or
   more of its capabilities.

   The format of the Capability message 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    Capability (IANA)        |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     TLV_1                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     . . .                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     TLV_N                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where TLV_1 through TLV_N are Capability Parameters.  The S-bit of
   each of the TLVs specifies the new state for the corresponding
   capability.

   Note that Backward Compatibility TLVs (see Section 4) MUST NOT be
   included in Capability messages.




Thomas, et al.                                                  [Page 6]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


6. Note on Terminology

   The sections that follow talk of enabling and disabling capabilities.
   The terminology "enabling (or disabling) a capability" is short hand
   for "advertising (or withdrawing) a capability associated with an
   enhancement".  Bear in mind that it is an LDP enhancement that is
   enabled or disabled and that it is the corresponding capability that
   is advertisted or withdrawn.


7. Procedures for Capability Parameters in Initialization Messages

   An LDP speaker SHOULD NOT include more than one instance of a
   Capability Parameter with the same type and value in an
   Initialization message.  Note, however, that processing multiple
   instances of such a parameter does not require special handling, as
   additional instances do not change the meaning of an announced
   capability.

   The S-bit of a Capability Parameter in an Initialization message MUST
   be 1 and SHOULD be ignored on receipt.  This ensures that any
   Capability Parameter in an Initialization message enables the
   corresponding capability.

   An LDP speaker determines the capabilities enabled by a peer by
   examining the set of of Capability Parameters present in the
   Initialization message received from the peer.

   An LDP speaker MAY use a particular capability with its peer after
   the speaker determines that the peer has enabled that capability.

   These procedures enable an LDP speaker A that advertises a specific
   LDP capability C to establish an LDP session with speaker B that does
   not advertise C.  In this situation whether or not capability C may
   be used for the session depends on the semantics of the enhancement
   associated with C.  If the semantics do not require both A and B
   advertise C to one another then B could use it; that is, A's
   advertisement of C permits B to send messages to A used by the
   enhancement.

   It is the responsibility of the capability designer to specify the
   behavior of an LDP speaker that has enabled a certain enhancement,
   advertised its capability and determines that its peer has not
   advertised the corresponding capability.  The document specifying
   procedures for the capability MUST describe the behavior in this
   situation.  If the specified procedure is to terminate the session
   the LDP speaker SHOULD send a Notification message to the peer before
   terminating the session.  The Status Code in the Status TLV of the



Thomas, et al.                                                  [Page 7]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


   Notification message SHOULD be Unsupported Capability, and the
   message SHOULD contain the unsupported capabilities (see Section 9
   for more details).  In this case the session SHOULD NOT be re-
   established automatically.  How the session is re-established is
   beyond the scope of this document.  It depends on the LDP capability
   and MUST be specified along with the procedures specifying the
   capability.

   An LDP speaker that supports capability advertisement and includes a
   Capability Parameter in its Initialization message SHOULD set the TLV
   U bit to 1.  This ensures that an [RFC5036] compliant peer that does
   not support the capability mechanism will ignore the Capability
   Parameter and allow the session to be established.


8. Procedures for Capability Parameters in Capability Messages

   An LDP speaker MUST NOT send a Capability message to a peer unless
   its peer had advertised the Dynamic Capability Announcement
   capability in its session Initialization message (see Section 10).

   An LDP speaker MAY send a Capability message to a peer if its peer
   had advertised the Dynamic Capability Announcement capability in its
   session Initialization message (see Section 10).

   An LDP speaker determines the capabilities enabled by a peer by
   determining the set of capabilities enabled at session initialization
   (as specified in Section 7) and tracking changes to that set made by
   Capability messages from the peer.

   An LDP speaker that has enabled a particular capability MAY use the
   enhancement corresponding to the capability with a peer after the
   speaker determines that the peer has enabled the capability.


9. Extensions to Error Handling

   This document defines a new LDP status code named Unsupported
   Capability.  The E bit of the Status TLV carried in a Notification
   message that includes this status code SHOULD be set to 0.

   In addition, this document defines a new LDP TLV named Returned TLVs
   TLV that MAY be carried in a Notification message.  The U-bit setting
   for a Returned TLVs TLV in a Notification message SHOULD be 1 and the
   F-bit setting SHOULD be 0.

   When the Status Code in a Notification message is Unsupported
   Capability the message SHOULD specify the capabilities that are



Thomas, et al.                                                  [Page 8]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


   unsupported.  When the Notification message specifies the unsupported
   capabilities it MUST include a Returned TLVs TLV which includes each
   unsupported Capability Parameter.  The Returned TLVs TLV MUST include
   only the Capability Parameters for unsupported capabilities.  In
   addition, the Capability Parameter for each such capability SHOULD be
   encoded as received from the peer.

   When the Status Code in a Notification Message is Unknown TLV the
   message SHOULD specify the TLV that was unknown.  When the
   Notification message specifies the TLV that was unknown it MUST
   include the unknown TLV in a Returned TLVs TLV.


10. Dynamic Capability Announcement TLV

   The Dynamic Capability Announcement TLV is a Capability Parameter.
   Its format 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0| DynCap Announcement (IANA)|            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |
      +-+-+-+-+-+-+-+-+


   The Dynamic Capability Announcement Parameter MAY be included by an
   LDP speaker in an Initialization message to signal its peer that the
   speaker is capable of processing Capability messages.

   An LDP speaker MUST NOT include the Dynamic Capability Announcement
   Parameter in Capability messages sent to its peers.  Once enabled
   during session initialization the Dynamic Capability Announcement
   capability cannot be disabled.

   An LDP speaker that receives a Capability message from a peer that
   includes the Dynamic Capability Announcement Parameter SHOULD
   silently ignore the parameter and process any other Capability
   Parameters in the message.











Thomas, et al.                                                  [Page 9]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


11. Backward Compatibility

   From the point of view of the LDP capability advertisement mechanism
   an [RFC5036] compliant peer has label distribution for IPv4 enabled
   by default.  To ensure compatibility with an [RFC5036] compliant peer
   LDP implementations that support capability advertisement have label
   distribution for IPv4 enabled until it is explicitly disabled and
   MUST assume that their peers do as well.

   Section 3 identifies a set of Backward Compatibility TLVs that may
   appear in Initialization messages in the role of a Capability
   Parameter.  This permits existing LDP enhancements that use an ad hoc
   mechanism for enabling capabilities at sesssion initialization time
   to continue to do so.


12. Security Considerations

   The security considerations described in [RFC5036] that apply to the
   base LDP specification apply to the capability mechanism described in
   this document.


13. IANA Considerations

   This document specifies the following which require code points
   assigned by IANA:

       - LDP message code point for the Capability message.  The authors
         request message type 0x0202 for the Capability message.

       - LDP TLV code point for the Dynamic Capability Announcemnt TLV.
         The authors request TLV type code 0x0506.

       - LDP TLV code point for the Returned TLVs TLV.  The authors
         request TLV type 0x304.

       - LDP Status Code code point for the Unsupported Capability
         Status Code.  The authors request Status Code 0x0000002C.












Thomas, et al.                                                 [Page 10]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


14. Acknowledgements

   The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo,
   Yakov Rekhter, and Eric Rosen for their comments.


15. References

   Normative References

   [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP
   Specification", RFC 5036, September 2007.

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

   [RFC3479] Farrel, A., Editor,  "Fault Tolerance for the Label
   Distribution Protocol (LDP)", RFC 3479, February 2003.


   Informative References

   [IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for
   Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt, Work in
   Progress, March 2007

   [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution Protocol
   Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label
   Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp-00.txt, Work in
   Progress, September 2005

   [NNHOP] Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop
   Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in Progress,
   May 2005

   [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron,
   "Pseudowire Setup and Maintenance using the Label Distribution
   Protocol", RFC 4447, April 2006.

   [RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart
   Mechanism for Label Distribution Protocol (LDP)", RFC 3478, February
   2003.

   [UPSTREAM_LDP] Aggarwal R., Le Roux, J.L.,  "MPLS Upstream Label
   Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt, Work in
   Progress, February 2006.





Thomas, et al.                                                 [Page 11]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


16. Author Information

   Shivani Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: shivani@juniper.net

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: rahul@juniper.net

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   E-mail: jeanlouis.leroux@orange_ftgroup.com

   Bob Thomas
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough MA 01719
   E-mail: rhthomas@cisco.com


17. Intellectual Property Statement

   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.






Thomas, et al.                                                 [Page 12]

Internet Draft  draft-ietf-mpls-ldp-capabilities-01.txt    February 2008


   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.


18. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.




























Thomas, et al.                                                 [Page 13]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/