The Diameter Capabilities Update Application
Extracted elements (19)
In RFC 3588, capabilities exchange occurs only once at transport connection inception. If a peer's capabilities change, all existing connections and associated user sessions must be torn down and restarted. This application enables dynamic update of a subset of Diameter peer capabilities over an existing connection, avoiding that disruption.
Modifying the security mechanism in use is explicitly prohibited over an existing connection. If the security method between a pair of peers must change, the affected connection MUST be restarted, ensuring that capability updates do not weaken or bypass the established security context.
A Diameter node must cache the supported applications of its peers in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer, as a node only issues a command to peers that have advertised support for the application defining that command.
Diameter nodes conforming to this specification MUST advertise support for the Capabilities Update application by including the value 10 in the Auth-Application-Id AVP of the CER and CEA commands.
If an upstream agent receives a CUR/CUA message for which no peers are available to handle the corresponding application (e.g., peers are too busy or down), the 'E' bit MUST be set in the answer with Result-Code set to DIAMETER_UNABLE_TO_DELIVER.
If the receiver of a CUR has no applications in common with the sender, it MUST return a CUA with Result-Code set to DIAMETER_NO_COMMON_APPLICATION and SHOULD disconnect the transport-layer connection. If active sessions are using the connection, peers MAY delay disconnection until sessions can be redirected or gracefully terminated.
Receiving a CUA from a peer advertising itself as a relay MUST be interpreted as having common applications with that peer, consistent with relay semantics in the Diameter base protocol.
The CUR and CUA messages MUST NOT be proxied, redirected, or relayed, mirroring the same restriction that applies to CER/CEA messages in the Diameter base protocol.
The receiver of a CUR MUST determine common applications by computing the intersection of its own supported Application Ids against all Auth-Application-Id, Acct-Application-Id, and Vendor-Specific-Application-Id AVPs present in the CUR. The Vendor-Id AVP in Vendor-Specific-Application-Id MUST NOT be used during this computation.
Upon detection of a transport failure, the CUR message MUST NOT be sent to an alternate peer.
When Diameter is run over SCTP, which allows connections to span multiple interfaces and IP addresses, the CUR message MUST contain one Host-IP-Address AVP for each potential IP address that may be locally used when transmitting Diameter messages.
When the capabilities of a Diameter node change, the node MUST notify all peers with which it has an open transport connection and which have advertised support for the Capabilities Update application, using the Capabilities-Update-Request (CUR) message.
The Capabilities-Update-Answer (CUA) is a Diameter command with Command Code 328 and the 'R' bit cleared, sent in response to a CUR. It carries Origin-Host, Origin-Realm, a mandatory Result-Code AVP, and an optional Error-Message AVP.
The Capabilities-Update-Request (CUR) is a new Diameter command with Command Code 328 and the 'R' bit set. It carries the sender's updated capabilities including Origin-Host, Origin-Realm, one or more Host-IP-Address AVPs, Vendor-Id, Product-Name, and optional application support AVPs.
IANA assigned Application Identifier value 10 (Diameter Capabilities Update) from the Diameter Application Identifiers namespace defined in RFC 6733.
IANA assigned Command Code value 328 for both the Capabilities-Update-Request (CUR) and Capabilities-Update-Answer (CUA) from the Diameter Command Codes namespace defined in RFC 6733.
All security considerations applicable to the Diameter base protocol (RFC 6733) apply equally to this specification. Additionally, modification of the security mechanism in use is prohibited over an existing connection; any change to the security method requires the connection to be restarted.
The CUA message format is: Diameter Header with Command Code 328 (R bit cleared); mandatory Origin-Host, Origin-Realm, Result-Code; optional Error-Message and additional AVPs.
The CUR message format is: Diameter Header with Command Code 328 and REQ flag; mandatory Origin-Host, Origin-Realm, one or more Host-IP-Address, Vendor-Id, Product-Name; optional Origin-State-Id, zero or more Supported-Vendor-Id, Auth-Application-Id, Acct-Application-Id, Vendor-Specific-Application-Id, Firmware-Revision, and additional AVPs.