Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects
updates
Extracted elements (15)
The original RFC 5420 Resv message definition did not provide BNF and was ambiguous for P2MP LSPs, preventing different egress LSRs from reporting different operational statuses per S2L sub-LSP. This document adds the S2L sub-LSP flow descriptor placement rule to correct that limitation.
A node supporting RFC 4875 and RFC 5420 but not RFC 6510 will interpret the first LSP_ATTRIBUTES object in a per-S2L-formatted Resv message as representing LSP operational status rather than S2L sub-LSP status. Networks wishing to use per-S2L operational reporting must deploy this extension.
LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects MAY be carried in a Path message. LSRs MUST be prepared to receive these objects in any order in any position within a Path message.
LSP Attributes objects representing S2L sub-LSP status MUST follow a S2L_SUB_LSP object. Only the first instance of LSP_ATTRIBUTES within the context of a S2L_SUB_LSP object is meaningful; subsequent instances SHOULD be ignored and MUST be forwarded unchanged.
LSP_REQUIRED_ATTRIBUTES is RECOMMENDED to be placed immediately after SESSION_ATTRIBUTE (if present) or otherwise immediately after LABEL_REQUEST; if both objects are present, LSP_REQUIRED_ATTRIBUTES SHOULD be placed first.
On a Resv message, LSRs MUST be prepared to receive the LSP_ATTRIBUTES object in any order in any position. Only one instance of LSP_ATTRIBUTES is meaningful within the context of a FILTER_SPEC object; subsequent instances SHOULD be ignored and MUST be forwarded unchanged.
Subsequent instances of LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects within a Path message SHOULD be ignored and MUST be forwarded unchanged.
When a branch node combines Resv state from multiple receivers and an LSP_ATTRIBUTES object is present before the first S2L_SUB_LSP object in a received Resv message, the received LSP_ATTRIBUTES object SHOULD be moved to follow the first received S2L_SUB_LSP object and SHOULD be duplicated for, and placed after, each subsequent S2L_SUB_LSP object.
When an LSP_ATTRIBUTES object is present before the first S2L_SUB_LSP object in a Resv message, it represents the operational status of all S2L sub-LSPs identified in the message; subsequent instances SHOULD be ignored and MUST be forwarded unchanged.
LSP_ATTRIBUTES object (defined in RFC 5420) may be carried in both Path and Resv messages to provide additional information about how an LSP should be set up (Path) or how it has been established (Resv).
LSP_REQUIRED_ATTRIBUTES object (defined in RFC 5420) is carried in Path messages to specify required attributes for LSP establishment; it is distinct from LSP_ATTRIBUTES in that it carries mandatory rather than optional attributes.
This document clarifies usage of objects defined in RFC 5420 and conveys no new information; therefore no additional security considerations are introduced. General MPLS/GMPLS security issues are addressed in the MPLS/GMPLS security framework RFC 5920.
Path message BNF: <Common Header> optionally followed by INTEGRITY, MESSAGE_ID_ACK/NACK, MESSAGE_ID, then SESSION, RSVP_HOP, TIME_VALUES, optional EXPLICIT_ROUTE, LABEL_REQUEST, optional PROTECTION, LABEL_SET, SESSION_ATTRIBUTE, LSP_REQUIRED_ATTRIBUTES, LSP_ATTRIBUTES, NOTIFY_REQUEST, ADMIN_STATUS, POLICY_DATA, sender descriptor, and optional S2L sub-LSP descriptor list.
Resv FF flow descriptor BNF (per-LSP status): [FLOWSPEC] FILTER_SPEC LABEL [LSP_ATTRIBUTES ...] [RECORD_ROUTE] [S2L sub-LSP flow descriptor list]. SE filter spec BNF is analogous.
Resv S2L sub-LSP flow descriptor BNF (per-S2L status): S2L_SUB_LSP [LSP_ATTRIBUTES ...] [P2MP_SECONDARY_RECORD_ROUTE]. LSP_ATTRIBUTES is removed from the FF/SE flow descriptor level and instead placed within each S2L sub-LSP flow descriptor.