Skip to main content

LDP IP and PW Capability
draft-ietf-mpls-ldp-ip-pw-capability-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7473.
Expired & archived
Authors Syed Kamran Raza , Sami Boutros
Last updated 2012-08-18 (Latest revision 2012-02-15)
Replaces draft-raza-mpls-ldp-ip-pw-capability
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7473 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-mpls-ldp-ip-pw-capability-01
MPLS Working Group                                           Kamran Raza
Internet Draft                                              Sami Boutros
Intended status: Standards Track                                        
Expires: August 14, 2012                                   Cisco Systems

                                                       February 15, 2012
 
                                      
                         LDP IP and PW Capability 
                                      
                draft-ietf-mpls-ldp-ip-pw-capability-01.txt 
 

 

Status of this Memo 

   This Internet-Draft is submitted in full conformance with the 
   provisions of BCP 78 and 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 

   This Internet-Draft will expire on August 14, 2012. 

Copyright Notice 

   Copyright (c) 2012 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 
   (http://trustee.ietf.org/license-info) in effect on the date of 
   publication of this document. Please review these documents 
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must 
 
 
 
Raza, et. al             Expires August 2012                   [Page 1] 

      
Internet-Draft          LDP IP and PW Capability           February 2012
      

   include Simplified BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described 
   in the Simplified BSD License. 

Abstract 

   Currently, no LDP capability is exchanged for LDP applications like 
   IP label switching and L2VPN/PW signaling. When an LDP session comes 
   up, an LDP speaker may unnecessarily advertise its local state for 
   such LDP applications even when the peer session may be established 
   for some other applications like ICCP. This document proposes a 
   solution by which an LDP speaker announces its disinterest or non-
   support for IP label switching or L2VPN/PW application, hence 
   disabling corresponding application state exchange over the 
   established LDP session.  

Table of Contents 

  1. Introduction ................................................... 3 
  2. Conventions used in this document .............................. 4 
  3. Non-negotiated LDP applications ................................ 4 
  4. Application Control Capabilities ............................... 5 
     4.1. IP Label Switching Capability TLV ......................... 5 
     4.2. PW Signaling Capability TLV ............................... 6 
  5. Capabilities Procedures .......................................  7 
     5.1. Application Control Capabilities in an Initialization msg . 7 
     5.2. Application Control capabilities in a Capability msg ...... 8 
  6. Operational Examples ........................................... 8 
     6.1. Disabling IP/PW label applications on an ICCP session ..... 8 
     6.2. Disabling IP Label Switching app. on a L2VPN/PW session ... 9 
     6.3. Disabling IP app. dynamically on an estab. IP/PW session .. 9 
  7. Security Considerations ....................................... 10 
  8. IANA Considerations ........................................... 10 
  9. Conclusions ................................................... 10 
  10. References ................................................... 10 
     10.1. Normative References .................................... 10 
     10.2. Informative References .................................. 11 
  11. Acknowledgments .............................................. 11 
   
    

 
 
Raza, et. al             Expires August 2012                   [Page 2] 

         
Internet-Draft          LDP IP and PW Capability          February 2012 
      

1. Introduction 

  LDP Capabilities [RFC5561] introduced a mechanism to negotiate LDP 
  capabilities for a given feature amongst peer LSRs. This mechanism 
  insures that no unnecessary state is exchanged between peer LSRs 
  unless corresponding feature capability is successfully negotiated 
  between peers.  
   
  While new features and applications, such as Typed Wildcard FEC 
  [RFC5918], Inter-Chassis Communication Protocol [ICCP], and mLDP 
  [RFC6388] make use of LDP capabilities framework for their feature 
  negotiation, the earlier LDP features and applications like IP label 
  switching and L2VPN/PW signaling [RFC4447] [RFC4762] may cause 
  unnecessary state exchange between LDP peers even when the given 
  application is not enabled on one of the LDP speakers participating 
  in a given session.  
   
  For example, when bringing up and using an LDP peer session with a 
  remote PE LSR for purely ICCP signaling purposes, the LDP speaker may 
  unnecessarily advertise labels for IP (unicast) prefixes to this ICCP 
  related LDP peer as per its default behavior.  
   
  Another example of unnecessary state advertisement can be cited when 
  LDP is used in (IP) dual-stack environment. For instance, an LSR that 
  is locally enabled for both IPv4 and IPv6 label switching may 
  advertise address/label bindings for both IPv4 and IPv6 address 
  families towards an IPv4-only LDP peer (i.e. a peer which is enabled 
  for IPv4 LDP only and with which hello adjacencies and transport 
  connection is formed using IPv4 only). In this case, the 
  advertisement of IPv6 addresses and labels to the peer is 
  unnecessary, as well as wasteful from LSR memory/CPU and network 
  resource consumption point of view.  
   
  To avoid this unnecessary state advertisement and exchange, currently 
  customers are typically required to configure/define some sort of LDP 
  state (e.g. label) filtering policies on the box, which introduces 
  operational overhead and complexity.  
   
  This document proposes an LDP Capabilities [RFC5561] based solution 
  by which an LDP speaker may announce its disinterest (or non-
  support/disability) to its peer for IP Label Switching and/or 

 
 
Raza, et. al             Expires August 2012                   [Page 3] 

          
Internet-Draft          LDP IP and PW Capability          February 2012 
      

  L2VPN/PW Signaling application at session establishment time. This 
  helps avoiding unnecessary state exchange for such feature 
  applications. The proposal also states the mechanics to enable a 
  previously disabled application to be enabled later during the 
  session lifetime. The document introduces two new LDP Capabilities 
  for IP label switching and L2VPN/PW applications to implement this 
  proposal.  
   
2. 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 RFC-2119 [RFC2119].  

   The term "IP" in this document refers to "IP unicast", and refers to 
   both IPv4 and IPv6 address families. 

3. Non-negotiated LDP applications 

   For the applications that existed before LDP Capabilities [RFC5561] 
   mechanics were defined, LDP speaker may advertise relevant 
   application state to its peers after session establishment without 
   waiting for any capabilities exchange and negotiation.  

   Amongst non-negotiated features and applications, the two most 
   important non-negotiated applications are: 

   o  IP [v4 and v6] label switching 

   o  L2VPN/PW signaling 

   To disable unnecessary state exchange for such LDP applications, two 
   new capabilities are being introduced in this document. These new 
   capabilities control application state advertisement and allow an LDP
   speaker to notify its LDP peer at the session establishment time when
   one or more of these "Non-negotiated" LDP applications are not 
   required/configured on the sender side. Upon receipt of such 
   capability, if supported, the receiving LDP speaker MUST disable the 
   advertisement of any state related to the application towards the 
   sender. These capabilities can also be sent later in a Capability 
   message to either disable these applications, or to enable previously
   disabled applications. 

 
 
Raza, et. al             Expires August 2012                   [Page 4] 

          
Internet-Draft          LDP IP and PW Capability          February 2012 
      

4. Application Control Capabilities 

   To control advertisement of state related to non-negotiated LDP 
   applications, namely IP Label switching and L2VPN/PW signaling, two 
   new capability TLVs are defined as described in the following sub-
   sections. 

4.1. IP Label Switching Capability TLV 

   The "IP Label Switching Capability" is a new Capability Parameter 
   defined with the 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| IP Label Sw. Cap. (IANA)  |           Length (4)          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |1| Reserved    | AF Bitmap     |        Reserved               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The value of the U-bit for the IP capability 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. Once 
   advertised, this capability cannot be withdrawn and hence the S-bit 
   must always be set to 1 both in Initialization message and Capability
   message. The capability data associated with this TLV is 1 octet long
   "Address Family Bitmap" and 2 octects "Reserved" field for future 
   use, and hence the TLV length MUST be set to 4.  
    
   The Capability data "Address Family Bitmap" is defined as follows: 
 
    0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+ 
   |   AF bitmap   | 
   +-+-+-+-+-+-+-+-+ 
    
   Where:   

       bit0: IPv4 label switching application 
       bit1: IPv6 label switching application       
       bit2-7: Unused. MBZ on transmit and ignored on receipt.  

   A bit in the bitmap is set to 0 or 1 to disable or enable 
   respectively a corresponding IP application. 

 
 
Raza, et. al             Expires August 2012                   [Page 5] 

          
Internet-Draft          LDP IP and PW Capability          February 2012 
      

   The "Reserved" field is reserved for future use and MBZ on transmit 
   and ignored on receipt. 

   As described earlier, "IP Label Switching Capability" Parameter TLV 
   MAY be included by an LDP speaker in an Initialization message to 
   signal to its peer LSR that state exchange for IPv4 and/or IPv6 
   application(s) need to be disabled on a given peer session. This TLV 
   can also be sent later in a Capability message to selectively enable 
   or disable IPv4/v6 label switching application(s). 

4.2. PW Signaling Capability TLV  

   The "PW Signaling Capability" is a new Capability Parameter defined 
   with the 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|  PW Signaling Cap. (IANA) |           Length (4)          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |1| Reserved    |E|  Unused     |            Reserved           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The value of the U-bit for the PW capability 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. Once 
   advertised, this capability cannot be withdrawn and hence the S-bit 
   MUST always be set to 1 in Initialization message or Capability 
   message. The capability data associated with this TLV is 3 octets 
   long and hence the TLV length MUST be set to 4.  
    
   The capability data is defined as follows:  

    0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+ 
   |E| Unused      | 
   +-+-+-+-+-+-+-+-+ 
    

   Where: 

    E-bit: Enable bit. Used to control PW signaling application by 
       setting it to 0 and 1 to disable and enable the application 
       respectively.  

    Unused: Unused bits. MBZ on transmit and ignored on receipt. 
 
 
Raza, et. al             Expires August 2012                   [Page 6] 

         
Internet-Draft          LDP IP and PW Capability          February 2012 
      

   The "Reserved" field is reserved for future use and MBZ on transmit 
   and ignored on receipt. 

   As described earlier, PW Signaling Capability Parameter TLV MAY be 
   included by an LDP speaker in an Initialization message to signal to 
   its peer LSR that state exchange for PW application need to be 
   disabled on given peer session. This TLV can also be sent later in a 
   Capability message to enable/disable the PW Signaling application. 

5. Capabilities Procedures 

5.1. Application Control Capabilities in an Initialization message 

   LDP Capabilities [RFC5561] dictate that the S-bit of capability 
   parameter in an Initialization message MUST be set to 1 and SHOULD be
   ignored on receipt.   

   An LDP speaker determines (e.g. via some local configuration or 
   default policy) if they need to disable IP and/or L2VPN/PW 
   applications with a peer LSR. If there is a need to disable, then the
   IP and/or PW application capability TLVs need to be included in the 
   Initialization message with respective application bits set to 0 to 
   indicate application disable, where the application bit refers to a 
   bit in "Address Family Bitmap" of the "IP Label Switching" Capability
   or E-bit in the "PW Signaling" Capability.   

   An LDP speaker that supports the "IP Label Switching" and/or "PW 
   Signaling" capability MUST interpret those TLVs in a received 
   Initialization message such that it disables the advertisement of the
   application state towards the sender LSR for IP (v4 and/or v6) and/or
   L2VPN/PW applications if their application control bits are set to 0.

   If a receiving LDP speaker does not understand the capability TLVs, 
   then it MUST respond to the sender with "Unsupported TLV" 
   Notification as described in LDP Capabilities [RFC5561]. Upon receipt
   of such Notification, the sender MAY still continue to block/disable 
   its outbound state advertisement towards the peer for the requested 
   disabled applications. 

   Once this capability has been sent by sender LSR and received and 
   understood by the receiver LSR, then both these LSRs MUST NOT 
   exchange any state related to the disabled applications until and 
   unless these applications are explicitly enabled again (e.g. via the 
   same Capability TLV sent in a Capability message with corresponding 
   application control bit set to 1). 

   "IP Label Switching" and "PW Signaling" capability TLVs are 
   unilateral and uni-directional in nature -- i.e. a receiving LSR may 
 
 
Raza, et. al             Expires August 2012                   [Page 7] 

         
Internet-Draft          LDP IP and PW Capability          February 2012 
      

   not need to send a similar capability TLV in an Initialization or 
   Capability message towards the sender. This unilateral behavior also 
   conforms to the procedures defined in the Section 6 of LDP 
   Capabilities [RFC5561].  

5.2. Application Control capabilities in a Capability message 

   If the LDP peer supports "Dynamic Announcement Capability" [RFC5561],
   then an LDP speaker can send IP Label Switching and/or PW Signaling 
   capability in a Capability message. Once advertised, these 
   capabilities cannot be withdrawn and hence the S-bit of the TLV MUST 
   be set to 1 when sent in a Capability message.  

   An LDP speaker may decide to send this TLV towards an LDP peer if any
   of its IP and/or L2VPN/PW signaling applications gets disabled, or if
   previously disabled IP and/or L2VPN/PW application gets enabled 
   again. In this case, LDP speaker constructs the TLVs with appropriate
   application control bitmap and sends the corresponding capability 
   TLVs in a Capability message. Furthermore, the LDP speaker also 
   withdraws application(s) related advertised state (such as label 
   bindings) from its peer. 

   Upon receipt of those TLVs in a Capability message, the receiving LDP
   speaker reacts in the same manner as it reacts upon the receipt of 
   those TLVs in an Initialization message. Additionally, the receiving 
   LDP speaker withdraws the application(s) related advertised state 
   (such as label bindings) from the sending LDP speaker. If the 
   receiving LDP speaker does not understand or support either Dynamic 
   Announcement capability or received Application Control capability 
   TLV ("IP Label Switching" or "PW Signaling"), it MUST respond with 
   "Unsupported Capability" notification to the sender of the Capability
   message.  

6. Operational Examples 

6.1. Disabling IP/PW label applications on an ICCP session 

   Consider two PE routers, LSR1 and LSR2, which understand/support "IP 
   Label Switching" and "PW Signaling" capability TLVs. These LSR have 
   an established LDP session due to ICCP application in order to 
   exchange ICCP state related to dual-homed devices connected to these 
   LSRs. Let us assume that LSR1 is provisioned not to exchange any 
   label bindings related to IP (v4/v6) prefixes and PW layer2 FEC 
   (FEC128/129) with LSR2. 

   To indicate its "disability" for the IP/PW applications, the LSR1 
   will include both the "IP Label Switching" capability TLV (with 
 
 
Raza, et. al             Expires August 2012                   [Page 8] 

         
Internet-Draft          LDP IP and PW Capability          February 2012 
      

   bit0-1 of "Address Family Bitmap" set to 0) and "PW Signaling" 
   capability TLV (with E-bit set to 0) in the Initialization message. 
   Upon receipt of those TLVs in Initialization message, the LSR2 will 
   disable any IP/PW address/label binding state advertisement towards 
   LSR1 after session establishment.  

   The LSR1 will also disable any IP/PW address/label binding state 
   towards LSR2, irrespective of the fact whether or not LSR2 could 
   disable the corresponding application state advertisement towards 
   LSR1. 

6.2. Disabling IP Label Switching application on a L2VPN/PW session 

   Now, consider LSR1 and LSR2 have an established session due to 
   L2VPN/PW application just to exchange PW (FEC128/129) label bindings 
   for VPWS/VPLS services amongst them. Since in most typical 
   deployments, there is no need to exchange IP (v4/v6) address/label 
   bindings amongst the PE LSRs, let us assume that LSR1 is provisioned 
   to disable IP (v4/v6) application on given PW session towards LSR2.  

   To indicate its disinterest in IP label switching, the LSR1 will 
   include the "IP Label Switching" capability TLV in the 
   Initialization message with bit0-1 (IPv4, IPv6) in "Address Family 
   Bitmap" set to zero. Upon receipt of this TLV in Initialization 
   message, the LSR2 will disable any IP address/label binding state 
   advertisement towards LSR1.  

   The LSR1 will also disable any IP address/label binding state 
   towards LSR2, irrespective of the fact whether or not LSR2 could 
   disable the corresponding IP application state advertisement towards 
   LSR1. 

6.3. Disabling IP application dynamically on an established IP/PW 
   session 

   Assume that LSRs from previous sections were initially provisioned to
   exchange both IP and PW state over the session between them, and also
   support "Dynamic Announcement Capability" [RFC5561]. Now, assume that
   LSR1 is dynamically provisioned to disable IP label switching with 
   LSR2. In this case, LSR1 will first withdraw all its IP label state 
   by sending a single Label Withdraw message with IP "Prefix Typed 
   Wildcard FEC" using the mechanics described in [RFC5918], and Address
   Withdraw message to withdraw its addresses. LSR1 will also send IP 
   Label Switching capability TLV in Capability message towards LSR2 
   with bit0-1 (IPv4, IPv6) in "Address Family Bitmap" set to zero. Upon
   receipt of this TLV, LSR2 will also disable IP label switching 
   towards LSR1 and withdraw all previous IP label/address state using 
 
 
Raza, et. al             Expires August 2012                   [Page 9] 

         
Internet-Draft          LDP IP and PW Capability          February 2012 
      

   the same mechanics as described earlier for LSR1. The disability of 
   IP label switching dynamically should not impact L2VPN/PW application
   on given session, and both LSRs should continue to exchange PW 
   Signaling application related state. 

7. Security Considerations 

  The proposal introduced in this document does not introduce any new 
  security considerations beyond that already apply to the base LDP 
  specification [RFC5036] and [RFC5920]. 
   
8. IANA Considerations 

  The document defines following two new capability parameter TLVs and 
  requests following LDP TLV code point assignment by IANA from LDP 
  "TLV Type Name Space" registry: 
   
   o  "IP Label Switching Capability" TLV (requested codepoint: 0x50C) 

   o  "PW Signaling Capability" TLV       (requested codepoint: 0x50D) 

 
9. Conclusions 

   The document proposed a solution using LDP Capabilities [RFC5561] 
   mechanics to disable unnecessary state exchange, if/as desired, 
   between LDP peers for currently non-negotiated IP/PW LDP 
   applications. 

10. References 

10.1. Normative References 

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

   [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le 
             Roux, "LDP Capabilities", RFC 5561, July 2009. 

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

 
 
Raza, et. al             Expires August 2012                  [Page 10] 

         
Internet-Draft          LDP IP and PW Capability          February 2012 
      

  [RFC4762] M. Lasserre, and V. Kompella,  "Virtual Private LAN Service 
            (VPLS) Using Label Distribution Protocol (LDP) Signaling", 
            RFC 4762, January 2007. 

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

10.2. Informative References 

   [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution 
             Protocol Typed Wildcard FEC", RFC 5918, August 2010. 

   [ICCP]    L. Martini, S. Salam, A. Sajassi, and S. Matsushima, 
             "Inter-Chassis Communication Protocol for L2VPN PE 
             Redundancy", draft-ietf-pwe3-iccp-07.txt, Work in Progress,
             February 2012. 

   [RFC6388] I. Minei, I. Wijnand, K. Kompella, and B. Thomas, "LDP 
             Extensions for P2MP and MP2MP LSPs", RFC 6388, November 
             2011. 

   [RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS 
             Networks", RFC 5920, July 2010. 

11. Acknowledgments 

   The authors would like to thank Eric Rosen for his valuable input and
   comments. 

   This document was prepared using 2-Word-v2.0.template.dot. 

Authors' Addresses 

  Kamran Raza 
  Cisco Systems, Inc., 
  2000 Innovation Drive, 
  Ottawa, ON K2K-3E8, Canada. 
  E-mail: skraza@cisco.com 
 
 
  Sami Boutros 
  Cisco Systems, Inc. 
  3750 Cisco Way, 
  San Jose, CA 95134, USA. 
  E-mail: sboutros@cisco.com 

 
 
Raza, et. al             Expires August 2012                  [Page 11]