Subject: [AAA-WG]: AW: Application support in Diameter

From: "Wiehe Ulrich" <[email-masked]>
Date: Tue, 4 May 2004 11:52:55 +0200

John,

RFC 3588 section 4.1 says:
"If an AVP with the 'M' bit set is received by a Diameter client, server,
proxy, or translation agent and either the AVP or its value is unrecognized,
the message MUST be rejected."

Therefore I'm afraid you are not right in saying that "A Diameter
implementation receiving a command with a new mandatory AVP is not required
to process the message in any way."  

If more than one new AVPs with M-bit set are added then only the first
unsupported one is required to be returned. The sender may re-send the
command omitting this AVP, but will receiver a second 5001 error. Again, the
sender may re-send the command omitting also the second AVP and so on.
Eventually the command will not be rejected with 5001. To avoid this multiple
round trip it would be a good idea to return all unsupported AVPs (the first
detected one must be returned, the others may be returned). Note that 3588
section 7.1.5 says: " A Diameter message with this error MUST contain one or
more Failed-AVP AVP containing the AVPs that caused the failure.

Ulrich

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 4. Mai 2004 09:38
An: Wiehe Ulrich; [email-masked]
Betreff: Application support in Diameter

Hi all,

There have been a number of mails about Application IDs and mandatory AVPs,
and
so forth in Diameter.  It seems that there is a desire to support application
versioning (at least adding new mandatory AVPs to existing applications.

It is my opinion that an implementation adding additional mandatory AVPs
cannot
be considered conformant to the Diameter Application if it does this.  A
Diameter
implementation receiving a command with a new mandatory AVP is not required
to process the message in any way.  It MAY send an error with error code
5001,
but is not required to.  Additionally, if more than one unsupported mandatory
AVP 
is sent, Section 7 says:

   The Result-Code AVP describes the error that the Diameter node
   encountered in its processing.  In case there are multiple errors,
   the Diameter node MUST report only the first error it encountered
   (detected possibly in some implementation dependent order).  

Therefore, it is problematic to add mandatory AVPs to existing
implementations
and it is the intent of the Diameter Base Specification to require a new
Application
in instances when new mandatory AVPs are required.

John

---

From: <[email-masked]>
Date: Tue, 4 May 2004 13:59:53 +0300

Hi Ulrich,

> to process the message in any way."  

The first paragraph you show above is correct.  The RFC isn't exactly
clear on what a recieving end should do if it does recieve an AVP with
the M bit set that it doesn't understand. Anyhow, this is a small point,
not the main point that you are discussing.
 
> more Failed-AVP AVP containing the AVPs that caused the failure.

This is optional behavior in the Diameter base specification, it is not mandatory
behavior.  If you want to have this kind of behavior, it would probably be
best to make this as a requirement in your Diameter Application.

John

---

From: <[email-masked]>
Date: Tue, 4 May 2004 14:09:16 +0300

Hi,

> command omitting this AVP, but will receiver a second 5001 
> error. Again, the sender may re-send the command omitting also the second
> AVP and so on. Eventually the command will not be rejected with 5001.

I think we should not base application version control on this kind
of fallback behavior. It might be so that in some cases the sender
is not able to re-send the command omitting the AVP because the command
with that AVP is the only kind of command the sender should send in that
particular situation. There might also be dependecies between AVPs that
need to be taken in account. These fallback scenarios should be specified
explicitly in each application case-by-case (AVP-by-AVP).

I think sending back the failed AVP is more useful for troubleshooting
purposes instead of version control.

It is better to define versions for the applications explicitly and
base the version control on that. One possibility to indicate the
version of application is the application-id, i.e. each new backward
incompatible version of the application would get new application-id.

BR,
Mikko

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Wiehe Ulrich
> Sent: 04 May, 2004 12:53
> To: Loughney John (Nokia-NRC/Helsinki); [email-masked]
> Subject: [AAA-WG]: AW: Application support in Diameter
> 
> 
> John,
>

---

From: "Wiehe Ulrich" <[email-masked]>
Date: Tue, 4 May 2004 14:41:55 +0200

Hi John,

The words "the message MUST be rejected" are perfectly clear. What behaviour
other than returning error 5001 do you think they could mean in the given
context? I think this is the main point of the existing mechanism: rely on
the fact that the unsupported AVPs with M bit set are rejected with error
5001.

Anyway, if 3GPP in their specifications for the Cx application mandate that a
node receiving unsupported M bit AVPs within Cx-commands MUST (or shall)
return them all with error 5001, would you still be concered? 

Ulrich

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 4. Mai 2004 13:00
An: Wiehe Ulrich; [email-masked]
Betreff: RE: [AAA-WG]: AW: Application support in Diameter

Hi Ulrich,

 
> more Failed-AVP AVP containing the AVPs that caused the failure.

This is optional behavior in the Diameter base specification, it is not
mandatory
behavior.  If you want to have this kind of behavior, it would probably be
best to make this as a requirement in your Diameter Application.

John

---

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

Ulrich,

> return them all with error 5001, would you still be concered? 

That would be part of the application definition, and my suggestion is that
the application could & should define this.

John

---

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

John,

Thank you very much for your help.

Best regards
Ulrich

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 4. Mai 2004 14:46
An: Wiehe Ulrich; [email-masked]
Betreff: RE: [AAA-WG]: AW: Application support in Diameter

Ulrich,

John

---

From: <[email-masked]>
Date: Tue, 4 May 2004 15:57:42 +0300

Hi Mikko,

> purposes instead of version control.

The points you raise are correct, and this is why negotiating AVP-by-AVP
is quite complicated.

> incompatible version of the application would get new application-id.

This is the intent of the Diameter Base spec, specifically CER/CEA exchange.
I am not sure why something more complicated is needed.

John

---

From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
Date: Tue, 4 May 2004 15:17:06 +0200

Hi John,

> This is the intent of the Diameter Base spec, specifically 
> CER/CEA exchange. I am not sure why something more 
> complicated is needed.

Because I think that the original purpose was to distinguish application
(1) from application (2) (e.g. NASREQ from MIPv4) that have few
overlapping in term of procedures, commands or AVPs. The problem is
quite different when you are considering versions of the same
application, with the same command and a common set of AVPs. And I'm not
sure that this point was clearly in mind.

Lionel