Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls
updated by
- rfc-6001 — Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
updates
- rfc-3473 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
Extracted elements (28)
Calls are defined as symmetrical: either end may add LSPs or initiate teardown. This symmetry is why a numeric address comparison rule is required to resolve Call setup collisions when both ends simultaneously attempt to establish Calls with matching long Call IDs.
Calls are established independently of Connections through the Notify message rather than Path/Resv messages. Simultaneous Call and Connection establishment (piggybacking) is explicitly not supported to maintain full and logical Call/Connection separation.
The Call_ID is only relevant at sender and receiver nodes; no maintenance of Call state at intermediate nodes is mandated. This design ensures no change in RFC 3473 transit implementations is required and there are no backward compatibility issues.
The LINK_CAPABILITY object's Class Number (133, form 10bbbbbb) is deliberately selected so that nodes not recognizing this object drop it silently. The top bit is set and the next bit is cleared, following RSVP's unknown object handling rules to allow backward-compatible deployment.
If a Path or Resv message is received with a non-zero Call ID but without the C bit set, and the Call ID is not recognized, the receiver is RECOMMENDED to assume Call establishment is delayed and ignore the message. If the Call never materializes, failure to refresh will cause the LSPs to be torn down.
In user-initiated Calls where the first core node acts as External Call Manager, neither long nor short Call ID is supplied by the edge node (Session Name Length=0, Call_ID=0). The first core node generates both IDs before dispatching the Notify to the remote Call endpoint.
Transit nodes that do not support Call management may zero the previously-reserved Call_ID field before forwarding SESSION objects, which will prevent LSP setup for Calls. Use of Explicit Routes may help by avoiding such nodes, but ultimately offending nodes may need to be upgraded.
A Call MUST NOT be imposed upon a Connection that is already established. Doing so would require changing the short Call ID in the SESSION object, constituting a change in Session Identifier which is prohibited by existing protocol specifications.
Call collision resolution uses a numeric address comparison: if a node's source address is numerically greater than the remote source address, it MUST discard the received conflicting Call setup and wait for a response to its own. If numerically smaller, it MUST discard its own setup state and respond to the received Call setup request.
During Call setup the ERROR_SPEC object MUST carry Error Code zero ('Confirmation'). At least one session MUST be listed in the notify session list. Message IDs MUST be used during Call setup to ensure reliable delivery.
If a node receives a Call setup request with an address pair and long Call ID matching an existing Call, it MUST return an error Notify message with Error Code 'Call Management' and Error Value 'Duplicate Call', and MUST NOT make any changes to the existing Call.
If a Notify teardown request (D bit set) is received for a Call that still has existing LSP Connections, the request MUST be rejected with Error Code 'Call Management' and Error Value 'Connections Still Exist'. The state of the Call MUST NOT be changed.
It MUST be possible to establish a Connection without dependence on a Call, and a Call without any associated Connections. It MUST be possible to associate more than one Connection with a Call. Signaling of a Connection associated with a Call MUST NOT require the distribution or retention of Call-related state within the network.
Periodic Notify messages SHOULD be sent by the initiator and terminator of the Call for keepalive. The period is RECOMMENDED to be twice the shortest LSP refresh period; when no LSPs exist, a refresh period of no less than one minute is RECOMMENDED.
Removal of the last Connection associated with a Call SHOULD NOT result in the automatic removal of the Call except as a matter of local policy at the ingress of the Call.
The C bit of the ADMIN_STATUS object MUST NOT be set on LSP messages (including Notify messages pertaining to LSPs) and MUST be ignored when received on such messages.
The Call_ID value of zero is reserved and MUST NOT be used during LSP-independent Call establishment. Zero indicates that the LSP is not associated with any Call.
The short Call ID is a 16-bit identifier that MUST be exchanged on the Notify message during Call initialization and used on all subsequent LSP messages associated with the Call. The Call ID MUST NOT be used as part of the processing to determine the session to which an RSVP signaling message applies.
When a single LINK_CAPABILITY object reports multiple links, each link MUST be identified by an identifier subobject (Type 1, 2, or 4), and capability subobjects (Types 64, 65) MUST be placed after the identifier subobject for the link or bundle to which they refer.
The LINK_CAPABILITY object (Class-Num=133, C-Type=1) is introduced to carry link-local capability information during Call setup. It contains subobjects: Types 1/2/4 for link identification (IPv4, IPv6, unnumbered), Type 64 for Maximum Reservable Bandwidth, and Type 65 for interface switching capability descriptor.
The long Call ID is carried in the 'Session Name' field of the SESSION_ATTRIBUTE object on the Notify message used for Call establishment. It is only required on that Notify message and need not appear in subsequent LSP messages.
IANA assigned bit number 28 in the 'Administrative Status Information Flags' sub-registry of the 'GMPLS Signaling Parameters' registry for the new C (Call Management) bit of the ADMIN_STATUS object defined in this document.
IANA assigned LINK_CAPABILITY object Class-Num=133 (form 10bbbbbb), C-Type=1 in the 'RSVP Parameters' registry. IANA maintains a subobject list; initial subobjects are Types 1 (IPv4 link), 2 (IPv6 link), 4 (unnumbered link), 64 (Max Reservable Bandwidth), and 65 (interface switching capability descriptor).
IANA assigned new RSVP Error Code 'Call Management' (value 32) and four Error Values: Call ID Contention (1), Connections Still Exist (2), Unknown Call ID (3), and Duplicate Call (4) in the 'RSVP Parameters' error codes registry.
Call setup is vulnerable to spoofing and denial-of-service attacks because it uses Notify messages. Deployments where security is a concern SHOULD protect Notify messages using the INTEGRITY object as described in RFC 2205 and RFC 3473. Implementations MAY additionally use IPsec (RFC 4302/4303) or RSVP security (RFC 2747).
Key exchange for Call-related message security should be configured or arranged dynamically per deployment per RFC 4107. Since Call endpoints are not necessarily IP-adjacent in the control plane, key exchange must be treated as a remote procedure; IKEv2 (RFC 4306) is particularly suggested by RFC 3473.
The ADMIN_STATUS object is extended with a new 'C' (Call Management) bit at bit position 28. When set, it indicates the Notify message is being used to control or manage a Call rather than an LSP.
The SESSION object (Class=1, C-Type=7 for IPv4, C-Type=8 for IPv6) is extended with a 16-bit Call_ID field placed immediately before the existing 16-bit Tunnel ID. The field was previously reserved (required to be zero on transmission, ignored on receipt), ensuring backward compatibility.