ietf-corpus

rfc-5918

Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)

R. Asati, I. Minei, B. Thomas
date2010-08 streamIETF areartg wgmpls statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc5918 doi10.17487/RFC5918 errataview
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. [STANDARDS-TRACK]

updated by

Extracted elements (19)

design-rationale §1

The RFC 5036 Wildcard FEC Element has two key deficiencies: it is untyped (cannot reference all FECs of a given type), and its use is limited to Label Withdraw and Label Release messages only, excluding Label Request. The Typed Wildcard FEC Element addresses both limitations.

mpls

design-rationale §5

The Typed Wildcard FEC Capability is advertised only in Initialization messages (not via dynamic capability negotiation) because knowing peer support at session setup time is sufficient for determining whether typed wildcard operations can be used for the session.

mpls

interoperability-note §4

Backwards compatibility with routers not supporting the Typed Wildcard FEC Element is ensured by RFC 5036 FEC procedures: an LSR that encounters an unknown FEC Element type SHOULD stop decoding the FEC TLV, abort processing, and send an 'Unknown FEC' Notification message to its peer.

mpls

normative-requirement §4 MUST

A router receiving a FEC TLV containing a Typed Wildcard FEC Element for a FEC Element Type it does not support or that does not support wildcarding MUST stop decoding the FEC TLV, abort processing the containing message, and send an 'Unknown FEC' Notification message to its LDP peer.

mpls

normative-requirement §4 MUST

An LDP implementation that supports the Typed Wildcard FEC Element MUST support it for every FEC Element Type defined in RFC 5036.

mpls

normative-requirement §5 MUST

An LDP speaker that supports the Typed Wildcard FEC Element MUST inform its peers by including a Typed Wildcard FEC Element Capability Parameter (per RFC 5561) in its Initialization messages only.

mpls

normative-requirement §6 MUST

For the Prefix FEC Typed Wildcard Element, the Len FEC Type Info field MUST be set to 0x0002 to indicate the two-octet Address Family field that follows.

mpls

normative-requirement §5 MUST

In the Typed Wildcard FEC Capability TLV, the U and F bits MUST be 1 and 0 respectively (per RFC 5561 Section 3), the Length MUST be set to 0x0001, and the S-bit MUST be 1.

mpls

normative-requirement §7 MUST NOT

The FEC Element Type field in the Typed Wildcard FEC Element MUST NOT be set to 0x01 (Host FEC, removed in RFC 5036) or 0x03 (Wildcard FEC, which is untyped by definition).

mpls

normative-requirement §3 MUST

The Len FEC Type Info field MUST be set to 0 if there is no Additional FEC Type-specific Information present in the Typed Wildcard FEC Element.

mpls

normative-requirement §4 MUST

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 other FEC elements are also present, the receiver should ignore them and process as if only the Typed Wildcard FEC Element was present.

mpls

protocol-element §3

Any future document specifying a new FEC Element Type should prescribe whether typed wildcarding is needed for that type; any document specifying typed wildcarding for a FEC Element Type must also specify the length and format of Additional FEC Type Specific Information if included.

mpls, registry

protocol-element §4

In Label Withdraw or Label Release messages: if the message carries an optional Label TLV, the Typed Wildcard FEC Element refers to all FECs of the specified type bound to that label; if no Label TLV is present, it refers to all FECs of the specified type.

mpls

protocol-element §4

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.

mpls

registry §8

IANA assigned code point 0x05 ('Typed Wildcard FEC Element') from the LDP FEC Type Name Space IETF Consensus region, and code point 0x050B ('Typed Wildcard FEC Capability') from the TLV Type Name Space IETF Consensus region.

mpls, registry

security-consideration §9

No security considerations beyond those of RFC 5036 (base LDP) and RFC 5920 (MPLS/GMPLS security framework) apply. The Typed Wildcard FEC may reduce security exposure relative to the untyped Wildcard FEC, since a single message can only request/withdraw/release all bindings of a specific type (e.g., a specific AFI) rather than all bindings of all types.

mpls, security

wire-format §6

The Prefix FEC Typed Wildcard FEC Element encodes as: one-octet Typed Wildcard type (0x05), one-octet FEC Element Type set to 0x02 (Prefix), one-octet Len set to 0x0002, and a two-octet Address Family value from the IANA ADDRESS FAMILY NUMBERS registry.

mpls

wire-format §5

The Typed Wildcard FEC Capability TLV encodes as: two-octet type field with U=1, F=0, and value 0x050B; two-octet Length MUST be set to 0x0001; one-octet with S-bit MUST be 1 (capability being advertised) and 7 reserved bits.

mpls

wire-format §3

The Typed Wildcard FEC Element encodes as: one-octet FEC Element Type field set to 0x05 (Typed Wildcard), one-octet FEC Element Type to be wildcarded, one-octet Len FEC Type Info, and optional variable-length Additional FEC Type-specific Information.

mpls