From a3bf1bdf235009441c9f29acc140148eccb254d8 Mon Sep 17 00:00:00 2001 From: Anders Svensson Date: Thu, 22 Nov 2012 17:15:02 +0100 Subject: Add copies of RFC's 6733 and 6737 6733 deprecates 3588. --- .../draft-ietf-dime-capablities-update-07.txt | 392 --------------------- 1 file changed, 392 deletions(-) delete mode 100644 lib/diameter/doc/standard/draft-ietf-dime-capablities-update-07.txt (limited to 'lib/diameter/doc/standard/draft-ietf-dime-capablities-update-07.txt') diff --git a/lib/diameter/doc/standard/draft-ietf-dime-capablities-update-07.txt b/lib/diameter/doc/standard/draft-ietf-dime-capablities-update-07.txt deleted file mode 100644 index bb7ec2d08c..0000000000 --- a/lib/diameter/doc/standard/draft-ietf-dime-capablities-update-07.txt +++ /dev/null @@ -1,392 +0,0 @@ - - - -Network Working Group K. Jiao -Internet-Draft Huawei -Intended status: Standards Track G. Zorn -Expires: April 27, 2011 Network Zen - October 24, 2010 - - - The Diameter Capabilities Update Application - draft-ietf-dime-capablities-update-07 - -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 Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on April 27, 2011. - -Copyright Notice - - Copyright (c) 2010 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 Expires April 27, 2011 [Page 1] - -Internet-Draft Diameter Capabilities Update October 2010 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 - 3. Diameter Protocol Considerations . . . . . . . . . . . . . . . 3 - 4. Capabilities Update . . . . . . . . . . . . . . . . . . . . . . 3 - 4.1. Command-Code Values . . . . . . . . . . . . . . . . . . . . 4 - 4.1.1. Capabilities-Update-Request . . . . . . . . . . . . . . 5 - 4.1.2. Capabilities-Update-Answer . . . . . . . . . . . . . . 5 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - 6.1. Application Identifier . . . . . . . . . . . . . . . . . . 6 - 6.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jiao & Zorn Expires April 27, 2011 [Page 2] - -Internet-Draft Diameter Capabilities Update October 2010 - - -1. Introduction - - Capabilities exchange is an important component of the Diameter Base - Protocol [I-D.ietf-dime-rfc3588bis], 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. - - 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]. - - -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 . Diameter - nodes conforming to this specification MUST advertise support by - including the value in the Auth-Application-Id of the - Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer - (CEA) commands [I-D.ietf-dime-rfc3588bis]. - - -4. Capabilities Update - - When the capabilities of a Diameter node conforming to this - specification change, it 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 - - - -Jiao & Zorn Expires April 27, 2011 [Page 3] - -Internet-Draft Diameter Capabilities Update October 2010 - - - 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 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. - - 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 [I-D.ietf-dime-rfc3588bis], 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 - [I-D.ietf-dime-rfc3588bis], 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. - - 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 [I-D.ietf-dime-rfc3588bis] values - that MUST be supported by all Diameter implementations conforming to - this specification. The following Command Codes are defined (using - modified ABNF [I-D.ietf-dime-rfc3588bis]) in this document: - Capabilities-Update-Request (CUR, Section 4.1.1) and Capabilities- - Update-Answer (CUA, Section 4.1.2). - - - -Jiao & Zorn Expires April 27, 2011 [Page 4] - -Internet-Draft Diameter Capabilities Update October 2010 - - -4.1.1. Capabilities-Update-Request - - The Capabilities-Update-Request (CUR), indicated by the Command-Code - set to 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 - [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 - - ::= < Diameter Header: , 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 ] - -4.1.2. Capabilities-Update-Answer - - The Capabilities-Update-Answer, indicated by the Command-Code set to - and the Command Flags' 'R' bit cleared, is sent in response to - a CUR message. - - Message Format - - ::= < Diameter Header: > - { Origin-Host } - { Origin-Realm } - { Result-Code } - [ Error-Message ] - * [ AVP ] - - - - - - - - -Jiao & Zorn Expires April 27, 2011 [Page 5] - -Internet-Draft Diameter Capabilities Update October 2010 - - -5. Security Considerations - - The security considerations applicable to the Diameter Base Protocol - [I-D.ietf-dime-rfc3588bis] 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 from the Application - Identifiers namespace [I-D.ietf-dime-rfc3588bis]. See Section 3 for - the assignment of the namespace in this specification. - -6.2. Command Codes - - This specification assigns the value from the Command Codes - namespace [I-D.ietf-dime-rfc3588bis]. 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. - - -9. References - -9.1. Normative References - - [I-D.ietf-dime-rfc3588bis] - Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, - "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-25 - (work in progress), September 2010. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - -Jiao & Zorn Expires April 27, 2011 [Page 6] - -Internet-Draft Diameter Capabilities Update October 2010 - - -9.2. Informative References - - [RFC4960] Stewart, R., "Stream Control Transmission Protocol", - RFC 4960, September 2007. - - -Authors' Addresses - - Jiao Kang - Huawei Technologies - Section B1, Huawei Industrial Base - Bantian, Longgang District - Shenzhen 518129 - P.R. China - - Phone: +86 755 2878-6690 - Email: kangjiao@huawei.com - - - Glen Zorn - Network Zen - 227/358 Thanon Sanphawut - Bang Na, Bangkok 10260 - Thailand - - Phone: +66 (0) 87-040-4617 - Email: gwz@net-zen.net - - - - - - - - - - - - - - - - - - - - - - - - -Jiao & Zorn Expires April 27, 2011 [Page 7] - -- cgit v1.2.3