One document matched: draft-ietf-dime-capablities-update-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4960 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml'>
<!ENTITY rfc3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-dime-capablities-update-03" ipr="trust200902">
<front>
<title abbrev="Diameter Capabilities Update">The Diameter Capabilities Update Application</title>
<author fullname="Jiao Kang" initials="K." surname="Jiao">
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>Section B1, Huawei Industrial Base</street>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone>+86 755 2878-6690</phone>
<email>kangjiao@huawei.com</email>
</address>
</author>
<author fullname="Glen Zorn" initials="G.Z.." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>1463 East Republican Street </street>
<street>#358</street>
<city>Seattle</city>
<region>WA</region>
<code>98112</code>
<country>USA</country>
</postal>
<email>gwz@net-zen.net</email>
</address>
</author>
<date year="2010"/>
<abstract>
<t>
This document defines a new Diameter application and associated
command codes.
The Capabilities Update application is intended to
allow the dynamic update of certain Diameter peer capabilities while the
peer-to-peer connection is in the open state.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Capabilities exchange is an important component of the Diameter Base
Protocol <xref target="RFC3588"/>,
allowing peers to exchange identities and
Diameter capabilities (protocol version number, supported Diameter
applications, security mechanisms, etc.).
As defined in RFC 3588,
however, the capabilities exchange process takes place only once, at
the inception of a transport connection between a given pair of
peers.
Therefore, if a peer's capabilities change (due to software
update, for example), the existing connection(s) must be torn down
(along with all of the associated user sessions) and restarted before
the modified capabilities can be advertised.
<vspace blankLines="1"/>
This document defines a new Diameter application intended to allow
the dynamic update of a subset of Diameter peer capabilities over an existing
connection.
Because the Capabilities Update application specified
herein operates over an existing transport connection, modification of
certain capabilities is prohibited.
Specifically, modifying the security mechanism in use is not allowed; if the security method
used between a pair of peers is changed the affected connection MUST
be restarted.
<vspace blankLines="1"/>
Discussion of this draft may be directed to the dime Working Group of the IETF
(dime@ietf.org).
</t>
</section>
<section title="Specification of Requirements">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section anchor="DPC" title="Diameter Protocol Considerations">
<t>
This section details the relationship of the Diameter Capabilities
Update application to the Diameter Base Protocol.
<vspace blankLines="1"/>
This document specifies Diameter Application-ID <TBD1>.
Diameter
nodes conforming to this specification MUST advertise support by
including the value <TBD1> in the Auth-Application-Id of the
Capabilities-Exchange-Req and Capabilities-Exchange-Answer commands
<xref target="RFC3588"/>.
</t>
</section>
<section title="Capabilities Update">
<t>
When the capabilities of a Diameter node conforming to this
specification change, it SHOULD notify all of the nodes with which it
has an open transport connection
and have also advertised support for the Capabilities Update application
using the Capabilities-Update-Request
message <xref target="C-U-R"/>.
This message allows the update of a peer's
capabilities (protocol version number, supported
Diameter applications, etc.).
<vspace blankLines="1"/>
A Diameter node only issues a given command to those peers that have advertised
support for the Diameter application that defines the command.
A Diameter node MUST cache the supported applications in order to
ensure that unrecognized commands and/or AVPs are not unnecessarily
sent to a peer.
<vspace blankLines="1"/>
The receiver of the CUR MUST determine
common applications by computing the intersection of its own set of
supported Application Id against all of the application identifier
AVPs (Auth-Application-Id, Acct-Application-Id and Vendor-Specific-
Application-Id) present in the CUR. The value of the Vendor-Id AVP
in the Vendor-Specific-Application-Id MUST NOT be used during
computation.
<vspace blankLines="1"/>
If the receiver of a Capabilities-Update-Req (CUR) message does not
have any applications in common with the sender then it MUST return a
Capabilities-Update-Answer (CUA) <xref target="C-U-A"/>
with the Result-Code AVP set to
DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport
layer connection; however, if active sessions are using the
connection, peers MAY delay disconnection until the sessions can be
redirected or gracefully terminated. Note that receiving a
CUA from a peer advertising itself as a Relay (see <xref target="RFC3588"/>,
Section 2.4) MUST be interpreted as having common applications with the peer.
<vspace blankLines="1"/>
The CUR and CUA messages MUST NOT be proxied, redirected or relayed.
<vspace blankLines="1"/>
Even though the CUR/CUA messages cannot be proxied, it is still possible
for an upstream agent to receive a message for which there are no
peers available to handle the application that corresponds to the
Command-Code. This could happen if, for example, the peers are too busy or down.
In such instances, the 'E' bit MUST be set in the answer
message with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER to
inform the downstream peer to take action (e.g., re-routing requests
to an alternate peer).
</t>
<section anchor="C-CV" title="Command-Code Values">
<t>
This section defines Command-Code <xref target="RFC3588"/>
values that MUST be
supported by all Diameter implementations conforming to this
specification.
The following Command Codes are defined in this
document: Capabilities-Update-Request (CUR, <xref target="C-U-R"/>)
and
Capabilities-Update-Answer (CUA, <xref target="C-U-A"/>).
</t>
<section title="Capabilities-Update-Request" anchor="C-U-R">
<t>
The Capabilities-Update-Request (CUR), indicated by the Command-Code
set to <TBD2> and the Command Flags' 'R' bit set, is sent to update
local capabilities.
Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.
<vspace blankLines="1"/>
When Diameter is run over SCTP <xref target="RFC4960"/>,
which allows connections to
span multiple interfaces and multiple IP addresses, the Capabilities-
Update-Request message MUST contain one Host-IP-Address AVP for each
potential IP address that may be locally used when transmitting
Diameter messages.
<figure>
<artwork><![CDATA[
Message Format
<CUR> ::= < Diameter Header: TBD2, REQ >
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]
]]></artwork>
</figure>
</t>
</section>
<section title="Capabilities-Update-Answer" anchor="C-U-A">
<t>
The Capabilities-Update-Answer indicated by the Command-Code set to
<TBD3> and the Command Flags' 'R' bit set, is sent in response to a
CUR message.
<figure align="center">
<artwork><![CDATA[
Message Format
<CUA> ::= < Diameter Header: TBD3 >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Error-Message ]
* [ AVP ]
]]></artwork>
</figure>
</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>
The security considerations applicable to the Diameter Base Protocol <xref target="RFC3588"/>
are also applicable to this document.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This section explains the criteria to be used by the IANA for
assignment of numbers within namespaces used within this document.
</t>
<section title="Application Identifier">
<t>
This specification assigns the value <TBD1> from the Application
Identifiers namespace defined in RFC 3588. See <xref target="DPC"/>
for the assignment of the namespace in this specification.
</t>
</section>
<section title="Command Codes">
<t>
This specification assigns the values <TBD2> and <TBD3> from the
Command Codes namespace defined in RFC 3588. See <xref target="C-CV"/>
for the assignment of the namespace in this specification.
</t>
</section>
</section>
<section title="Contributors">
<t>
This document is based upon work done by Tina Tsou.
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks to Sebastien Decugis, Niklas Neumann,
Subash Comerica and Ravi for helpful discussion.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3588;
</references>
<references title="Informative References">
&rfc4960;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:36:20 |