< draft-ietf-dime-app-design-guide-26.txt   draft-ietf-dime-app-design-guide-27.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: Best Current Practice V. Fajardo Intended status: Best Current Practice V. Fajardo
Expires: February 17, 2015 Fluke Networks Expires: March 8, 2015 Fluke Networks
H. Tschofenig H. Tschofenig
ARM Ltd.
August 16, 2014 September 4, 2014
Diameter Applications Design Guidelines Diameter Applications Design Guidelines
draft-ietf-dime-app-design-guide-26 draft-ietf-dime-app-design-guide-27
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. Furthermore, this document provides guidelines to extend Diameter. Furthermore, this document provides guidelines
to Diameter application designers reusing/defining Diameter to Diameter application designers reusing/defining Diameter
applications or creating generic Diameter extensions. applications or creating generic Diameter extensions.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 February 17, 2015. This Internet-Draft will expire on March 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 27 skipping to change at page 2, line 27
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Reusing Existing Diameter Applications . . . . . . . . . . . 5 4. Reusing Existing Diameter Applications . . . . . . . . . . . 6
4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 6 4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 6
4.2. Deleting an Existing Command . . . . . . . . . . . . . . 7 4.2. Deleting an Existing Command . . . . . . . . . . . . . . 7
4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 7 4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 7
4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 7 4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 8
4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 9 4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 9
4.3.3. Changing the Flags Setting of AVP in existing 4.3.3. Changing the Flags Setting of AVP in existing
Commands . . . . . . . . . . . . . . . . . . . . . . 10 Commands . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 10 4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 10
4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 10 4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 11
4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 11 4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 11
5. Defining New Diameter Applications . . . . . . . . . . . . . 11 5. Defining New Diameter Applications . . . . . . . . . . . . . 11
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 11 5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 12
5.3. Use of Application-Id in a Message . . . . . . . . . . . 12 5.3. Use of Application-Id in a Message . . . . . . . . . . . 12
5.4. Application-Specific Session State Machines . . . . . . . 13 5.4. Application-Specific Session State Machines . . . . . . . 13
5.5. Session-Id AVP and Session Management . . . . . . . . . . 13 5.5. Session-Id AVP and Session Management . . . . . . . . . . 13
5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 14 5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 14
5.7. Application-Specific Message Routing . . . . . . . . . . 16 5.7. Application-Specific Message Routing . . . . . . . . . . 16
5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 17 5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 17
5.9. End-to-End Application Capabilities Exchange . . . . . . 17 5.9. End-to-End Application Capabilities Exchange . . . . . . 18
5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 18 5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 18
5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 20 5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 20
6. Defining Generic Diameter Extensions . . . . . . . . . . . . 20 6. Defining Generic Diameter Extensions . . . . . . . . . . . . 20
7. Guidelines for Registrations of Diameter Values . . . . . . . 22 7. Guidelines for Registrations of Diameter Values . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The Diameter base protocol [RFC6733] is intended to provide an The Diameter base protocol [RFC6733] is intended to provide an
Authentication, Authorization, and Accounting (AAA) framework for Authentication, Authorization, and Accounting (AAA) framework for
applications such as network access or IP mobility in both local and applications such as network access or IP mobility in both local and
roaming situations. roaming situations. This protocol provides the ability for Diameter
peers to exchange messages carrying data in the form of Attribute-
Value Pairs (AVPs).
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.
2. Addition of new functionality to an existing Diameter application 2. Addition of new functionality to an existing Diameter application
skipping to change at page 17, line 33 skipping to change at page 17, line 44
RADIUS-Diameter translation agent were put into the Diameter NASREQ RADIUS-Diameter translation agent were put into the Diameter NASREQ
Application ([RFC4005]). Application ([RFC4005]).
However, it was acknowledged that such translation mechanism was not However, it was acknowledged that such translation mechanism was not
so obvious and deeper protocol analysis was required to ensure so obvious and deeper protocol analysis was required to ensure
efficient interworking between RADIUS and Diameter. Moreover, the efficient interworking between RADIUS and Diameter. Moreover, the
interworking requirements depend on the functionalities provided by interworking requirements depend on the functionalities provided by
the Diameter application under specification, and a case-by-case the Diameter application under specification, and a case-by-case
analysis is required. As a consequence, all the material related to analysis is required. As a consequence, all the material related to
RADIUS-to-Diameter translation is removed from the new version of the RADIUS-to-Diameter translation is removed from the new version of the
Diameter NASREQ application specification [RFC4005bis], (see Diameter NASREQ application specification [RFC7155], which deprecates
[RFC7155]) which deprecates the RFC4005 ([RFC4005]). the RFC4005 ([RFC4005]).
Therefore, protocol designers SHOULD NOT assume the availability of a Therefore, protocol designers SHOULD NOT assume the availability of a
"standard" Diameter-to-RADIUS gateways agent when planning to "standard" Diameter-to-RADIUS gateways agent when planning to
interoperate with the RADIUS infrastructure. They SHOULD specify the interoperate with the RADIUS infrastructure. They SHOULD specify the
required translation mechanism along with the Diameter application, required translation mechanism along with the Diameter application,
if needed. This recommendation applies for any kind of translation. if needed. This recommendation applies for any kind of translation.
5.9. End-to-End Application Capabilities Exchange 5.9. End-to-End Application Capabilities Exchange
Diameter applications can rely on optional AVPs to exchange Diameter applications can rely on optional AVPs to exchange
skipping to change at page 19, line 20 skipping to change at page 19, line 27
differentiate received accounting messages. Since the received differentiate received accounting messages. Since the received
accounting messages can be for any application and/or service, the accounting messages can be for any application and/or service, the
accounting server MUST have a method to match accounting messages accounting server MUST have a method to match accounting messages
with applications and/or services being accounted for. This may with applications and/or services being accounted for. This may
mean defining new AVPs, checking the presence, absence or contents mean defining new AVPs, checking the presence, absence or contents
of existing AVPs, or checking the contents of the accounting of existing AVPs, or checking the contents of the accounting
record itself. One of these means could be to insert into the record itself. One of these means could be to insert into the
request sent to the accounting server an Auth-Application-Id AVP request sent to the accounting server an Auth-Application-Id AVP
containing the identifier of the application for which the containing the identifier of the application for which the
accounting request is sent. But in general, there is no clean and accounting request is sent. But in general, there is no clean and
generic scheme for sorting these messages. Therefore, the use of generic scheme for sorting these messages. Therefore, this model
this model is NOT RECOMMENDED when all received accounting SHOULD NOT be used when all received accounting messages cannot be
messages cannot be clearly identified and sorted. For most cases, clearly identified and sorted. For most cases, the use of Coupled
the use of Coupled Accounting Model is RECOMMENDED. Accounting Model is RECOMMENDED.
Coupled Accounting Model: Coupled Accounting Model:
In this model, the accounting messages will use the Application Id In this model, the accounting messages will use the Application Id
of the application using the accounting service. The design of the application using the accounting service. The design
implication for this is that the accounting messages are tightly implication for this is that the accounting messages are tightly
coupled with the application itself; meaning that accounting coupled with the application itself; meaning that accounting
messages will be routed like the other application messages. It messages will be routed like the other application messages. It
would then be the responsibility of the application server would then be the responsibility of the application server
(application entity receiving the ACR message) to send the (application entity receiving the ACR message) to send the
skipping to change at page 20, line 11 skipping to change at page 20, line 18
* The system architecture or deployment requires that the * The system architecture or deployment requires that the
accounting service for the specific application should be accounting service for the specific application should be
handled by the application itself. handled by the application itself.
In all cases above, there will generally be no direct Diameter In all cases above, there will generally be no direct Diameter
access to the accounting server. access to the accounting server.
These models provide a basis for using accounting messages. These models provide a basis for using accounting messages.
Application designers may obviously deviate from these models Application designers may obviously deviate from these models
provided that the factors being addressed here have also been taken provided that the factors being addressed here have also been taken
into account. Defining a new set of commands to carry application- into account. As a general recommendation, application designers
specific accounting records is NOT RECOMMENDED. SHOULD NOT define a new set of commands to carry application-specific
accounting records.
5.11. Diameter Security Mechanisms 5.11. Diameter Security Mechanisms
As specified in [RFC6733], the Diameter message exchange SHOULD be As specified in [RFC6733], the Diameter message exchange SHOULD be
secured between neighboring Diameter peers using TLS/TCP or DTLS/ secured between neighboring Diameter peers using TLS/TCP or DTLS/
SCTP. However, IPsec MAY also be deployed to secure communication SCTP. However, IPsec MAY also be deployed to secure communication
between Diameter peers. When IPsec is used instead of TLS or DTLS, between Diameter peers. When IPsec is used instead of TLS or DTLS,
the following recommendations apply. the following recommendations apply.
IPsec ESP [RFC4301] in transport mode with non-null encryption and IPsec ESP [RFC4301] in transport mode with non-null encryption and
skipping to change at page 27, line 36 skipping to change at page 27, line 43
Phone: +33145296257 Phone: +33145296257
Email: lionel.morand@orange.com Email: lionel.morand@orange.com
Victor Fajardo Victor Fajardo
Fluke Networks Fluke Networks
Email: vf0213@gmail.com Email: vf0213@gmail.com
Hannes Tschofenig Hannes Tschofenig
ARM Ltd.
Hall in Tirol 6060 Hall in Tirol 6060
Austria Austria
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 14 change blocks. 
20 lines changed or deleted 22 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/