LDP Typed Wildcard FEC: Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)
A way for an LDP router to say 'all labels of this kind' in one message, with a capability to announce support.
Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, <https://www.rfc-editor.org/info/rfc5918>.
@misc{rfc5918,
series = {Request for Comments},
number = 5918,
howpublished = {RFC 5918},
publisher = {RFC Editor},
doi = {10.17487/RFC5918},
url = {https://www.rfc-editor.org/info/rfc5918},
author = {R. Asati and I. Minei and B. Thomas},
title = {{Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)}},
pagetotal = 10,
year = 2010,
month = aug,
} RFC text
Contents
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.
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
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.
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.
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:
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:
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.
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).
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.
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
AI ELI5
On this page
§1The Limits of the Untyped Wildcard
The Label Distribution Protocol (LDP, RFC 5036) hands out labels for Forwarding Equivalence Classes (FECs). Messages carry a FEC TLV that holds one or more FEC elements, each with a FEC type and an optional type-dependent value. RFC 5036 defines the Prefix and Wildcard types.
The Wildcard FEC element means all FECs, optionally limited to those bound to a given label. RFC 5918 names two deficiencies. It is untyped, so there is no way to say all FECs of a given type. And it may be used only in Label Withdraw and Label Release messages, not in Label Request messages.
The document defines a Typed Wildcard FEC element and its procedures, a capability announced at session setup, use in Label Request, and the typed wildcard for the Prefix FEC element. It does not change the procedures for the existing Wildcard FEC element.
The old 'everything' wildcard cannot be narrowed to one kind of thing, and cannot be used when asking for labels. This document fixes both.
§3The Typed Wildcard FEC Element
The element refers to all FECs of a specified type that meet an optional constraint. It begins with a one-octet element type, 0x05, followed by a one-octet FEC Element Type naming the type to be wildcarded, and a one-octet Len FEC Type Info giving the length in octets of the optional type-specific information. That length MUST be 0 when there is no additional information.
If the additional information is absent, all FECs of the specified type match. Any future document that defines a new FEC element type should say whether typed wildcarding is needed for it, and if so, the length and format of the extra information.
The note says 'this is a typed wildcard', then which kind of thing it means, then how much extra detail follows, which may be none.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPED-WILDCARD | Typed Wildcard | 1 byte | 0x05 | FEC element type of the typed wildcard itself. |
FEC-TYPE | FEC Element Type | 1 byte | 0x02 | The type being wildcarded; Prefix here. |
LEN | Len FEC Type Info | 1 byte | 0x02 | Length of the type-specific information. |
ADDRESS-FAMILY | Address Family | 2 bytes | Value from the IANA address family numbers registry. |
§4Procedures
A Typed Wildcard FEC element MUST be the only FEC element in its TLV. If a receiver sees others, it should ignore them and process the message as if only the typed wildcard were present.
An implementation that supports the element MUST support it in Label Request, Label Withdraw and Label Release messages, and for every FEC element type defined in RFC 5036. A Label Request carrying it asks for one or more Label Mappings for all FECs of that type. In Label Withdraw or Label Release, if a Label TLV is present the element means all FECs of that type bound to that label; with no Label TLV it means all FECs of that type.
A router receiving a typed wildcard for a type it does not support, or one that does not support wildcarding, MUST stop decoding, abort the message and send an "Unknown FEC" Notification, as RFC 5036 already provides. It MAY also use mechanisms from RFC 5919, for example when it has no label bindings for the requested type.
The wildcard has to be the only item on the note, otherwise the extras are ignored. If a router does not understand the kind of thing named, it politely says so and stops.
§5The Typed Wildcard FEC Capability
RFC 5036 already makes it safe to send an unsupported FEC element, but offers no way to learn whether a peer supports one except by trying. So an LDP speaker that supports the typed wildcard MUST announce it with a Typed Wildcard FEC Capability Parameter, defined with the mechanism of RFC 5561, in its Initialization messages only.
The capability TLV has type 0x050B and a length of 0x0001. The U and F bits MUST be 1 and 0, and the S bit MUST be 1 to show the capability is being advertised.
When two routers meet, each one says 'I know how to read typed wildcards', so nobody has to guess.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
U | U | 1 bits | 1 | MUST be 1. |
F | F | 1 bits | 0 | MUST be 0. |
TYPE | Typed WCard FEC Cap | 14 bits | 0x050B | TLV type for the capability. |
LENGTH | Length | 2 bytes | 0x0001 | MUST be set to 1. |
S | S | 1 bits | 1 | MUST be 1: the capability is being advertised. |
RESERVED | Reserved | 7 bits | Reserved bits. |
§6The Prefix FEC Typed Wildcard
RFC 5036 defines the Prefix FEC element but no typed wildcard for it, so this RFC supplies one. The FEC Element Type is 0x02 (Prefix). Len FEC Type Info MUST be 0x0002, and the additional information is a two-octet Address Family taken from the IANA address family numbers registry. The procedures in section 4 apply.
No typed wildcard is needed for the Host FEC element from RFC 3036, which RFC 5036 removed, or for the Wildcard element, which is untyped by definition. The FEC Element Type field therefore MUST NOT be 0x01 or 0x03.
For the most common kind of thing, addresses, you say which family of addresses you mean, such as one kind of address book, and the router handles all of that kind.
§8IANA Assignments
IANA assigned the code point 0x05 for the Typed Wildcard FEC element from the LDP FEC Type Name Space, and 0x050B for the Typed Wildcard FEC Capability from the TLV Type name space. Both come from the IETF Consensus range of the registries partitioned by RFC 5036.
Two official numbers were reserved so that nobody else uses them for something different.
§9Security Considerations
No security considerations apply beyond those of base LDP in RFC 5036, further described in RFC 5920. The RFC adds that the exposure could be seen as reduced: with a typed wildcard one message affects only the label mappings of one type, such as one address family, whereas the plain Wildcard FEC element can affect mappings of all types in one message.
Asking for only the red balls can do less accidental damage than asking for every ball.