ietf-corpus

rfc-4875

Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)

R. Aggarwal (Editor), D. Papadimitriou (Editor), S. Yasukawa (Editor)
date2007-05 streamIETF areartg wgmpls statusPROPOSED STANDARD pages53 canonicalhttps://www.rfc-editor.org/rfc/rfc4875 doi10.17487/RFC4875 errataview
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]

updated by

Extracted elements (28)

design-rationale §4.5

SERO-based explicit route compression avoids repeating shared-path information for multiple S2L sub-LSPs. Each SERO encodes only the path from a branch LSR to the leaf; an LSR processes only SEROs whose first hop is a local address, reducing both Path message size and per-hop processing cost.

mpls, routing

design-rationale §1

The solution deliberately avoids requiring a multicast routing protocol in the SP core; instead it relies solely on RSVP-TE for P2MP LSP setup. This allows traffic-engineered multicast trees with explicit resource reservation while remaining decoupled from IP multicast routing.

mpls, routing

design-rationale §4.3

The Sub-Group mechanism was introduced because P2MP LSP state may not fit in a single IP packet (RSVP prohibits IP fragmentation) and leaves must be efficiently added or removed. Sub-Group IDs allow multiple Path messages per P2MP LSP and enable incremental state updates without re-signaling the entire tree.

mpls, routing

interoperability-note §6.2.1

Branch nodes SHOULD combine Resv state from multiple downstream receivers into a single upstream Resv message. When the only change is in SRRO objects, transmission SHOULD be delayed until after a timer (suggested 30 seconds, SHOULD be longer than 1 second) since the previous Resv for the session, to throttle excessive Resv messages.

mpls, routing

interoperability-note §16

LSRs not supporting P2MP extensions may be included as transit LSRs via LSP stitching and LSP hierarchy (RFC 4206): a P2P LSP segment is signaled between P2MP-capable LSRs spanning the legacy stretch. Ingress, branch, and egress roles MUST be performed only by P2MP-capable LSRs.

mpls, routing

normative-requirement §5.2.1 MUST

A P2MP LSP MUST have consistent attributes across all portions of the tree per RFC 4461. Each Path message for the same P2MP LSP MUST carry identical signaling attributes except for S2L sub-LSP descriptors, the Sub-Group identifier, and per-message/hop objects (INTEGRITY, MESSAGE_ID, RSVP_HOP).

mpls, routing

normative-requirement §6.2 MUST NOT

A Resv message MUST NOT be sent upstream until at least one Resv has been received from a downstream neighbor. When the LSP integrity bit is set in LSP_REQUIRED_ATTRIBUTES, the node MUST NOT send Resv upstream until all downstream Resv messages have been received.

mpls, routing

normative-requirement §5.2.2 MUST

All LSRs MUST process the ERO for the first S2L sub-LSP if present; if any SEROs are present an ERO MUST also be present. A branch LSR MUST only propagate the relevant S2L sub-LSP descriptors to each downstream hop, and MUST NOT include descriptors routed via other outgoing interfaces.

mpls, routing

normative-requirement §5.2.4 MUST

An ingress LSR requests 'LSP integrity' by setting bit 3 of the Attributes Flags TLV via the LSP_REQUIRED_ATTRIBUTES object. A branch LSR that supports this flag MUST enforce LSP integrity or reject the LSP with a PathErr 'Routing Error'/'Unsupported LSP Integrity'; a failure on any branch must cause the entire P2MP LSP to fail.

mpls, routing

normative-requirement §16 MUST

An LSR that supports P2MP extensions but cannot perform P2MP branching in the data plane MUST respond with a PathErr carrying Error Code 'Routing Error' and Error Value 'Unable to Branch' when asked to act as a branch LSR. LSRs not supporting the extensions at all will reject the P2MP SESSION C-Type.

mpls, routing

normative-requirement §5.2 MUST

An LSR that supports RSVP-TE P2MP LSPs MUST be able to receive and process multiple Path messages for the same P2MP LSP and multiple S2L sub-LSPs within one Path message, and MUST be able to process all objects defined in section 19.

mpls, routing

normative-requirement §15.1.2 MUST NOT

During fast reroute, the Merge Point MUST use the LSP-ID to identify corresponding S2L sub-LSPs and MUST NOT use the <Sub-Group Originator ID, Sub-Group ID> tuple, because the Sub-Group Originator ID may have been changed by an LSR bypassed by the bypass tunnel.

mpls, routing

normative-requirement §15 MUST

Each S2L sub-LSP of a P2MP LSP MUST have the same protection characteristics. Fast reroute procedures from RFC 4090 MUST be followed, and RRO processing MUST apply to SRROs as well unless otherwise modified.

mpls, routing

normative-requirement §6.4 MUST

S2L sub-LSPs belonging to the same P2MP LSP SHOULD share labels where they share hops; if they share labels they MUST share resources. If the reservation style is FF, sub-LSPs from different P2MP LSPs MUST NOT share resources or labels. If SE, they SHOULD share resources but MUST NOT share labels in packet environments.

mpls, routing

normative-requirement §11.3 MUST

When LSP integrity is set and a branch LSR receives a PathErr with Path_State_Removed clear, it MUST send PathTear on all downstream branches and forward the PathErr upstream with Path_State_Removed set. Without LSP integrity the default is to forward the PathErr upstream with no further action.

mpls, routing

normative-requirement §5.2.3 MUST

When transit fragmentation of a Path message is required (e.g., ERO expansion overflow), IP fragmentation MUST be avoided per RFC 2205. Instead the transit LSR generates multiple Path messages, each with a distinct Sub-Group Originator ID set to its TE Router ID and a unique Sub-Group ID.

mpls, routing

protocol-element §4.4

A P2MP LSP is constituted of one or more source-to-leaf (S2L) sub-LSPs, each identified by the P2MP SESSION tuple, the SENDER_TEMPLATE fields, and an S2L_SUB_LSP object carrying the destination address. S2L sub-LSPs are combined at branch LSRs via data replication to form the P2MP tree.

mpls, routing

protocol-element §4.1

A P2MP TE Tunnel is identified by a P2MP SESSION object containing a P2MP ID (4-octet number unique within the ingress LSR scope), a Tunnel ID, and an Extended Tunnel ID. The SESSION object replaces the Tunnel Endpoint Address field of the RFC 3209 SESSION object with the P2MP ID.

mpls, routing

protocol-element §4.3

Sub-Group fields (Sub-Group Originator ID and Sub-Group ID) are added to SENDER_TEMPLATE and FILTER_SPEC objects to represent a portion of a P2MP LSP's signaling state, disambiguating multiple Path messages for the same P2MP LSP. The Sub-Group Originator ID is set to the TE Router ID of the originating LSR and is globally unique.

mpls, routing

registry §20

Section 20 creates new IANA allocations: new RSVP Class Numbers (section 20.1) including Class 50 for S2L_SUB_LSP; new C-Types (section 20.2) for P2MP SESSION (C-Types 13/14), P2MP SENDER_TEMPLATE (C-Types 13/14), and P2MP FILTER_SPEC (C-Types 13/14); new PathErr error values (section 20.3) for 'Unable to Branch' and 'Unsupported LSP Integrity'; and a new LSP Attributes Flag bit (section 20.4) for LSP integrity.

mpls, routing, registry

security-consideration §21

The security considerations for P2MP TE LSPs are identical to those in RFC 3209 and RFC 3473. No new security vulnerabilities beyond existing RSVP-TE threats are introduced; the RSVP INTEGRITY object mechanism applies equally to P2MP Path, Resv, and error messages.

mpls, routing, security

state-machine §18

When a node receives a Path message matching existing P2MP LSP state (same SESSION, sender address, LSP-ID) but with a different incoming interface, it must distinguish among: dynamic LSP rerouting, re-merge (new branch intersects P2MP LSP at a downstream node on the same outgoing interface), and cross-over (intersection with a different outgoing interface). Specific re-merge detection and data-plane deduplication procedures are defined in section 18.1.

mpls, routing

wire-format §19.2

The P2MP SENDER_TEMPLATE object (C-Type 13 for IPv4, 14 for IPv6) extends the RFC 3209 SENDER_TEMPLATE with a Sub-Group Originator ID (globally unique TE Router ID) and a Sub-Group ID, enabling multiple Path messages and incremental updates to be associated with the same P2MP LSP.

mpls, routing

wire-format §19.1

The P2MP SESSION IPv4 object (C-Type 13) carries a 4-octet P2MP ID, a 2-octet Tunnel ID, and a 4-octet Extended Tunnel ID (ingress LSR address); the IPv6 variant (C-Type 14) uses a 16-octet Extended Tunnel ID. The P2MP ID replaces the Tunnel Endpoint Address of the RFC 3209 SESSION object.

mpls, routing

wire-format §5.1

The Path message is extended with an S2L sub-LSP descriptor list appended after the sender descriptor. Each descriptor is an S2L_SUB_LSP object optionally followed by a P2MP SECONDARY_EXPLICIT_ROUTE object (SERO); the first S2L sub-LSP uses the main ERO rather than a SERO.

mpls, routing

wire-format §11.1

The PathErr message format is extended with an optional S2L sub-LSP descriptor list (one or more S2L_SUB_LSP objects without SEROs) following the sender descriptor, identifying which S2L sub-LSPs experienced the error.

mpls, routing

wire-format §6.1

The Resv message FF flow descriptor and SE filter spec are extended with an S2L sub-LSP flow descriptor list; each entry is an S2L_SUB_LSP object optionally followed by a P2MP_SECONDARY_RECORD_ROUTE object (SRRO). The first S2L sub-LSP's recorded route goes in the main RRO.

mpls, routing

wire-format §19.3

The S2L_SUB_LSP object carries the destination address of an individual leaf: 4 octets for IPv4 (C-Type 1), 16 octets for IPv6 (C-Type 2). It uniquely identifies each S2L sub-LSP within the context of a P2MP LSP alongside the SESSION and SENDER_TEMPLATE.

mpls, routing