summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5918.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5918.txt')
-rw-r--r--doc/rfc/rfc5918.txt563
1 files changed, 563 insertions, 0 deletions
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]
+