MPLS Working Group P. Dutta Internet-Draft M. Aissaoui Intended status: Standards Track Alcatel-Lucent Expires: October 7, 2012 April 05, 2012 LDP Adjacency Capabilities draft-pdutta-mpls-ldp-adj-capability-00 Abstract This document defines method for negotiation of a set of capabilities specific to a Label Distribution Protocol (LDP) Hello Adjacency. The document uses the TLVs for the LDP Capabilities defined in [RFC5561] to be used for exchanging capabilities over LDP Hello Adjacencies. The Hello Adjacency capabilities can be thought of as "Traffic Forwarding Capabilities" (TFC). Some capabilties already exist that can be re-used for hello adjacency specific capabilities and it is likely that some may be defined in future. This document defines the mechanism to advertise LDP TFCs for a hello adjacency as well as mechanism to enable and disable TFCs after a hello adjacency is formed between LDP peers. Requirements 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 RFC 2119 [RFC2119]. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 7, 2012. Copyright Notice Dutta & Aissaoui Expires October 7, 2012 [Page 1] Internet-Draft LDP Adj Capabilities April 2012 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 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. LDP Adjacency Capability . . . . . . . . . . . . . . . . . . . 5 3. Specifying Capabilities in LDP Hello Message . . . . . . . . . 5 4. Interaction between LDP Session and Adjacency Capabilities . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Dutta & Aissaoui Expires October 7, 2012 [Page 2] Internet-Draft LDP Adj Capabilities April 2012 1. Introduction [RFC5561] defines LDP Capabilities that are negotiated during establishement of a LDP session between two peering Label Switch Routers (LSR). LDP Capability advertisement provides means for an LDP speaker to announce what it can receive and process over a LDP session. For example, a speaker may exchange capabilities of upstream label allocation, in bound label filtering or support of various Forwarding Equivalence Classes (FECs). Each Capability Type defines its own procedures, parameters and TLVs as described in [RFC5561]. The LDP Capabilities defined in [RFC5561] is applicable to all hello adjacencies associated with a LDP session. However, there may be certain Capabilities (based on the specific Capability Type) that may not be applicable to all hello adjacencies associated with a LDP session between two LDP speakers. For example, It is possible that there can be multiple Equal Cost Multi Path (ECMP) nterfaces between two LDP speakers and thus multiple Hello Adjacencies are associated with the session, one adjacency on each interface. Certain LDP Capabilities negotiated through the session are applicable to all such interfaces over which hello adjacencies are formed for the LDP session, whereas some capabilities may be applicable only to a sub- set of the Interfaces. Such interface specific capabilities can be various FEC specific capabilities exchanged over the peering session. It is possible that a subset of the interfaces from the ECMP set may not be capable of setting up the Label Switched Paths (LSPs) for certain FEC types that have been exchanged over the peering session. Further an operator may choose to exclude a subset of the ECMP interfaces from forwarding or receiving traffic on certain FEC types for administrative policy reasons. Such separation may be also required for fate separation of LDP LSP types in data plane. Thus it is also required for negotiation of capabilities at per interface level whether the interface in a peer is capable or willing to forwarding traffic for a FEC type on an interface. Two examples are described below: +------+----------------L1------------------+-------+ | | | | |LSR-A |----------------L2------------------| LSR-B | | | | | +------+----------------L3------------------+-------+ Figure 1: Hello Adjacencies over ECMP. An LDP session is formed between LSR-A and LSR-B with hello adjacencies over three ECMP interfaces respectively as IF1, IF2, and IF3. Dutta & Aissaoui Expires October 7, 2012 [Page 3] Internet-Draft LDP Adj Capabilities April 2012 Case 1: Let's assume that the hello adjacencies over IF1, IF2 and IF3 are using either IPv4 or IPv6 based interfaces but not both (dual-stack). Further the interface capability definitions are as follows: All the three interfaces are capable of setting up LDP LSPs for IPv4 FEC Element Types. Interface IF1 and IF2 are capable of setting up LDP Multi-point (MP) LSPs defined in [RFC6388] Interface IF2 and IF3 are capable of setting up LDP LSPs for IPv6 FEC Element Types, or the operator decided to enable so. Thus the LDP Hellos Messages exchanged over the interfaces need to advertise capabilities as below in order to negotiate the LSP types to be set-up on the interfaces. The LDP Hello Messages exchanged over interface IF1 would advertise IPv4 FEC Type Capability and the respective MP FEC Type Capabilities, and would exclude IPv6 Capabilities. The LDP Hello Messages exchanged over interface IF2 would advertise IPV4 FEC Type Capability, MP FEC Type Capability and IPv6 FEC Type Capability. The LDP Hello Messages exchanged over interface IF3 would advertise IPV4 FEC Type Capability and IPv6 FEC Type Capability, and would exclude MP FEC Type Capability. Case 2: Node - A Node - B +-------------+ +--------------+ | LSR-A1:0--|============IF 1==============|---LSR-B1:0 | | x | | x | | LSR-A2:0--|============IF 2==============|---LSR-B2:0 | | | | | +-------------+ +--------------+ Figure 2. Multiple LDP Instances for fate-separation of IPv4 and IPv6 LSPs This case refers to section 2.1.3 described in draft-pdutta-mpls-multi-ldp-instance-00. In this case, for fate separation of IPv4 traffic and IPv6 traffic over dual stack interfaces. In this case, all the ECMP inrerfaces are participating in both the LDP instances, for IPv4 and IPv6 respectively. Each Dutta & Aissaoui Expires October 7, 2012 [Page 4] Internet-Draft LDP Adj Capabilities April 2012 inteface would originate two sets of Hello Messages. One set would use IPv6 address on the interface as source address of the Hello Message for the LSR assigned for IPV6. Another set would use IPv4 address on the interface as source address of the Hello Message for the LSR assigned to IPv4. In such a scenerio, it is required that the Hello Messages originated by the IPv4 LDP instance would carry IPv4 FEC Capabilities only whereas the Hello Messages originated by the IPv6 LDP instance would carry IPv6 FEC Capabilities only. 2. LDP Adjacency Capability The LDP Adjacency Capability or TFC advertisement mechanism operates as follows: - Each LDP speaker is assumed to implement a set of LDP capabilities per Interface. At any time, a speaker may have none, one or more of those capabilities enabled on an interface. When a capability is enabled , the speaker advertises that capability associated on that interface on the hello messages originated from that interface. By advertising the capability over the interface, the speaker asserts that it shall perform the protocol actions specified for the capability on that interface. Unless the capability has been advertised, the speaker will not perform protocol actions specified for the capability on that interface. - When a LDP speaker had advertised a set of capabilities on the Hello Messages sent over an interface, then at any time the speaker MAY announce changes to the advertised capabilities by reflecting then change in subsequent Hello Messages. 3. Specifying Capabilities in LDP Hello Message This document uses Capabilty Parameter TLV defined in [RFC5561] that may be included as an OPTIONAL parameter in a LDP Hello Message to advertise a Capability associated with an Interface. The Hello Message can carry a set of such Capability Parameters TLVs, one for each capability type. The LDP speaker MUST NOT include more than one instance of a Capability Parameter (as identified by the same TLV code point) in a Hello Message. If an LDP speaker receives more than one instance of the same Capability Parameter type in a message, it SHOULD accept the first occurance of that Capability Type and ignore the next occurences in that message. Dutta & Aissaoui Expires October 7, 2012 [Page 5] Internet-Draft LDP Adj Capabilities April 2012 To ensure backward compatibility, if a speaker receives a LDP Hello Message without any Capability Parameter TLV then the receiver SHOULD assume that the interface over which the hello adjacency is formed is capable of the entire set of capabilities associated with the session established with the peer. Such capability designer should specify rules of that adjacency specific capability. For example, if a received Hello Message does not carry any Capability Parameter then receiver should assume that the interface is capable of sending or receving of all FEC types advertised by the LDP session between the speakers. If a Hello Message received over an interface carries one or more Capability Parameters then receiver SHOULD use that interface only as per the received capabilities. For dual stack deployments involving IPv4 and IPv6 interfaces between LDP peers, the IP Label Switching Capabilities defined in [I-D.ietf-mpls-ldp-ip-pw-capability] can be used. Note that it may be possible to define some capabilities in future that may not be applicable to ber advertised by LDP session but only over the Hello Adjacency. Such capabilities are out of scope of this document. 4. Interaction between LDP Session and Adjacency Capabilities Capabilities advertised via LDP session SHOULD be applicable to all interfaces unless it is explicitly excluded on a given interface. An LDP speaker MAY receive a set of Capabilities over a Hello Adjacency with a peer but peer may not have included the Capability set while establishing an LDP session. Such situation may arise in multi-acess Interfaces where an LDP speaker may have established sessions with multiple LDP peers. In such a case the LDP speaker MUST not exercise the interface capabilities that are not included in the LDP session with the peer. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations This document does not specify additional security implications to Dutta & Aissaoui Expires October 7, 2012 [Page 6] Internet-Draft LDP Adj Capabilities April 2012 what has been described in [RFC5561] 7. Acknowledgements The authors would like to thank Wim Henderickx for the insightful comments and probing questions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009. 8.2. References [I-D.ietf-mpls-ldp-ip-pw-capability] Raza, K. and S. Boutros, "LDP IP and PW Capability", draft-ietf-mpls-ldp-ip-pw-capability-01 (work in progress), February 2012. [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. Appendix A. An Appendix Dutta & Aissaoui Expires October 7, 2012 [Page 7] Internet-Draft LDP Adj Capabilities April 2012 Authors' Addresses Pranjal Kumar Dutta Alcatel-Lucent 701 E Middlefield Road Mountain View, California 94043 USA Phone: Fax: Email: pranjal.dutta@alcatel-lucent.com Mustapha Aissaoui Alcatel-Lucent 600 May Road Kanata, ON Canada Phone: Fax: Email: mustapha.aissaoui@alcatel-lucent.com URI: Dutta & Aissaoui Expires October 7, 2012 [Page 8]