MPLS Working Group Bob Thomas Internet Draft Intended status: Standards Track Expires: Feb 2010 Ina Minei Juniper Networks Rajiv Asati Cisco Systems September 5, 2009 LDP Typed Wildcard FEC draft-ietf-mpls-ldp-typed-wildcard-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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on Feb 5, 2010. Thomas & Minei Expires Feb 5, 2010 [Page 1] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 2009 Copyright Notice 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 The LDP specification [RFC5036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC5036. Table of Contents 1. Introduction...................................................3 2. Specification Language.........................................4 3. The Typed Wildcard FEC Element.................................4 4. Procedures for the Typed Wildcard FEC Element..................5 5. Typed Wildcard FEC Capability..................................6 6. Typed Wildcard FEC Element for Prefix FEC Element..............7 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements..8 8. IANA Considerations............................................8 9. Security Considerations........................................8 10. Acknowledgments...............................................8 11. References....................................................9 11.1. Normative References.....................................9 11.2. Informative References...................................9 Author's Addresses...............................................10 Thomas & Minei Expires Feb 5, 2010 [Page 2] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 2009 1. Introduction LDP [RFC5036] distributes labels for Forwarding Equivalence Classes (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP FEC TLV includes 1 or more FEC Elements. A FEC element includes a FEC type and an optional type-dependent value. RFC5036 specifies two FEC types (Prefix and Wildcard), and other documents specify additional FEC types; e.g., see [RFC4447] [MLDP]. As specified by RFC5036 the Wildcard FEC Element refers to all FECs relative to an optional constraint. The only constraint RFC5036 specifies is one that limits the scope of the Wildcard FEC Element to "all FECs bound to a given label". The RFC5036 specification of the Wildcard FEC Element has the following deficiencies which limit its utility: 1) The Wildcard FEC Element is untyped. There are situations where it would be useful to be able to refer to all FECs of a given type. 2) Use of the Wildcard FEC Element is limited to Label Withdraw and Label Release messages only. There are situations where it would be useful in Label Request messages. This document: - Addresses the above deficiencies by defining a Typed Wildcard FEC Element and procedures for its use. - Specifies use of the LDP capability mechanism [RFC5561] at session establishment time for informing a peer that an LDP speaker is capable of handling the Typed Wildcast FEC. - Specifies the Typed Wildcard FEC Element for the Prefix FEC Element specified by RFC5036. Note that this document does not change procedures specified for the LDP Wildcard FEC Element by RFC5036. Thomas & Minei Expires Feb 5, 2010 [Page 3] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 2009 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 Typed Wildcard FEC Element The Typed Wildcard FEC Element refers to all FECs of a given type relative to an optional constraint. The constraint, if present, is determined from the context in which the Typed Wildcard FEC Element appears. The format of the Typed Wildcard FEC Element 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Typed (IANA) | FEC Element | Len FEC Type | | | Wildcard | Type | Info | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ Additional FEC Type-specific Information ~ | | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Typed Wildcard FEC Element where: Typed Wildcard: One octet FEC Element Type (to be assigned by IANA). FEC Element Type: One octet FEC Element Type that specifies the FEC Element Type to be wildcarded. Len FEC Type Info: One octet that specifies the length of the FEC Type Specific information field. MUST be 0 if there is no Additional FEC Type-specific Information. Thomas & Minei Expires Feb 5, 2010 [Page 4] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 2009 Additional FEC Type-specific Information: Additional information specific to the FEC Element Type required to fully specify the Typed Wildcard. Specification of the length and format of Additional FEC Type Specific Information for particular FEC Element Types is outside of the scope of this document. It is the responsibility of the designer of the FEC Element Type to specify the length and format of any Additional FEC Type Specific Information. This document discusses two instances of Typed Wildcard FEC Elements in section 6 and 7. 4. Procedures for the Typed Wildcard FEC Element It is the responsibility of the designer of the FEC Element Type to determine whether typed wildcarding makes sense the FEC Element Type. If typed wildcarding does make sense the specification for the FEC Element Type MUST include support for it. When typed wildcarding is supported for a FEC Element Type it is the responsibility of the designer to specify the length and format of any Additional FEC Type Specific Information. When a FEC TLV contains a Typed Wildcard FEC Element the Typed Wildcard FEC Element MUST be the only FEC Element in the TLV. An LDP implementation that supports the Typed Wildcard FEC Element MUST support its use in Label Request, Label Withdraw and Label Release messages. An LDP implementation that supports the Typed Wildcard FEC Element MUST support it for every FEC Element Type implemented for which it is defined. Receipt of a Label Request message with a FEC TLV containing a Typed Wildcard FEC Element is interpreted as a request to send a Label Mapping for all FECs of the type specified by the FEC Element Type field in the Typed Wildcard FEC Element encoding. An LDP implementation that supports the Typed Wildcard FEC Element MUST support the following constraints whenever a Typed Wildcard FEC appears in a Label Withdraw or Label Release message: Thomas & Minei Expires Feb 5, 2010 [Page 5] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 2009 1) If the message carries an optional Label TLV the Typed Wildcard FEC Element refers to all FECs of the specified FEC type bound to the specified label. 2) If the message has no Label TLV the Typed Wildcard FEC Element refers to all FECs of the specified FEC type. Backwards compatibility with a router not supporting the Typed Wildcard FEC element is ensured by the FEC procedures defined in RFC5036. Quoting from RFC5036: "If it" [an LSR] "encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error." A router receiving a FEC TLV containing a Typed Wildcard FEC element for a FEC Element Type that it either doesn't support or for a FEC Element Type that doesn't support the use of wildcarding MUST stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error. 5. Typed Wildcard FEC Capability As noted above, RFC5056 FEC procedures provide for backward compatibility with a LSR not supporting the Typed Wildcard FEC Element. However, they don't provide means for LSR wishing to use the Typed Wildcard FEC Element to determine whether a peer supports it other than to send a message that uses the FEC Element and to wait and see how the peer responds. An LDP speaker that supports the Typed Wildcard FEC Element MUST inform its peers of the support by including a Typed Wildcard FEC Element Capability Parameter [RFC5561] in its Initialization messages. The Capability Parameter for the Typed Wildcard FEC capability is a TLV with the following format: Thomas & Minei Expires Feb 5, 2010 [Page 6] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 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| Typed WCard FEC Cap (IANA)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | +-+-+-+-+-+-+-+-+ Figure 2 Typed Wildcard FEC Capability format Where: U and F bits : MUST be 1 and 0 respectively as per section 3 of LDP Capabilities [RFC5561]. Typed WCard FEC Cap : TLV code point to be assigned by IANA. S-bit : MUST be 1 (indicates that capability is being advertised). 6. Typed Wildcard FEC Element for Prefix FEC Element RFC5036 defines the Prefix FEC Element but it does not specify a Typed Wildcard for it. This section specifies the Typed Wildcard FEC Element for Prefix FEC Elements. The format of the Prefix FEC Typed Wildcard FEC ("Prefix FEC Wildcard" for short) 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Typed Wcard | Prefix (2) | 2 | Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Family | +-+-+-+-+-+-+-+-+ Figure 3 Format of Prefix FEC Element using Typed Wildcard Where: Address Family: Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [IANA-AF]. Thomas & Minei Expires Feb 5, 2010 [Page 7] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 2009 The procedures of Section 4 apply to the Prefix FEC Wildcard. 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements There is no need to specify Typed Wildcard FEC Elements for the Host FEC Element specified by [RFC3036], nor for the Wildcard FEC Element specified by RFC5036. The [RFC3036] Host FEC Element has been removed from RFC5036, and the Wildcard FEC Element is untyped by definition. 8. IANA Considerations This draft introduces a new LDP FEC Element Type and a new LDP Capability both of which require IANA assignment - The 'Typed Wildcard' FEC Element requires a code point from the LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name Space into 3 regions: IETF Consensus region, First Come First Served region, and Private Use region. The authors recommend that the code point 0x05 from the IETF Consensus range be assigned to the 'Typed Wildcard' FEC Element. The 'Typed Wildcard FEC' Capability requires a code point from the TLV Type name space. [RFC5036] partitions the TLV TYPE name space into 3 regions: IETF Consensus region, First Come First Served region, and Private Use region. The authors recommend that a code point from the IETF Consensus range be assigned to the 'Typed Wildcard FEC' Capability. 9. Security Considerations No security considerations beyond those that apply to the base LDP specification [RFC5036] and further described in [MPLSsec] apply to use of the Typed Wildcard FEC Elements as described in this document. 10. Acknowledgments The authors would like to thank Yakov Rekhter for suggesting that the deficiencies of the Wildcard FEC be addressed. This document was prepared using 2-Word-v2.0.template.dot. Thomas & Minei Expires Feb 5, 2010 [Page 8] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 2009 11. References 11.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 Thomas, B., "LDP Specification", RFC 5036, October 2007. [RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., "LDP Capabilities", RFC5561, May 2007. 11.2. Informative References [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and Thomas, B., "LDP Specification", RFC 3036, January 2001. [RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance Using the label Distribution Protocol (LDP)", RFC4447, April 2006. [MLDP] Minei, I., Wijnands, I., Editors, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp- p2mp-07.txt, Work in Progress, July 2009. [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-06, Work in Progress, July 13 2009. [IANA-AF] http://www.iana.org/assignments/address-family-numbers. Thomas & Minei Expires Feb 5, 2010 [Page 9] Internet-Draft draft-ietf-mpls-ldp-typed-wildcard September 2009 Author's Addresses Ina Minei Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: ina@juniper.net Bob Thomas Email: bobthomas@alum.mit.edu Rajiv Asati Cisco Systems, 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 Email: rajiva@cisco.com Thomas & Minei Expires Feb 5, 2010 [Page 10]