Internet DRAFT - draft-ietf-mpls-ldp-capabilities

draft-ietf-mpls-ldp-capabilities




Network Working Group                                        Bob Thomas 
Internet Draft                                       Cisco Systems, Inc. 
Updates: 5036 
Intended Status: Proposed Standard                          S. Aggarwal 
Expiration Date: October 22, 2009                      Juniper Networks 
                                         
                                                             R. Aggarwal 
                                                        Juniper Networks 
 
                                                            J.L. Le Roux 
                                                          France Telecom 
                                    
                                                       Syed Kamran Raza 
                                                    Cisco Systems, Inc. 
 
                                                         April 23, 2009 
                                      
                             LDP Capabilities 
                                      
                  draft-ietf-mpls-ldp-capabilities-04.txt 


Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and BCP 79.  This document may contain material 
   from IETF Documents or IETF Contributions published or made publicly 
   available before November 10, 2008.  The person(s) controlling the 
   copyright in some of this material may not have granted the IETF 
   Trust the right to allow modifications of such material outside the 
   IETF Standards Process.  Without obtaining an adequate license from 
   the person(s) controlling the copyright in such materials, this 
   document may not be modified outside the IETF Standards Process, and 
   derivative works of it may not be created outside the IETF Standards 
   Process, except to format it for publication as an RFC or to 
   translate it into languages other than English.  

   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.         

 
 
 
Thomas, et al.           Expires October 2009                  [Page 1] 
      







Internet-Draft             LDP Capabilities                  April 2009 
    

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

   This Internet-Draft will expire on October 22, 2009. 

Copyright 

  Copyright (c) 2009 IETF Trust and the persons identified as the 
  document authors.  All rights reserved. 
  This document is subject to BCP 78 and the IETF Trust's Legal 
  Provisions Relating to IETF Documents in effect on the date of 
  publication of this document (http://trustee.ietf.org/license-info). 
  Please review these documents carefully, as they describe your rights 
  and restrictions with respect to this document. 
   
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. This document defines a 
   mechanism for advertising LDP enhancements at session initialization 
   time, as well as a mechanism to enable and disable enhancements after 
   LDP session establishment. 

Conventions used in this document 

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

   This document uses the terms "LDP speaker" and "speaker" 
   interchangably. 

Table of Contents 

   1. Introduction...................................................3 
   2. The LDP Capability Mechanism...................................4 
      2.1. Capability Document.......................................5 
   3. Specifying Capabilities in LDP Messages........................5 
      3.1. Backward Compatibility TLVs...............................7 
   4. Capability Message.............................................7 
   5. Note on Terminology............................................8 
   6. Procedures for Capability Parameters in Initialization Messages8 
   7. Procedures for Capability Parameters in Capability Messages...10 

 
Thomas, et al.           Expires October 2009                  [Page 2] 
    







Internet-Draft             LDP Capabilities                  April 2009 
    

   8. Extensions to Error Handling..................................10 
   9. Dynamic Capability Announcement TLV...........................11 
   10. Backward Compatibility.......................................11 
   11. Security Considerations......................................12 
   12. IANA Considerations..........................................12 
   13. Acknowledgments..............................................12 
   14. References...................................................13 
      14.1. Normative References....................................13 
      14.2. Informative References..................................13 
   15. Author's Addresses...........................................14 
    
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 also likely that 
  additional enhancements will be implemented and deployed in the 
  future. 
   
  This document proposes and defines a mechanism for advertising LDP 
  enhancements at session initialization time.  It also defines a 
  mechanism to enable and disable these 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 deviationts 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. 




 
 
Thomas, et al.           Expires October 2009                  [Page 3] 
    







Internet-Draft             LDP Capabilities                  April 2009 
    

2. 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 the changing 
  conditions.  For example, an LSR capable of a particular enhancement 
  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 require the LDP speaker 
      to receive and process enhancement-specific messages from its 
      peer. 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 


 
 
Thomas, et al.           Expires October 2009                  [Page 4] 
    







Internet-Draft             LDP Capabilities                  April 2009 
    

      processing capability announcements following a 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. 
       
2.1. Capability Document 

  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; 
      
     - 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 requests IANA 
      assignment of a code point (from TLV Type namespace) for the 
      optional capability parameter corresponding to the enhancement. 
      
       The capability document MUST also describe the interpretation and 
     processing of associated capability data, if present.  
      
3. 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 "Capability Parameter" TLV is as follows: 
   
   
   
   
   

 
 
Thomas, et al.           Expires October 2009                  [Page 5] 
    







Internet-Draft             LDP Capabilities                  April 2009 
    

      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-bit: 
       Unknown TLV bit, as described in [RFC5036]. The value could be 
       either 0 or 1 as specified in Capability document associated 
       with given capability.  
 
     F-bit: 
       Forward unknown TLV bit, as described in [RFC5036]. The value of 
       this bit MUST be 0 since a Capability Paramter TLV is sent only 
       in Initialization and Capability messages which are not 
       forwarded. 
   
     TLV Code Point: 
         The TLV type which identifies a specific capability. This is 
       IANA assigned code point (from TLV Type namespace) for given 
       capability as requested in the associated capability document. 
   
     S-bit: 
       The State Bit. It indicates whether the sender is advertising or 
       withdrawing the capability corresponding to the TLV Code Point. 
       The State bit value 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: 
       Information, if any, about the capability in addition to the TLV 
       Code Point required to fully specify the capability. 
 
 
Thomas, et al.           Expires October 2009                  [Page 6] 
    






Internet-Draft             LDP Capabilities                  April 2009 
    

       The method for interpreting and processing this data is specific 
       to the TLV Code Point and MUST be described in the document 
       specifying the capability. 
   
  An LDP speaker MUST NOT include more than one instance of a 
  Capability Parameter (as identified by the same TLV code point) in an 
  Initialization or Capability message. If an LDP speaker receives more 
  than one instance of the same Capability Parameter type in a message, 
  it SHOULD send a Notification message to peer before terminating the 
  session with peer. The Status Code in the Status TLV of the 
  Notification message MUST be Malformed TLV, and the message SHOULD 
  contain the second Capability Parameter TLV of the same type (Code 
  point) that is received in the message. 
   
3.1. Backward Compatibility TLVs 

  LDP extensions that require advertisement or negotiation of some 
  capability at session establishment time typically use TLVs that are 
  included in an Initialization message. To ensure backward 
  compatibility with existing implementations, such TLVs continue to be 
  supported in an Initialization message and are known in this document 
  as "Backward Compatibility TLVs". A Backward Compatibility TLV plays 
  the role of a "Capability Parameter" TLV; that is the presence of a 
    Backward Compatibility TLV has the same meaning as a Capability 
  Parameter TLV with the S bit set for the same capability. 
   
  One example of a Backward Capability TLV is the "FT Session TLV" that 
  is exchanged in an Initialization message between peers to announce 
  LDP Fault Tolerance [RFC3479] capability. 
   
4. Capability Message 

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

 
 
Thomas, et al.           Expires October 2009                  [Page 7] 
    







Internet-Draft             LDP Capabilities                  April 2009 
    

       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 Parameter TLVs.  The S-bit 
  of each of the TLVs specifies the new state for the corresponding 
  capability. 
   
  Note that Backward Compatibility TLVs (see Section 3.1. ) MUST NOT be 
  included in Capability messages. 
   
  5. Note on Terminology 

  The following sections in this document talk about 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 being enabled or disabled, and that it is 
  the corresponding capability that is being advertisted or withdrawn. 
   
6. Procedures for Capability Parameters in Initialization Messages 

  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 of a peer by examining the 
  set of of Capability Parameters present in the Initialization message 
  received from the peer. 
   

 
 
Thomas, et al.           Expires October 2009                  [Page 8] 
    






Internet-Draft             LDP Capabilities                  April 2009 
    

  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 S1, that advertises a specific 
  LDP capability C, to establish an LDP session with speaker S2 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 
  S1 and S2 advertise C to one another, then S2 could use it; i.e. S1's 
  advertisement of C permits S2 to send messages to S1 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, 
  then the LDP speaker SHOULD send a Notification message to the peer 
  before terminating the session.  The Status Code in the Status TLV 
  of the Notification message MUST be Unsupported Capability, and the 
  message SHOULD contain the unsupported capability (see Section 8.  
  for more details). 
   
  An LDP speaker that supports capability advertisement and includes a 
  Capability Parameter in its Initialization message MUST set the TLV 
  U-bit to 0 or 1, as specified by Capability document.  LDP speaker 
  should set U-bit to 1 if the capability document allows to continue 
  with a peer that does not understand the enhancement, and set U-bit 
  to 0 otherwise. If a speaker receives a message containng unsupported 
  capability, it responds according to U-bit setting in the TLV. If U-
  bit is 1, then speaker MUST silently ignore the Capability Parameter 
  and allow the session to be established. However, if U-bit is 0, then 
  speaker SHOULD send a Notification message to the peer before 
  terminating the session.  The Status Code in the Status TLV of the 
  Notification message MUST be Unsupported Capability, and the 
  message SHOULD contain the unsupported capability (see Section 8.  
  for more details). 
 



 
 
Thomas, et al.           Expires October 2009                  [Page 9] 
    






Internet-Draft             LDP Capabilities                  April 2009 
    

7. 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.  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 9. ). 
   
  An LDP speaker determines the capabilities enabled by a peer by 
  determining the set of capabilities enabled at session initialization 
  (as specified in Section 6. ) 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. 
     
8. 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 MUST be set to 0. 
   
  In addition, this document defines a new LDP TLV, named Returned 
  TLVs, 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 
  unsupported.  When the Notification message specifies the unsupported 
  capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs 
  TLV MUST include only the Capability Parameters for unsupported 
  capabilities, and 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. 
 
 
 
Thomas, et al.           Expires October 2009                 [Page 10] 
    






Internet-Draft             LDP Capabilities                  April 2009 
    

9. Dynamic Capability Announcement TLV 

  The Dynamic Capability Announcement TLV is a Capability Parameter 
  defined by this document with following format: 
   
       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |1|0| DynCap Announcement (IANA)|            Length (1)         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |1| Reserved    | 
      +-+-+-+-+-+-+-+-+ 
   
  The value of U-bit for Dynamic Capability Announcement Parameter TLV 
  MUST be set to 1 so that a receiver MUST silently ignore this TLV, if 
  unknown to it, and continue processing the rest of the message. There 
  is no "Capability Data" associated with this TLV and hence TLV length 
  MUST be set to 1. 
   
  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. This implies that S-bit is always 1 
  for Dynamic Capability Announcement.  
 
  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. 
 
10. 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. 
   
 
 
Thomas, et al.           Expires October 2009                 [Page 11] 
    






Internet-Draft             LDP Capabilities                  April 2009 
    

  Section 3.1 introduces the concept of Backward Compatibility TLVs  
  that may appear in an Initialization message in the role of a 
  Capability  Parameter. This permits existing LDP enhancements that 
  use an adhoc mechanism for enabling capabilities at sesssion 
  initialization time to continue to do so. 
   
11. Security Considerations 

  [MPLS_SEC] describes the security framework for MPLS networks, 
  whereas [RFC5036] describes the security considerations that apply to 
  the base LDP specification. The same security framework and 
  considerations apply to the capability mechanism described in this 
  document. 
   
12. 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. 
    

13. Acknowledgments 

  The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, 
  Yakov Rekhter, and Eric Rosen for their comments. 
   
  This document was prepared using 2-Word-v2.0.template.dot. 





 
 
Thomas, et al.           Expires October 2009                 [Page 12] 
    






Internet-Draft             LDP Capabilities                  April 2009 
    

14. References 

14.1. 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. 
 
14.2. 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.           Expires October 2009                 [Page 13] 
    






Internet-Draft             LDP Capabilities                  April 2009 
    

[MPLS_SEC] Fang, L. et al., Security Framework for MPLS and GMPLS 
          Networks, draft-ietf-mpls-mpls-and-gmpls-security-framework-
          05.txt, Work in Progress, March 2009. 
   
15. Author's Addresses 

  Bob Thomas 
  Cisco Systems, Inc. 
  1414 Massachusetts Ave. 
  Boxborough, MA 01719 
  E-mail: bobthomas@alum.mit.edu 
 
  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 
   
  Syed Kamran Raza 
  Cisco Systems, Inc. 
  2000 Innovation Dr. 
  Kanata, ON K2K-3E8, Canada 
  E-mail: skraza@cisco.com 







 
 
Thomas, et al.           Expires October 2009                 [Page 14]