From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5918.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc5918.txt (limited to 'doc/rfc/rfc5918.txt') diff --git a/doc/rfc/rfc5918.txt b/doc/rfc/rfc5918.txt new file mode 100644 index 0000000..09d0319 --- /dev/null +++ b/doc/rfc/rfc5918.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Asati +Request for Comments: 5918 Cisco Systems +Category: Standards Track I. Minei +ISSN: 2070-1721 Juniper Networks + B. Thomas + August 2010 + + + Label Distribution Protocol (LDP) 'Typed Wildcard' + Forward Equivalence Class (FEC) + +Abstract + + The Label Distribution Protocol (LDP) specification for the Wildcard + Forward Equivalence Class (FEC) element has several limitations. + This document addresses those limitations by defining a Typed + Wildcard FEC Element and associated procedures. In addition, it + defines a new LDP capability to address backward compatibility. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5918. + + + + + + + + + + + + + + + + + + + +Asati, et al. Standards Track [Page 1] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + +Copyright Notice + + Copyright (c) 2010 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. + + 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. + +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 ................................................9 + 11. References .....................................................9 + 11.1. Normative References ......................................9 + 11.2. Informative References ....................................9 + + + + + + + + + +Asati, et al. Standards Track [Page 2] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + +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 one or more FEC elements. A FEC element includes a + FEC type and an optional type-dependent value. + + RFC 5036 specifies two FEC types (Prefix and Wildcard), and other + documents specify additional FEC types; e.g., see [RFC4447] and + [MLDP]. + + As specified by RFC 5036, the Wildcard FEC Element refers to all FECs + relative to an optional constraint. The only constraint RFC 5036 + specifies is one that limits the scope of the Wildcard FEC Element to + "all FECs bound to a given label". + + The RFC 5036 specification of the Wildcard FEC Element has the + following deficiencies that 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 + (as another constraint). + + 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 to have a Wildcard FEC Element, with type constraint, in + Label Request messages. + + This document: + + - addresses the above limitations 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 Wildcard FEC. + + - specifies use of the Typed Wildcard FEC Element in a Label + Request message. + + - specifies the Typed Wildcard FEC Element for the Prefix FEC + Element specified by RFC 5036. + + Note that this document does not change procedures specified for the + LDP Wildcard FEC Element by RFC 5036. + + + + + + +Asati, et al. Standards Track [Page 3] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + +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]. + + LDP - Label Distribution Protocol + + FEC - Forwarding Equivalence Class + + TLV - Type Length Value + + LSR - Label Switching Router + +3. The Typed Wildcard FEC Element + + The Typed Wildcard FEC Element refers to all FECs of the specified + type that meet the constraint. It specifies a 'FEC Element Type' and + an optional constraint, which is intended to provide additional + information. + + 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 (0x05) | FEC Element | Len FEC Type | | + | Wildcard | Type | Info | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + ~ Additional FEC Type-specific Information ~ + | (Optional) | + | +-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Typed Wildcard FEC Element + + Where: + + Typed Wildcard: One-octet FEC Element Type (0x05). + + FEC Element Type: One-octet FEC Element Type that specifies the + FEC Element Type to be wildcarded. Please see Section 3.4.1 of + RFC 5036. + + + + + + +Asati, et al. Standards Track [Page 4] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + + Any (future) document specifying a new FEC Element Type (not + defined in RFC 5036) should prescribe whether typed + wildcarding is needed for that FEC Element Type. + + Len FEC Type Info: One octet that specifies the length in octets + of the FEC Type Specific information field. It MUST be set to + 0 if there is no Additional FEC Type-specific Information. + + Additional FEC Type-specific Information (Optional): Additional + information that is specific to the FEC Element Type and that + is required to fully specify the Typed Wildcard. If this field + is absent, then all FECs of the specified FEC Type would be + matched. + + Any (future) document specifying Typed wildcarding for any + FEC Element Type should also specify the length and format + of Additional FEC Type Specific Information, if included. + + This document specifies one FEC Element Type instance (e.g., Prefix + FEC) for the 'Typed Wildcard FEC Element' in Section 6. + +4. Procedures for the Typed Wildcard FEC Element + + When a FEC TLV contains a Typed Wildcard FEC Element, the Typed + Wildcard FEC Element MUST be the only FEC Element in the TLV. If an + LDP speaker receives a FEC TLV containing a Typed Wildcard FEC + Element and any other FEC elements, then the LDP speaker should + ignore the other FEC elements and continue processing as if the + message only contains the Typed Wildcard FEC Element. + + 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 defined in [RFC5036]. + + Receipt of a Label Request message with a FEC TLV containing a Typed + Wildcard FEC Element is interpreted as a request to send one or more + Label Mappings 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: + + + + + + +Asati, et al. Standards Track [Page 5] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + + 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 RFC + 5036. Quoting from RFC 5036: + + 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 either a FEC Element Type that it 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 + to signal an error. + + A router receiving a FEC TLV containing a Typed Wildcard FEC element + MAY also leverage mechanisms defined in [RFC5919] (say, if it had + zero label binding for the requested FEC type, etc.). + +5. Typed Wildcard FEC Capability + + As noted above, RFC 5036 FEC procedures provide for backward + compatibility with an LSR not supporting the Typed Wildcard FEC + Element. However, they don't provide means for an LSR that wishes 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 + only. + + The Capability Parameter for the Typed Wildcard FEC capability is a + TLV with the following format: + + + + + + + + +Asati, et al. Standards Track [Page 6] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + + 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(0x050B)| 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: 0x050B + + Length: Two octets. It MUST be set to 0x0001. + + S-bit: MUST be 1 (indicates that capability is being advertised). + +6. Typed Wildcard FEC Element for Prefix FEC Element + + RFC 5036 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 Element ("Prefix FEC + Wildcard" for short), based on Figure 1, 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 | Type = Prefix | Len = 2 | Address... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ...Family | + +-+-+-+-+-+-+-+-+ + + Figure 3: Format of Prefix FEC Element Using Typed Wildcard + + Where: + + FEC Element Type: "Prefix" FEC Element (0x02, per RFC 5036). + + Len FEC Type Info: Two octets. It MUST be set to 0x0002. + + Address Family: Two-octet quantity containing a value from the + "ADDRESS FAMILY NUMBERS" registry on http://www.iana.org. + + + +Asati, et al. Standards Track [Page 7] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + + The procedures described in Section 4 apply to the Prefix FEC + Wildcard processing. + +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 RFC 5036. The [RFC3036] Host FEC Element has been + removed from RFC 5036, and the Wildcard FEC Element is untyped by + definition. + + In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC + Element' MUST NOT be either 0x01 or 0x03. + +8. IANA Considerations + + This document introduces a new LDP FEC Element Type and a new LDP + Capability, both of which have been assigned by IANA. + + IANA has assigned a 'Typed Wildcard FEC Element' code point (0x05) + 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 code point 0x05 + is from the IETF Consensus range. + + IANA has assigned a 'Typed Wildcard FEC Capability' code point + (0x050B) from the TLV Type name space. [RFC5036] partitions the + TLV TYPE name space into 3 regions: IETF Consensus region, Vendor + Private Use region, and Experimental Use region. The code point + 0x050B is from the IETF Consensus range. + +9. Security Considerations + + No security considerations beyond those that apply to the base LDP + specification [RFC5036] and that are further described in [RFC5920] + apply to use of the Typed Wildcard FEC Elements as described in this + document. + + One could deduce that the security exposure is reduced by this + document, since an LDP speaker using the Typed Wildcard FEC Element + could use a single message to request, withdraw, or release all the + label mappings of a particular type (a particular Address Family + Identifier (AFI), for example), whereas an LDP speaker using the + Wildcard FEC Element, as defined in the base LDP specification + [RFC5036], could use a single message to request, withdraw, or + release all the label mappings of all types (all AFIs, for example). + + + + + +Asati, et al. Standards Track [Page 8] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + +10. Acknowledgments + + The authors would like to thank Yakov Rekhter for suggesting that the + limitations of the Wildcard FEC be addressed. Also, thanks to Adrian + Farrel, Kamran Raza, and Richard L. Barnes for extensive review of + this document. + +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., Ed., Minei, I., Ed., and B. Thomas, Ed., + "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. + +11.2. Informative References + + [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and + B. Thomas, "LDP Specification", RFC 3036, January 2001. + + [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and + G. Heron, "Pseudowire Setup and Maintenance Using the + Label Distribution Protocol (LDP)", RFC 4447, April 2006. + + [RFC5919] Asati, R., Mohapatra, P., Minei, I., and B. Thomas, + "Signaling LDP Label Advertisement Completion", RFC 5919, + August 2010. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + [MLDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B. + Thomas, "Label Distribution Protocol Extensions for Point- + to-Multipoint and Multipoint-to-Multipoint Label Switched + Paths", Work in Progress, July 2010. + + + + + + + + + + + +Asati, et al. Standards Track [Page 9] + +RFC 5918 LDP 'Typed Wildcard' FEC August 2010 + + +Authors' Addresses + + Rajiv Asati + Cisco Systems + 7025-6 Kit Creek Rd. + Research Triangle Park, NC 27709-4987 + EMail: rajiva@cisco.com + + + Ina Minei + Juniper Networks + 1194 North Mathilda Ave. + Sunnyvale, CA 94089 + EMail: ina@juniper.net + + + Bob Thomas + EMail: bobthomas@alum.mit.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Asati, et al. Standards Track [Page 10] + -- cgit v1.2.3