draft-ietf-dime-capablities-update-01.txt		draft-ietf-dime-capablities-update-02.txt
	Network Working Group K. Jiao		Network Working Group K. Jiao
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track G. Zorn		Intended status: Standards Track G. Zorn
	Expires: June 4, 2010 Network Zen		Expires: August 30, 2010 Network Zen
	December 1, 2009		February 26, 2010
	The Diameter Capabilities Update Application		The Diameter Capabilities Update Application
	draft-ietf-dime-capablities-update-01		draft-ietf-dime-capablities-update-02
	Abstract		Abstract
	This document defines a new Diameter application and associated		This document defines a new Diameter application and associated
	command codes. The Capabilities Update application is intended to		command codes. The Capabilities Update application is intended to
	allow the dynamic update of Diameter peer capabilities while the		allow the dynamic update of certain Diameter peer capabilities while
	peer-to-peer connection is in the open state.		the peer-to-peer connection is in the open state.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 4, 2010.		This Internet-Draft will expire on August 30, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	2. Specification of Requirements . . . . . . . . . . . . . . . . . 3		2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
	3. Diameter Protocol Considerations . . . . . . . . . . . . . . . 3		3. Diameter Protocol Considerations . . . . . . . . . . . . . . . 3
	4. Capabilities Update . . . . . . . . . . . . . . . . . . . . . . 3		4. Capabilities Update . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. Command-Code Values . . . . . . . . . . . . . . . . . . . . 4		4.1. Command-Code Values . . . . . . . . . . . . . . . . . . . . 4
	4.1.1. Capabilities-Update-Request . . . . . . . . . . . . . . 5		4.1.1. Capabilities-Update-Request . . . . . . . . . . . . . . 5
	4.1.2. Capabilities-Update-Answer . . . . . . . . . . . . . . 5		4.1.2. Capabilities-Update-Answer . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Application Identifier . . . . . . . . . . . . . . . . . . 6		6.1. Application Identifier . . . . . . . . . . . . . . . . . . 6
	6.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 6		6.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 6
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
			9.2. Informative References . . . . . . . . . . . . . . . . . . 7
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	Capabilities exchange is an important component of the Diameter Base		Capabilities exchange is an important component of the Diameter Base
	Protocol [RFC3588], allowing peers to exchange identities and		Protocol [RFC3588], allowing peers to exchange identities and
	Diameter capabilities (protocol version number, supported Diameter		Diameter capabilities (protocol version number, supported Diameter
	applications, security mechanisms, etc.). As defined in RFC 3588,		applications, security mechanisms, etc.). As defined in RFC 3588,
	however, the capabilities exchange process takes place only once, at		however, the capabilities exchange process takes place only once, at
	the inception of a transport connection between a given pair of		the inception of a transport connection between a given pair of
	peers. Therefore, if a peer's capabilities change (due to software		peers. Therefore, if a peer's capabilities change (due to software
	update, for example), the existing connection(s) must be torn down		update, for example), the existing connection(s) must be torn down
	(along with all of the associated user sessions) and restarted before		(along with all of the associated user sessions) and restarted before
	the modified capabilities can be advertised.		the modified capabilities can be advertised.
	This document defines a new Diameter application intended to allow		This document defines a new Diameter application intended to allow
	the dynamic update of Diameter peer capabilities over an existing		the dynamic update of a subset of Diameter peer capabilities over an
	connection. Because the Capabilities Update application specified		existing connection. Because the Capabilities Update application
	here operates over an existing transport connection, modification of		specified herein operates over an existing transport connection,
	the security mechanism in use is not allowed; if the security method		modification of certain capabilities is prohibited. Specifically,
	used between a pair of peers is changed the affected connection MUST		modifying the security mechanism in use is not allowed; if the
	be restarted.		security method used between a pair of peers is changed the affected
			connection MUST be restarted.
	Discussion of this draft may be directed to the dime Working Group of		Discussion of this draft may be directed to the dime Working Group of
	the IETF (dime@ietf.org).		the IETF (dime@ietf.org).
	2. Specification of Requirements		2. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 4, line 10		skipping to change at page 4, line 11
	4. Capabilities Update		4. Capabilities Update
	When the capabilities of a Diameter node conforming to this		When the capabilities of a Diameter node conforming to this
	specification change, it SHOULD notify all of the nodes with which it		specification change, it SHOULD notify all of the nodes with which it
	has an open transport connection and have also advertised support for		has an open transport connection and have also advertised support for
	the Capabilities Update application using the Capabilities-Update-		the Capabilities Update application using the Capabilities-Update-
	Request message Section 4.1.1. This message allows the update of a		Request message Section 4.1.1. This message allows the update of a
	peer's capabilities (protocol version number, supported Diameter		peer's capabilities (protocol version number, supported Diameter
	applications, etc.).		applications, etc.).
	The receiver only issues commands to its peers that have advertised		A Diameter node only issues a given command to those peers that have
	support for the Diameter application that defines the command. A		advertised support for the Diameter application that defines the
	Diameter node MUST cache the supported applications in order to		command. A Diameter node MUST cache the supported applications in
	ensure that unrecognized commands and/or AVPs are not unnecessarily		order to ensure that unrecognized commands and/or AVPs are not
	sent to a peer.		unnecessarily sent to a peer.
	The receiver of the CUR MUST determine common applications by		The receiver of the CUR MUST determine common applications by
	computing the intersection of its own set of supported Application Id		computing the intersection of its own set of supported Application Id
	against all of the application identifier AVPs (Auth-Application-Id,		against all of the application identifier AVPs (Auth-Application-Id,
	Acct-Application-Id and Vendor-Specific- Application-Id) present in		Acct-Application-Id and Vendor-Specific- Application-Id) present in
	the CUR. The value of the Vendor-Id AVP in the Vendor-Specific-		the CUR. The value of the Vendor-Id AVP in the Vendor-Specific-
	Application-Id MUST NOT be used during computation.		Application-Id MUST NOT be used during computation.
	If the receiver of a Capabilities-Update-Req (CUR) message does not		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		have any applications in common with the sender then it MUST return a
	skipping to change at page 6, line 27		skipping to change at page 6, line 27
	This specification assigns the value <TBD1> from the Application		This specification assigns the value <TBD1> from the Application
	Identifiers namespace defined in RFC 3588. See Section 3 for the		Identifiers namespace defined in RFC 3588. See Section 3 for the
	assignment of the namespace in this specification.		assignment of the namespace in this specification.
	6.2. Command Codes		6.2. Command Codes
	This specification assigns the values <TBD2> and <TBD3> from the		This specification assigns the values <TBD2> and <TBD3> from the
	Command Codes namespace defined in RFC 3588. See Section 4.1 for the		Command Codes namespace defined in RFC 3588. See Section 4.1 for the
	assignment of the namespace in this specification.		assignment of the namespace in this specification.
	7. References		7. Contributors
	7.1. Normative References		This document is based upon work done by Tina Tsou.
			8. Acknowledgements
			Thanks to Sebastien Decugis, Niklas Neumann, Subash Comerica and Ravi
			for helpful discussion.
			9. References
			9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.		[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
	Arkko, "Diameter Base Protocol", RFC 3588, September 2003.		Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
	7.2. Informative References		9.2. Informative References
	[RFC4960] Stewart, R., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
	RFC 4960, September 2007.		RFC 4960, September 2007.
	Authors' Addresses		Authors' Addresses
	Jiao Kang		Jiao Kang
	Huawei Technologies		Huawei Technologies
	Section B1, Huawei Industrial Base		Section B1, Huawei Industrial Base
	Bantian, Longgang District		Bantian, Longgang District
End of changes. 11 change blocks.
	25 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/