Subject: [AAA-WG]: Issue 365: Revised Extensibility Section

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Sep 2002 11:46:29 -0700 (PDT)

Issue 365: Revised Extensibility Section
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: S
Section: 1.2
Rationale/Explanation of issue:

This revision is designed to clarify the issue of
extensibility to make it clear that addition of
non-mandatory AVPs does not require definition of a
new application ID.

Replace section 1.2 with the following:

"1.2 Approach to Extensibility

The Diameter protocol is designed to be extensible, using
several mechanisms, including:

- Defining new AVP values.
- Creating new AVPs
- Creating new authentication/authorization applications
- Creating new accounting applications
- Application authentication procedures

Reuse of existing AVP values, AVPs, applications and command codes
are strongly recommended. Reuse simplifies standardization and
implementation and avoids potential interoperability issues.

1.2.1 Defining New AVP Values

New applications should attempt to reuse AVPs defined in existing
applications when possible, as opposed to creating new AVPs. For AVPs
of type Enumerated an application may require a new
value to communicate some service-specific information.

In order to allocate a new AVP value, a request MUST be
sent to IANA [IANA], along with an explanation of the new
AVP value. IANA considerations for Diameter are discussed
in Section 11.

1.2.2 Creating New AVPs

When no existing AVP can be used, a new AVP should
be created. The new AVP being defined MUST use one of the
data types listed in section 4.3.

In the event that a logical grouping of AVPs is necessary, and
multiple "groups" are possible in a given command, it is
recommended that a Grouped AVP be used (see Section 4.5).

In order to create a new AVP, a request MUST be sent to IANA,
with a specification for the AVP. The request MUST include
the commands that would make use of the AVP.

1.2.3 Creating New Authentication Applications

Every Diameter application specification MUST have an IANA assigned
Application Identifier (see section 2.4) or a vendor specific
Application Identifier.

Should a new Diameter usage scenario find itself unable to fit
within an existing application without requiring major changes to the
specification, it may be desirable to create a new Diameter
application. Major changes to an application include:

- Adding new AVPs to the command, which have the "M" bit set.

- Requiring a command that has a different number of round trips
to satisfy a request (e.g. application foo has a command that
requires one round trip, but new application bar has a command
that requires two round trips to complete).

- Adding support for an authentication method requiring definition of
new AVPs for use with the application. Since a new EAP authentication
method can be supported within Diameter without requiring new AVPs,
addition of EAP methods does not require the creation of a new
authentication
application.

Creation of a new application should be viewed as a last resort.
An implementation MAY add arbitrary non-mandatory AVPs to any
command defined in an application, including vendor-specific AVPs without
needing to define a new application. Please refer to section 11.1.1 for
details.

In order to justify allocation of a new application identifier, Diameter
applications MUST define one Command Code, or add new mandatory AVPs to
the ABNF.

The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see section
3.2). If the Diameter application has accounting requirements, it
MUST also specify the AVPs that are to be present in the Diameter
Accounting messages (see section 9.3). However, just because a new
authentication application id is required, does not imply that a new
accounting application id is required.

When possible, a new Diameter application SHOULD reuse
existing Diameter AVPs, in order to avoid defining
multiple AVPs that carry similar information.

1.2.4 Creating New Accounting Applications

There are services that only require Diameter accounting.
Such services need to define the AVPs carried in the ACR/ACA messages,
but do not need to define new command codes. An implementation MAY add
arbitrary non-mandatory AVPs (e.g. AVPs with the "M" bit not set) to any
command defined in an application, including vendor-specific
AVPs, without needing to define a new accounting application. Please
refer to section 11.1.1 for details.

Application Identifiers are still required for Diameter capability
exchange. Every accounting application MUST have either an IANA
allocated Application Identifier, or a vendor specific Application
Identifier.

Since every Diameter implementation MUST support accounting, there
is no need to advertise support for the Base accounting application
within the CER/CEA, since this is implicit. This basic accounting
support is sufficient to handle any application that uses the
ACR/ACA commands defined in this document, as long as no new
mandatory AVPs are added. A mandatory AVP is defined as one
which has the "M" bit set when sent within an accounting command,
regardless of whether it is required or optional within the ABNF for
the accounting application.

The creation of a new accounting application should be viewed as a
last resort and MUST NOT be used unless a new command is defined with
the application, or new mandatory AVPs are added to the ABNF.

Within an accounting command, setting the "M" bit implies that
the backend billing server MUST understand the AVP in order to compute
a correct bill. If the AVP is not relevant to the billing process, when
the AVP is included within an accounting command, it MUST NOT
have the "M" bit set, even if the "M" bit is set when the same AVP is
used within other Diameter commands.

When possible, a new Diameter accounting application SHOULD attempt
to reuse existing AVPs, in order to to avoid defining multiple AVPs
that carry similar information.

Every Diameter accounting application specification MUST have an IANA
assigned Application Identifier (see section 2.4) or a vendor specific
Application Identifier."