< draft-ietf-dime-app-design-guide-18.txt		draft-ietf-dime-app-design-guide-19.txt >
	Diameter Maintenance and Extensions (DIME) L. Morand, Ed.		Diameter Maintenance and Extensions (DIME) L. Morand, Ed.
	Internet-Draft Orange Labs		Internet-Draft Orange Labs
	Intended status: Informational V. Fajardo		Intended status: Informational V. Fajardo
	Expires: December 08, 2013		Expires: December 28, 2013
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	June 06, 2013		June 26, 2013
	Diameter Applications Design Guidelines		Diameter Applications Design Guidelines
	draft-ietf-dime-app-design-guide-18		draft-ietf-dime-app-design-guide-19
	Abstract		Abstract
	The Diameter base protocol provides facilities for protocol		The Diameter base protocol provides facilities for protocol
	extensibility enabling to define new Diameter applications or modify		extensibility enabling to define new Diameter applications or modify
	existing applications. This document is a companion document to the		existing applications. This document is a companion document to the
	Diameter Base protocol that further explains and clarifies the rules		Diameter Base protocol that further explains and clarifies the rules
	to extend Diameter. It is meant as a guidelines document and		to extend Diameter. It is meant as a guidelines document and
	therefore as informative in nature.		therefore as informative in nature.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on December 08, 2013.		This Internet-Draft will expire on December 28, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	5.3. Use of Application-Id in a Message . . . . . . . . . . . 10		5.3. Use of Application-Id in a Message . . . . . . . . . . . 10
	5.4. Application-Specific Session State Machines . . . . . . . 11		5.4. Application-Specific Session State Machines . . . . . . . 11
	5.5. Session-Id AVP and Session Management . . . . . . . . . . 11		5.5. Session-Id AVP and Session Management . . . . . . . . . . 11
	5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 12		5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 12
	5.7. Application-Specific Message Routing . . . . . . . . . . 12		5.7. Application-Specific Message Routing . . . . . . . . . . 12
	5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 13		5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 13
	5.9. End-to-End Application Capabilities Exchange . . . . . . 14		5.9. End-to-End Application Capabilities Exchange . . . . . . 14
	5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 14		5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 14
	5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 16		5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 16
	6. Defining Generic Diameter Extensions . . . . . . . . . . . . 16		6. Defining Generic Diameter Extensions . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. Guidelines for Registrations of Diameter Values . . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18		9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
	11. Informative References . . . . . . . . . . . . . . . . . . . 18		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		12. Informative References . . . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	The Diameter base protocol provides facilities to extend Diameter		The Diameter base protocol provides facilities to extend Diameter
	(see Section 1.3 of [RFC6733]) to support new functionality. In the		(see Section 1.3 of [RFC6733]) to support new functionality. In the
	context of this document, extending Diameter means one of the		context of this document, extending Diameter means one of the
	following:		following:
	1. Addition of new functionality to an existing Diameter application		1. Addition of new functionality to an existing Diameter application
	without defining a new application.		without defining a new application.
	skipping to change at page 17, line 46 ¶		skipping to change at page 17, line 46 ¶
	specify such a use case and perhaps provide specific examples of		specify such a use case and perhaps provide specific examples of
	applications using them.		applications using them.
	In most cases, these optional AVPs piggybacked by applications would		In most cases, these optional AVPs piggybacked by applications would
	be defined as a Grouped AVP and it would encapsulate all the		be defined as a Grouped AVP and it would encapsulate all the
	functionality of the generic extension. In practice, it is not		functionality of the generic extension. In practice, it is not
	uncommon that the Grouped AVP will encapsulate an existing AVP that		uncommon that the Grouped AVP will encapsulate an existing AVP that
	has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS		has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS
	Cx/Dx interfaces ([TS29.228] and [TS29.229]).		Cx/Dx interfaces ([TS29.228] and [TS29.229]).
	7. IANA Considerations		7. Guidelines for Registrations of Diameter Values
			As summarized in the Section 3 of this document and further described
			in the Section 1.3 of [RFC6733], there are four main ways to extend
			Diameter. The process for defining new functionality slightly varies
			based on the different extensions. This section provides protocol
			designers with some guidance regarding the definition of values for
			possible Diameter extensions and the necessary interaction with IANA
			to register the new functionality.
			a. Defining new AVP values
			The specifications defining AVPs and AVP values provide guidance
			for defining new values and the corresponding policy for adding
			these values. For example, the RFC 5777 [RFC5777] defines the
			Treatment-Action AVP which contains a list of valid values
			corresponding to pre-defined actions (drop, shape, mark, permit).
			This set of values can be extended following the Specification
			Required policy defined in [RFC5226]. As a second example, the
			Diameter base specification [RFC6733] defines the Result-Code AVP
			that contains a 32-bit address space used to identity possible
			errors. According to the Section 11.3.2 of [RFC6733], new values
			can be assigned by IANA via an IETF Review process [RFC5226].
			b. Creating new AVPs
			Two different types of AVP Codes namespaces can be used to create
			a new AVPs:
			* IETF AVP Codes namespace;
			* Vendor-specific AVP Codes namespace.
			In the latter case, a vendor needs to be first assigned by IANA
			with a private enterprise number, which can be used within the
			Vendor-Id field of the vendor-specific AVP. This enterprise
			number delimits a private namespace in which the vendor is
			responsible for vendor-specific AVP code value assignment. The
			absence of a Vendor-Id or a Vendor-Id value of zero (0) in the AVP
			header identifies standard AVPs from the IETF AVP Codes namespace
			managed by IANA. The allocation of code values from the IANA-
			managed namespace is conditioned by an Expert Review of the
			specification defining the AVPs or an IETF review if a block of
			AVPs needs to be assigned. Moreover, the remaining bits of the
			AVP Flags field of the AVP header can be also assigned via
			Standard Action if the creation of new AVP Flags is desired.
			c. Creating new commands
			Unlike the AVP Code namespace, the Command Code namespace is flat
			but the range of values is subdivided into three chunks with
			distinct IANA registration policies:
			* A range of standard Command Code values that can be allocated
			via IETF review;
			* A range of vendor-specific Command Code values that can be
			allocated on a First-Come/First-Served basis;
			* A range of values reserved only for experimental and testing
			purposes.
			As for AVP Flags, the remaining bits of the Command Flags field of
			the Diameter header can also be assigned via a Standards Action to
			create new Command Flags if required.
			d. Creating new applications
			Similarly to the Command Code namespace, the Application-Id
			namespace is flat but divided into two distinct ranges:
			* A range of values reserved for standard Application-Ids
			allocated after Expert Review of the specification defining the
			standard application;
			* A range for values for vendor specific applications, allocated
			by IANA on a First-Come/First-Serve basis.
			The IANA AAA parameters page can be found at http://www.iana.org/
			assignments/aaa-parameters/aaa-parameters.xml and the enterprise
			number IANA page is available at http://www.iana.org/assignments/
			enterprise-numbers. More details on the policies followed by IANA
			for namespace management (e.g. First-Come/First-Served, Expert
			Review, IETF Review, etc.) can be found in [RFC5226].
			NOTE:
			When the same functionality/extension is used by more than one
			vendor, it is recommended to define a standard extension.
			Moreover, the registration of vendor-specific extension is
			encouraged to avoid interoperability issues in the same network.
			With this aim, the registration policy of vendor-specific
			extension has been simplified with the publication of [RFC6733]
			and the namespace reserved for vendor-specific extensions is large
			enough to avoid exhaustion.
			8. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	8. Security Considerations		9. Security Considerations
	This document provides guidelines and considerations for extending		This document provides guidelines and considerations for extending
	Diameter and Diameter applications. Although such an extension may		Diameter and Diameter applications. Although such an extension may
	related to a security functionality, the document does not explicitly		related to a security functionality, the document does not explicitly
	give guidance on enhancing Diameter with respect to security.		give guidance on enhancing Diameter with respect to security.
	9. Contributors		10. Contributors
	The content of this document was influenced by a design team created		The content of this document was influenced by a design team created
	to revisit the Diameter extensibility rules. The team consisting of		to revisit the Diameter extensibility rules. The team consisting of
	the members listed below was formed in February 2008 and finished its		the members listed below was formed in February 2008 and finished its
	work in June 2008.		work in June 2008.
	o Avi Lior		o Avi Lior
	o Glen Zorn		o Glen Zorn
	skipping to change at page 18, line 42 ¶		skipping to change at page 20, line 42 ¶
	o Glenn McGregor		o Glenn McGregor
	o Hannes Tschofenig		o Hannes Tschofenig
	o Dave Frascone		o Dave Frascone
	We would like to thank Tolga Asveren, Glenn McGregor, and John		We would like to thank Tolga Asveren, Glenn McGregor, and John
	Loughney for their contributions as co-authors to earlier versions of		Loughney for their contributions as co-authors to earlier versions of
	this document.		this document.
	10. Acknowledgments		11. Acknowledgments
	We greatly appreciate the insight provided by Diameter implementers		We greatly appreciate the insight provided by Diameter implementers
	who have highlighted the issues and concerns being addressed by this		who have highlighted the issues and concerns being addressed by this
	document. The authors would also like to thank Jean Mahoney and Ben		document. The authors would also like to thank Jean Mahoney and Ben
	Campbell for their invaluable detailed review and comments on this		Campbell for their invaluable detailed review and comments on this
	document.		document.
	11. Informative References		12. Informative References
	[I-D.asveren-dime-dupcons]		[I-D.asveren-dime-dupcons]
	Asveren, T., "Diameter Duplicate Detection Cons.", draft-		Asveren, T., "Diameter Duplicate Detection Cons.", draft-
	asveren-dime-dupcons-00 (work in progress), August 2006.		asveren-dime-dupcons-00 (work in progress), August 2006.
	[I-D.calhoun-diameter-res-mgmt]		[I-D.calhoun-diameter-res-mgmt]
	Calhoun, P., "Diameter Resource Management Extensions",		Calhoun, P., "Diameter Resource Management Extensions",
	draft-calhoun-diameter-res-mgmt-08.txt (work in progress),		draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
	March 2001.		March 2001.
	skipping to change at page 19, line 46 ¶		skipping to change at page 21, line 46 ¶
	August 2005.		August 2005.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,		[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
	Canales-Valenzuela, C., and K. Tammi, "Diameter Session		Canales-Valenzuela, C., and K. Tammi, "Diameter Session
	Initiation Protocol (SIP) Application", RFC 4740, November		Initiation Protocol (SIP) Application", RFC 4740, November
	2006.		2006.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,		[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
	and K. Chowdhury, "Diameter Mobile IPv6: Support for		and K. Chowdhury, "Diameter Mobile IPv6: Support for
	Network Access Server to Diameter Server Interaction", RFC		Network Access Server to Diameter Server Interaction", RFC
	5447, February 2009.		5447, February 2009.
	[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,		[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
	and A. Lior, "Traffic Classification and Quality of		and A. Lior, "Traffic Classification and Quality of
	Service (QoS) Attributes for Diameter", RFC 5777, February		Service (QoS) Attributes for Diameter", RFC 5777, February
	2010.		2010.
End of changes. 11 change blocks.
	15 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/