Link Bundling in MPLS Traffic Engineering (TE)
updates
- rfc-3471 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
- rfc-3472 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
- rfc-3473 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
Extracted elements (22)
Link bundling is introduced because in some GMPLS contexts (e.g., SONET/SDH cross-connects composed of multiple fibers where a label is a TDM time slot valid only within a specific fiber), a combination of <TE link identifier, label> is insufficient to unambiguously identify the resource used by an LSP. The component link identifier fills this gap.
The purpose of link bundling is to improve routing scalability by reducing the amount of information that OSPF and/or IS-IS must handle, accomplished through information aggregation and abstraction at the expense of some information loss.
All component links in a bundle MUST have the same Link Type (point-to-point or multi-access), the same Traffic Engineering metric, and the same set of resource classes at each end, and must begin and end on the same pair of LSRs.
Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.
Component link identifiers MUST be unique across both TE and component link identifiers on a particular node; unnumbered identifiers have node-wide scope and numbered identifiers share IP address scope.
For multi-access links, if the set of IS-IS/OSPF routers connected to each component link or the Designated Router cannot be enforced to be the same across all component links, multi-access links MUST NOT be bundled.
If all component links associated with a bundled link are down, the bundled link MUST NOT be advertised into OSPF/IS-IS.
Interface Identification TLV types 1 (IPv4 numbered), 2 (IPv6 numbered), and 3 (unnumbered) SHOULD be used to indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs. The Component Interface TLVs (types 4 and 5) SHOULD NOT be used.
Link local identifiers for all unnumbered links of a given LSR (whether component links, Forwarding Adjacencies, or bundled links) MUST be unique in the context of that LSR.
The choice of the component link to use for an LSP is always made by the sender of the Path/REQUEST message. For a bidirectional LSP, the sender chooses a component link in each direction.
When Interface Identification TLVs are used to identify errored components, any received TLVs SHOULD be copied into the IF_ID ERROR_SPEC object (RSVP) or IF_ID Status TLV (CR-LDP). The Error Node Address / HOP Address SHOULD indicate the TE Link associated with the error.
A bundled link is alive when at least one of its component links is determined to be alive. Liveness may be determined by IS-IS/OSPF hellos, RSVP Hello, LMP hellos, or layer 1/2 indications.
A bundled link is partitioned into disjoint component link subsets such that (a) the partition is minimal, and (b) within each subset, a label alone suffices to identify the resource used by an LSP. Each such subset is called a 'component link'; the overall logical construct is the 'bundled link'.
Admission control for LSPs on bundled links is performed per-component link. An LSP with bandwidth requirement b and setup priority p fits if at least one component link has maximum LSP bandwidth >= b at priority p. The Traffic Control module must track unreserved bandwidth per component link.
For a bidirectional LSP, one or two TLVs SHOULD be used: the first always indicates the downstream component link identifier, and the optional second indicates the upstream component link identifier. If only one TLV is present, it serves both directions.
For a unidirectional LSP, only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID TLV, indicating the component link identifier of the downstream data channel on which label allocation must be done.
In the special case where the same label is valid across all component links (bundle-scope label), two TLVs SHOULD be used: the first identifies the TE link (bundle), and the second uses a special all-ones value (0xFFFFFFFF for types 1–2; Interface ID = 0xFFFFFFFF for type 3) to indicate bundle scope. This applies to both unidirectional and bidirectional LSPs.
The Maximum LSP Bandwidth replaces Maximum Bandwidth for bundled links. The Maximum LSP Bandwidth of a bundled link at priority p is the maximum of the Maximum LSP Bandwidth at priority p across all of its component links.
The unreserved bandwidth of a bundled link at priority p is the sum of the unreserved bandwidths at priority p of all component links. The Maximum Reservable Bandwidth of a bundled link is the sum of Maximum Reservable Bandwidths of all component links (when configured per component link).
The IANA registry of GMPLS Signaling Parameters has been updated to deprecate Interface_ID Type 4 (COMPONENT_IF_DOWNSTREAM, length 12) and Type 5 (COMPONENT_IF_UPSTREAM, length 12), previously defined in RFC 3471.
RFC 4201 defines procedures that utilize mechanisms from referenced documents (RFC 3209 RSVP-TE and RFC 3212 CR-LDP). All security issues are addressed in those referenced documents; this document raises no new security issues.
For Interface Identification TLV types 3, 4, and 5, the Value field has an identical format to the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object defined in RFC 3477. This results in renaming the 'IP Address' field from RFC 3471.