aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/standard/rfc6737.txt
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2012-11-23 15:43:37 +0100
committerAnders Svensson <[email protected]>2012-11-23 15:43:37 +0100
commitd8d53aefc3234a37ad9308949d122c265f90cca9 (patch)
treeafbaed05738399b660fa967c88bb9ae8c67a4c2d /lib/diameter/doc/standard/rfc6737.txt
parent744c5e4232fd010c6630831a6b15ecd19ec7ac80 (diff)
parent2810e848c24d93b2292a08f2df0293166cf32ee6 (diff)
downloadotp-d8d53aefc3234a37ad9308949d122c265f90cca9.tar.gz
otp-d8d53aefc3234a37ad9308949d122c265f90cca9.tar.bz2
otp-d8d53aefc3234a37ad9308949d122c265f90cca9.zip
Merge branch 'anders/diameter/doc/OTP-10568' into maint
* anders/diameter/doc/OTP-10568: Update doc for RFC 6733 Add copies of RFC's 6733 and 6737
Diffstat (limited to 'lib/diameter/doc/standard/rfc6737.txt')
-rw-r--r--lib/diameter/doc/standard/rfc6737.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/lib/diameter/doc/standard/rfc6737.txt b/lib/diameter/doc/standard/rfc6737.txt
new file mode 100644
index 0000000000..50aa33e98f
--- /dev/null
+++ b/lib/diameter/doc/standard/rfc6737.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Jiao
+Request for Comments: 6737 Huawei
+Category: Standards Track G. Zorn
+ISSN: 2070-1721 Network Zen
+ October 2012
+
+
+ The Diameter Capabilities Update Application
+
+Abstract
+
+ 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6737.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+Jiao & Zorn Standards Track [Page 1]
+
+RFC 6737 Diameter Capabilities Update October 2012
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2
+ 3. Diameter Protocol Considerations . . . . . . . . . . . . . . . 3
+ 4. Capabilities Update . . . . . . . . . . . . . . . . . . . . . . 3
+ 4.1. Command Code Values . . . . . . . . . . . . . . . . . . . . 4
+ 4.1.1. Capabilities-Update-Request . . . . . . . . . . . . . . 4
+ 4.1.2. Capabilities-Update-Answer . . . . . . . . . . . . . . 5
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 6.1. Application Identifier . . . . . . . . . . . . . . . . . . 5
+ 6.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 6
+
+1. Introduction
+
+ Capabilities exchange is an important component of the Diameter base
+ protocol [RFC6733], 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 a 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.
+
+ 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.
+
+2. Specification of Requirements
+
+ 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 RFC 2119 [RFC2119].
+
+
+
+
+
+Jiao & Zorn Standards Track [Page 2]
+
+RFC 6737 Diameter Capabilities Update October 2012
+
+
+3. Diameter Protocol Considerations
+
+ This section details the relationship of the Diameter Capabilities
+ Update application to the Diameter base protocol.
+
+ This document specifies Diameter Application-Id 10. Diameter nodes
+ conforming to this specification MUST advertise support by including
+ the value 10 in the Auth-Application-Id of the Capabilities-Exchange-
+ Request (CER) and Capabilities-Exchange-Answer (CEA) commands
+ [RFC6733].
+
+4. Capabilities Update
+
+ When the capabilities of a Diameter node conforming to this
+ specification change, the node MUST notify all of the nodes with
+ which it has an open transport connection and which have also
+ advertised support for the Capabilities Update application using the
+ Capabilities-Update-Request (CUR) message (Section 4.1.1). This
+ message allows the update of a peer's capabilities (supported
+ Diameter applications, etc.).
+
+ 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 Attribute-Value
+ Pairs (AVPs) are not unnecessarily sent to a peer.
+
+ The receiver of the CUR MUST determine common applications by
+ computing the intersection of its own set of supported Application
+ Ids against all of the Application-Id 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.
+
+ If the receiver of a CUR does not have any applications in common
+ with the sender, then it MUST return a Capabilities-Update-Answer
+ (CUA) (Section 4.1.2) with the Result-Code AVP set to
+ DIAMETER_NO_COMMON_APPLICATION [RFC6733], and it 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
+ [RFC6733], Section 2.4) MUST be interpreted as having common
+ applications with the peer.
+
+ As for CER/CEA messages, the CUR and CUA messages MUST NOT be
+ proxied, redirected, or relayed.
+
+
+
+
+Jiao & Zorn Standards Track [Page 3]
+
+RFC 6737 Diameter Capabilities Update October 2012
+
+
+ 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).
+
+4.1. Command Code Values
+
+ This section defines Command Code [RFC6733] 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, Section 4.1.1), and
+ Capabilities-Update-Answer (CUA, Section 4.1.2). The Diameter
+ Command Code Format (CCF) ([RFC6733], Section 3.2) is used in the
+ definitions.
+
+4.1.1. Capabilities-Update-Request
+
+ The Capabilities-Update-Request (CUR), indicated by the Command Code
+ set to 328 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.
+
+ When Diameter is run over the Stream Control Transmission Protocol
+ (SCTP) [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.
+
+ Message Format
+
+ <CUR> ::= < Diameter Header: 328, 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 ]
+
+
+
+
+Jiao & Zorn Standards Track [Page 4]
+
+RFC 6737 Diameter Capabilities Update October 2012
+
+
+4.1.2. Capabilities-Update-Answer
+
+ The Capabilities-Update-Answer, indicated by the Command Code set to
+ 328 and the Command Flags' 'R' bit cleared, is sent in response to a
+ CUR message.
+
+ Message Format
+
+ <CUA> ::= < Diameter Header: 328 >
+ { Origin-Host }
+ { Origin-Realm }
+ { Result-Code }
+ [ Error-Message ]
+ * [ AVP ]
+
+5. Security Considerations
+
+ The security considerations applicable to the Diameter base protocol
+ [RFC6733] are also applicable to this document.
+
+6. IANA Considerations
+
+ This section explains the criteria to be used by the IANA for
+ assignment of numbers within namespaces used within this document.
+
+6.1. Application Identifier
+
+ This specification assigns the value 10 (Diameter Capabilities
+ Update) from the Application Identifiers namespace [RFC6733]. See
+ Section 3 for the assignment of the namespace in this specification.
+
+6.2. Command Codes
+
+ This specification assigns the value 328 (Capabilities-Update-
+ Request/Capabilities-Update-Answer (CUR/CUA)) from the Command Codes
+ namespace [RFC6733]. See Section 4.1 for the assignment of the
+ namespace in this specification.
+
+7. Contributors
+
+ This document is based upon work done by Tina Tsou.
+
+8. Acknowledgements
+
+ Thanks to Sebastien Decugis, Niklas Neumann, Subash Comerica, Lionel
+ Morand, Dan Romascanu, Dan Harkins, and Ravi for helpful review and
+ discussion.
+
+
+
+
+Jiao & Zorn Standards Track [Page 5]
+
+RFC 6737 Diameter Capabilities Update October 2012
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
+ "Diameter Base Protocol", RFC 6733, October 2012.
+
+9.2. Informative References
+
+ [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
+ RFC 4960, September 2007.
+
+Authors' Addresses
+
+ Jiao Kang
+ Huawei Technologies
+ Section F1, Huawei Industrial Base
+ Bantian, Longgang District
+ Shenzhen 518129
+ P.R. China
+
+
+
+ Glen Zorn
+ Network Zen
+ 227/358 Thanon Sanphawut
+ Bang Na, Bangkok 10260
+ Thailand
+
+ Phone: +66 (0) 909-201060
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jiao & Zorn Standards Track [Page 6]
+