The 16-bit Association ID field in the original ASSOCIATION object limits an association source to at most 65536 distinct associations, which is insufficient for centralized entities managing large numbers of associations or for MPLS-TP LSP identification requiring operator-unique global identifiers (ASN-based Global_ID).

mpls, routing

The ASSOCIATION object was originally defined for GMPLS recovery contexts, but this document generalizes it for broader use across GMPLS LSPs, MPLS LSPs, and non-LSP RSVP sessions to associate RSVP state for resource sharing, voice call-waiting, shared lines, and symmetric NAT scenarios.

mpls, routing

Association matching, in the absence of type-specific comparison rules, is based on comparison of all fields in an ASSOCIATION object. This applies equally to standard and Extended ASSOCIATION objects. No associations are made across Path state and Resv state.

mpls, routing

The ASSOCIATION object uses Class-Num of the form 11bbbbbb (value 199) ensuring that non-supporting nodes ignore the object but forward it without modification per RFC 2205. Transit nodes that support ASSOCIATION but not Extended C-Types will forward without modification; egress nodes may generate an 'Unknown object C-Type' error that propagates to ingress.

mpls, routing

A node that wishes to allow upstream nodes to associate Resv state across RSVP sessions MUST include an ASSOCIATION object in the outgoing Resv messages corresponding to those sessions. In the absence of type-specific rules, the included ASSOCIATION objects MUST be identical.

mpls, routing

The IPv4 and IPv6 Extended ASSOCIATION objects SHOULD be supported by an implementation compliant with this document. Their processing MUST be identical to the processing of IPv4 and IPv6 ASSOCIATION objects except as extended in Section 4.

mpls, routing

The Resource Sharing Association Type (value 2) MUST be supported by any implementation compliant with this document. Once an association is identified, resources MUST be considered as shared across the identified sessions by the admission-control function.

mpls, routing

To indicate association between multiple sessions, a node sending a Path message MUST include an appropriate ASSOCIATION object in the outgoing Path messages corresponding to each of the associated sessions. In the absence of Association-Type-specific rules, the included ASSOCIATION object MUST be identical across those messages.

mpls, routing

Unless there are type-specific processing rules, downstream nodes MUST forward all ASSOCIATION objects received in a Path message in any corresponding outgoing Path messages without modification. This MUST also be followed for unknown Association Type field values.

mpls, routing

Unless there are type-specific processing rules, upstream nodes MUST forward all ASSOCIATION objects received in a Resv message in any corresponding outgoing Resv messages without modification, including for unknown Association Type field values.

mpls, routing

When a node receives a Path message, it MUST check each ASSOCIATION object to determine if the Association Type is supported, then MUST check for matching objects in Path state of all other sessions. Matching MUST continue after a match is found and MUST be performed against all local Path state.

mpls, routing

When creating an ASSOCIATION object, the originator MUST format the object per RFC 4872 Section 16.1, MUST set the Association Type field based on the type of association, MUST set the Association ID to a value unique within the Association Source context, and MUST set the Association Source to a unique address assigned to the originating node.

mpls, routing

When the Extended Association ID field is omitted, the object Length MUST be set to 16 (IPv4) or 28 (IPv6). When included, the Length field MUST indicate the additional bytes including pad bytes. The Extended Association ID field MUST be set to a value that, together with all other fields, uniquely identifies the association.

mpls, routing

The Association ID field is generalized from 'a value assigned by the LSP head-end' to 'a value assigned by the node that originated the association.' When combined with the Association Type and Association Source fields, it uniquely identifies an association.

mpls, routing

The Extended Association ID field is variable-length and 4-byte aligned, scoped by the Association Source. It MUST have length zero or be 4-byte aligned. It MUST be included when the Association ID field alone is insufficient to uniquely identify the association within the scope of the source.

mpls, routing

The Global Association Source field (4 bytes) in Extended ASSOCIATION objects contains the RFC 6370 Global_ID (operator's ASN-based identifier) or the special value zero (indicating no global identifier). Zero SHOULD be limited to entities within a single operator. For 2-octet ASNs, the two high-order octets MUST be set to zero.

mpls, routing

Two association types are currently defined: recovery (from RFC 4872/4873, applicable only to recovery contexts) and resource sharing (type value 2, applicable to any RSVP session type in both Path and Resv messages). Unknown association types are forwarded without modification.

mpls, routing

Upstream-initiated association is carried in ASSOCIATION objects in Path messages and associates RSVP Path state across MPLS Tunnels/RSVP sessions. Downstream-initiated association is carried in ASSOCIATION objects in Resv messages and associates RSVP Resv state. Association is never made across Path state and Resv state.

mpls, routing

IANA assigned two new C-Types for the existing ASSOCIATION object (Class-Num 199) in the RSVP Parameters registry: C-Type 3 for IPv4 Extended Association and C-Type 4 for IPv6 Extended Association, both defined by RFC 6780.

registry, mpls, routing

IANA updated the 'Association Type' registry in the GMPLS Signaling Parameters registry to add RFC 6780 as a reference for the Resource Sharing Association Type (value 2) alongside RFC 4873, and corrected a duplicate '(R)' designation to '(S)'.

registry, mpls, routing

This document does not introduce new security risks. The broader usage of the ASSOCIATION object in Section 3 does not fundamentally expand the association function from RFC 4872/4873, and the Extended ASSOCIATION objects in Section 4 add only 32 bits of additional information not fundamentally different from existing RSVP information. For general MPLS/GMPLS security, RFC 5920 applies.

security, mpls, routing

Path messages for MPLS/GMPLS sessions include the ASSOCIATION object(s) after SESSION_ATTRIBUTE and before POLICY_DATA; for non-LSP sessions, ASSOCIATION appears after TIME_VALUES and before POLICY_DATA. Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes.

mpls, routing

Resv messages for MPLS, GMPLS, and non-LSP sessions include ASSOCIATION object(s) after SCOPE and before POLICY_DATA, with the format: Common Header, INTEGRITY (opt), SESSION, RSVP_HOP, TIME_VALUES, RESV_CONFIRM (opt), SCOPE (opt), ASSOCIATION (0+), POLICY_DATA (0+), STYLE, flow descriptor list.

mpls, routing

The IPv4 Extended ASSOCIATION object (Class-Num 199, C-Type 3) contains: Length (16 bits), Class-Num (8 bits), C-Type (8 bits), Association Type (16 bits), Association ID (16 bits), IPv4 Association Source (32 bits), Global Association Source (32 bits), and variable-length 4-byte-aligned Extended Association ID.

mpls, routing, ip

The IPv6 Extended ASSOCIATION object (Class-Num 199, C-Type 4) contains: Length (16 bits), Class-Num (8 bits), C-Type (8 bits), Association Type (16 bits), Association ID (16 bits), IPv6 Association Source (128 bits), Global Association Source (32 bits), and variable-length 4-byte-aligned Extended Association ID.

mpls, routing, ip