Subject: RE: [AAA-WG]: Questions on RFC 3588

From: <[email-masked]>
Date: Mon, 3 May 2004 10:04:17 +0300

Hello Ulrich,

> 3GPP have defined a vendor-specific Diameter-Application (3GPP Cx Rel-5) for which IANA has 
> allocated an application-Id (167772151). Now  3GPP are in the process of defining a new version 
> of this application (3GPP Cx Rel-6). The new version is an extension of the old version,i.e. 
> nodes supporting the new version do also support the old version. The new version does not 
> replace the old version, i.e. interworking between nodes supporting only the old version and 
> nodes supporting the old and the new version is required.
>
> Let us assume that the difference between the old version and the new version is that a new AVP 
> is added to a command and this AVP has the M-bit set.

A new mandatory AVP is a requirement for a new application ID.

> The first question is: Is it necessary to get a new application-Id allocated by IANA for the 
> new version, or is it possible for both versions to share the same (already allocated) 
> application-Id, and to achieve interoperability between the two versions by means of the mechanism 
> defined in RFC 3588 section 4.1 (description of the 'M' bit), i.e. the node sending the new 
> mandatory AVP must be prepared to receive error code 5001 (unsupported AVP) and re-send the command 
> in a Rel-5 compliant form?

If you wanted the above behavior, the new AVP defined by 3GPP should not be mandatory, but it should
be optional, then the above behavior would be compliant to 3588.

> Here are some quotes from RFC 3588 which you might want to consider when answering the question:

> -In section 1.1: "AVPs may be added arbitrarily to Diameter messages, so long as the required AVPs 
> are included and AVPs that are explicitly excluded are not included." 
> -In section 1.2.3:" 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."
> -In section 1.2.3:"Creation of a new application should be viewed as a last resort."  

Defining new applications are a last resort, of course.  A real reason for having a new application
would be because you are adding new functionality to Diameter that cannot be met with existing
applicaitions.  Adding a new AVPs would not really qualify, in my opinion, unless they drastically
changed the behavior.

> The second question  is similar: If the difference between the old version and the new version 
> is that an existing mandatory AVP is removed from a command is it then necessary to get a 
> new application-Id allocated, or can interoperability be achieved in the way that the node 
> omitting the mandatory AVP must be prepared to receive error 5005 (missing AVP) and re-send the 
> command in a Rel-5 compliant form?

You are saying that you are removing an mandatory AVP?  I guess to ensure interoperability, a new
Application ID would be needed - but why are you removing the AVP? The question is quite hypothetical,
and it is hard to advise the proper behavior without more concrete examples.

> The last question: If the difference beween the old version and the new version is that a new 
> command is added is it then necessary to get a new application-Id allocated, or can interoperability 
> be achieved in the way that the node sending the new command must be prepared to receive the error 
> 3001 (unsupported command)  and fall back to Rel-5?

In general, adding new commands mean that a new Application ID is needed.

However, your questions are extremely hypothetical.  The important questions are why
are you adding new (mandatory) AVPs and commands.  Are these really needed?  Arbitrarily adding
new mandatory AVPs and commands create interoperability problems, and that is why the Diameter
Base spec tries to advise against doing so, unless absolutely necessarily.

best regards,
John

---

From: "Wiehe Ulrich" <[email-masked]>
Date: Mon, 3 May 2004 11:02:54 +0200

Hello John,

Thank you for your response. I'm not sure whether I correctly understand your
answer. Can you please confirm that

a) A new mandatory AVP (i.e. an AVP which is not surrounded by square
brackets in the command's ABNF definition) is a requirement for a new
application ID.

b) A new optional AVP (i.e. an AVP surrounded by square brackets in the
command's ABNF definition) may be added without requiring a new application
ID. If the optional AVP's M-bit is set the behavior described in RFC 3588
section 4.1 applies i.e. the sending (Rel-6) node shall be prepared to
receive error 5001 and may then decide to re-send the command in a Rel-5
compliant form. If the optional AVP's M-bit is cleared the reciving(Rel-5)
node will silently discard the AVP.

Thank you again
Ulrich

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Montag, 3. Mai 2004 09:04
An: Wiehe Ulrich; [email-masked]
Betreff: RE: [AAA-WG]: Questions on RFC 3588

Hello Ulrich,

> in a Rel-5 compliant form?

If you wanted the above behavior, the new AVP defined by 3GPP should not be
mandatory, but it should
be optional, then the above behavior would be compliant to 3588.

> -In section 1.2.3:"Creation of a new application should be viewed as a last
resort."  

Defining new applications are a last resort, of course.  A real reason for
having a new application
would be because you are adding new functionality to Diameter that cannot be
met with existing
applicaitions.  Adding a new AVPs would not really qualify, in my opinion,
unless they drastically
changed the behavior.

> command in a Rel-5 compliant form?

You are saying that you are removing an mandatory AVP?  I guess to ensure
interoperability, a new
Application ID would be needed - but why are you removing the AVP? The
question is quite hypothetical,
and it is hard to advise the proper behavior without more concrete examples.

However, your questions are extremely hypothetical.  The important questions
are why
are you adding new (mandatory) AVPs and commands.  Are these really needed?
Arbitrarily adding
new mandatory AVPs and commands create interoperability problems, and that is
why the Diameter
Base spec tries to advise against doing so, unless absolutely necessarily.

best regards,
John

---

From: <[email-masked]>
Date: Tue, 4 May 2004 06:55:27 +0300

Hi Ulrich,

> Thank you for your response. I'm not sure whether I correctly
> understand your answer. Can you please confirm that
>
> a) A new mandatory AVP (i.e. an AVP which is not surrounded
> by square brackets in the command's ABNF definition) is a
> requirement for a new application ID.

Yes, a new mandatory AVP is one requirement for a new Applicaiton 
ID.

> b) A new optional AVP (i.e. an AVP surrounded by square
> brackets in the command's ABNF definition) may be added
> without requiring a new application ID. If the optional AVP's
> M-bit is set the behavior described in RFC 3588 section 4.1
> applies i.e. the sending (Rel-6) node shall be prepared to
> receive error 5001 and may then decide to re-send the command
> in a Rel-5 compliant form. If the optional AVP's M-bit is
> cleared the reciving(Rel-5) node will silently discard the AVP.

Basically, yes.  You've defined a 3GPP Cx applicaiton. If new
AVPs are added to this application, they need to be optional.
If you want to add mandatory new AVPs, you most likely need
a new Application ID.

It seems that you really want some sort of improved negotiation
capabilities in your application.  This could be added to the
application, so that it could support negotiating the of 3GPP
release versions inside of the application. This is something
that would be rather tricky - negotiation capabilities can
be complex.  There was some discussion of having additional
negotiation capabilities in the AAA a few years ago, but the
WG decided not to persue it.

best regards,
John

---

From: <[email-masked]>
Date: Tue, 4 May 2004 07:45:03 +0300

Lionel,

> I think that the problem comes from the text identifying the 
> rules for the creation of new applications (section 1.2.3 in 
> RFC 3588):
> 
> " [...]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. [...]
> 
> [...]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."
> 
> From my understanding, a mandatory AVP is used in the RFC 
> 3588 for an AVP that must be supported by the application i.e 
> AVP with the M-bit set, regardless of whether it is required 
> or optional within the ABNF description of the command which 
> the AVP is included in.
> 
> Therefore, the rule "adding new AVPs to the command, which 
> have the bit "M" bit set" is not clear: does this apply for 
> addition of a new "required" AVP in the ABNF descritpion of 
> the command, creation of a new AVP that must be supported by 
> the application, or for both?

Basically, if a mandatory AVP is not supported, then it cannot
be said that the application is fully supporting the specification.
Mandatory means that it MUST be supported.

New AVPs with the M bit set cannot be added to an existing application.

John

---

From: "Wiehe Ulrich" <[email-masked]>
Date: Tue, 4 May 2004 08:59:54 +0200

Hi John,

Thank you for this clarification.

I do not want to introduce new or improve existing negotiation capabilities.
I just want to understand and possibly make use of the existing mechanism
defined in RFC 3588 chapter 4.1. My understanding of the existing mechanism
is:
a) you may add AVPs arbitrarily (see 3588 chapter 1.1).
b1) If the added AVPs M-bit is set, the not supporting receiver shall return
error 5001 (see 3588 chapter 7.1.5). When receiving error 5001, the sender
shall re-send the command without the new AVP (see 3588 section 4.1).
b2) If the added AVPs M-bit is not set, the not supporting receiver may
discard the new AVP (see 3588 section 4.1).

From your answers I understand that you do not share my view. Can you please
point me to text in RFC 3588 indicating that my understanding of the existing
mechanism is not correct, or indicating that this mechanism must not be used.

Best regards
Ulrich

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 4. Mai 2004 05:55
An: Wiehe Ulrich; [email-masked]
Betreff: RE: RE : [AAA-WG]: Questions on RFC 3588

Hi Ulrich,

best regards,
John

---

From: <[email-masked]>
Date: Tue, 4 May 2004 10:27:35 +0300

Hi Ulrich,

Starting in with:

1) 5.3.  Capabilities Exchange

   When two Diameter peers establish a transport connection, they MUST
   exchange the Capabilities Exchange messages, as specified in the peer
   state machine (see Section 5.6).  This message allows the discovery
   of a peer's identity and its capabilities (protocol version number,
   supported Diameter applications, security mechanisms, etc.)

   The receiver only issues commands to its 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 AVPs are not unnecessarily
   sent to a peer.

-> CEA/CER is used to advertise supported Diameter applications, so that
   unrecognized commands and/or AVPs are not sent to a peer.

2.1) Section 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.

-> I interpret this to mean that adding a new mandatory AVP to 
   a command is considered a major change, requiring a new
   application.

2.2) Section 1.2.4.  Creating New Accounting Applications

   ...

   When two Diameter peers establish a transport connection, they MUST
   exchange the Capabilities Exchange messages, as specified in the peer
   state machine (see Section 5.6).  This message allows the discovery
   of a peer's identity and its capabilities (protocol version number,
   supported Diameter applications, security mechanisms, etc.)

   The receiver only issues commands to its 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 AVPs are not unnecessarily
   sent to a peer.

-> I interpret this to mean, for example, applications can add new AVPs
   to an accounting application, as long as the M bit is not set.

3) Section 4.1.  AVP Header

   ....

      The 'M' bit MUST be set according to the rules defined for the AVP
      containing it.  In order to preserve interoperability, a Diameter
      implementation MUST be able to exclude from a Diameter message any
      Mandatory AVP which is neither defined in the base Diameter
      protocol nor in any of the Diameter Application specifications
      governing the message in which it appears.  It MAY do this in one
      of the following ways:

      1) If a message is rejected because it contains a Mandatory AVP
         which is neither defined in the base Diameter standard nor in
         any of the Diameter Application specifications governing the
         message in which it appears, the implementation may resend the
         message without the AVP, possibly inserting additional standard
         AVPs instead.

      2) A configuration option may be provided on a system wide, per
         peer, or per realm basis that would allow/prevent particular
         Mandatory AVPs to be sent.  Thus an administrator could change
         the configuration to avoid interoperability problems.

-> Interpret this to mean that if an instance of an application receives
   a command with an AVP that has the M bit set, but is not defined with
   that application, it can reject the message. However, there is no mandatory
   behavior.  An conformant application could silently discard the message
   as well.  There is no discussion about falling back to another version
   of the application, etc.

> mechanism is not correct, or indicating that this mechanism  must not be used.

I will follow-up in another mail, about this in a more general way.

John

---

From: "Wiehe Ulrich" <[email-masked]>
Date: Tue, 4 May 2004 09:37:30 +0200

Dear Lionel,

My understanding of the text you are quoting is:
a) adding a new AVP with M-bit set is a major change.
b) for major changes it *may be desirable* to create a new application (but
it is not an absolute must).
c) if you want to create a new application, you must define a new Command or
add a new mandatory AVP to the ABNF. The text does not say: if you want to
add a new command or a new mandatory AVP, you must create a new application.

Best regards
Ulrich

-----Ursprüngliche Nachricht-----
Von: MORAND Lionel FTRD/DAC/ISS [mailto:[email-masked]] 
Gesendet: Montag, 3. Mai 2004 17:18
An: Wiehe Ulrich; [email-masked]; [email-masked]
Betreff: RE : [AAA-WG]: Questions on RFC 3588

Hi,

I think that the problem comes from the text identifying the rules for the
creation of new applications (section 1.2.3 in RFC 3588):

" [...]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:

[...]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."

From my understanding, a mandatory AVP is used in the RFC 3588 for an AVP
that must be supported by the application i.e AVP with the M-bit set,
regardless of whether it is required or optional within the ABNF description
of the command which the AVP is included in.

Therefore, the rule "adding new AVPs to the command, which have the bit "M"
bit set" is not clear: does this apply for addition of a new "required" AVP
in the ABNF descritpion of the command, creation of a new AVP that must be
supported by the application, or for both?

BR,

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> De la part de Wiehe Ulrich
> Envoyé : lundi 3 mai 2004 11:03
> À : [email-masked]; [email-masked]
> Objet : AW: [AAA-WG]: Questions on RFC 3588
>
>
> Hello John,
>
> > 3GPP have defined a vendor-specific Diameter-Application (3GPP Cx
> > Rel-5)
> for which IANA has
> > allocated an application-Id (167772151). Now  3GPP are in
> the process
> > of
> defining a new version
> > of this application (3GPP Cx Rel-6). The new version is an
> extension
> > of the
> old version,i.e.
> > nodes supporting the new version do also support the old
> version. The
> > new
> version does not
> > replace the old version, i.e. interworking between nodes supporting
> > only
> the old version and
> > Let us assume that the difference between the old version
> and the new
> version is that a new AVP
> > new version, or is it possible for both versions to share the same
> > (already
> allocated)
> > application-Id, and to achieve interoperability between the two
> > versions by
> means of the mechanism
> > defined in RFC 3588 section 4.1 (description of the 'M'
> bit), i.e. the
> > node
> sending the new
> > mandatory AVP must be prepared to receive error code 5001
> (unsupported
> > AVP)
> and re-send the command
> If you wanted the above behavior, the new AVP defined by 3GPP
> should not be mandatory, but it should be optional, then the
> above behavior would be compliant to 3588.
>
> > Here are some quotes from RFC 3588 which you might want to consider
> > when
> answering the question:
>
> > -In section 1.1: "AVPs may be added arbitrarily to Diameter
> messages,
> > so
> long as the required AVPs
> > -In section 1.2.3:" 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
> > -In section 1.2.3:"Creation of a new application should be
> viewed as a
> > last
> resort." 
>
> Defining new applications are a last resort, of course.  A
> real reason for having a new application would be because you
> are adding new functionality to Diameter that cannot be met
> with existing applicaitions.  Adding a new AVPs would not
> really qualify, in my opinion, unless they drastically
> changed the behavior.
>
> > The second question  is similar: If the difference between the old
> > version
> and the new version
> > is that an existing mandatory AVP is removed from a command
> is it then
> necessary to get a
> > new application-Id allocated, or can interoperability be
> achieved in
> > the
> way that the node
> > omitting the mandatory AVP must be prepared to receive error 5005
> > (missing
> AVP) and re-send the
> You are saying that you are removing an mandatory AVP?  I
> guess to ensure interoperability, a new Application ID would
> be needed - but why are you removing the AVP? The question is
> quite hypothetical, and it is hard to advise the proper
> behavior without more concrete examples.
>
> > The last question: If the difference beween the old version and the
> > new
> version is that a new
> However, your questions are extremely hypothetical.  The
> important questions are why are you adding new (mandatory)
> AVPs and commands.  Are these really needed? Arbitrarily
> adding new mandatory AVPs and commands create
> interoperability problems, and that is why the Diameter Base
> spec tries to advise against doing so, unless absolutely necessarily.
>
> best regards,
> John
>