Subject: [AAA-WG]: Request for Clarification of Diameter Capability Exchange

From: [email-masked]
Date: Fri, 14 Nov 2003 10:02:54 +0000

Hi,

We are looking at a scenario where two nodes, supplied by separate 
vendors, are communicated using a Diameter vendor-specific application 
defined by a third vendor.  We have been trying to understand exactly how 
the CER and CEA messages would work in this scenario and I would like to 
test our interpretation of RFC 3588.  We're assuming a separate Vendor-ID 
value for each of the three companies.

Our understanding is that the Vendor-ID, Product-Name and 
Firmware-Revision AVPs refer to the vendor of each box and their product. 
This contradicts the text in section 5.3.3 of RFC 3588 which states "The 
Vendor-ID AVP ... contains the ... value assigned to the vendor of the 
Diameter application", but appears consistent with the rest of 5.3.  As 
I've said, we're interpretting Vendor-ID as really being the vendor of the 
box, not the vendor of the Diameter vendor-specific application.  Is this 
correct?

If so, what this means is that these three AVPs would probably only be 
used for logging by the recipient of the message (request or answer 
command).  A box produced by vendor B shouldn't be expected to know that 
version x.z of vendor A's box supports Diameter ABC and version x.y 
doesn't.  Therefore the important AVPs, in this scenario, for capabilities 
exchange are Supported-Vendor-ID (set to the value for vendor C who 
defined the Diameter application) and Vendor-Specific-Application-ID.

So far so good, but we're imagining a scenario where the application will 
be phased in, so the functionality between different versions will be 
significantly different.  There appears to be no means in the capabilities 
exchange to negotiate the supported version of the Diameter application.

Therefore the only mechanism we can see is for the recipient of a message 
to reject the message if it: 
        a) gets a manadatory AVP that it doesn't understand
        b) fails to receive a mandatory AVP that it requires.

Which all means a successful capabilities exchange doesn't guarantee 
subsequent successful communication.

Have we understood this correctly?

It has also been suggested that the vendor-specific application ID could 
be changed between say v1.0 and v2.0 of the Diameter application.  Is this 
the way it is intended to work?

Regards,

John.

******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message 
(or responsible for delivery of the message to such person), 
you may not copy or deliver this message to anyone. In such 
case, you should destroy this message and kindly notify the 
sender and [email-masked] by reply email.  Please
note that in such circumstances any review, dissemination, 
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited 
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages 
of this kind.  The opinions, conclusions and other information 
in this message are of the author and shall be understood as 
neither given nor endorsed by Vodafone Ireland Limited 
unless it is otherwise indicated by an authorised representative 
independent of this message.  Internet e-mail is
transmitted over the public internet over which Vodafone 
Ireland Limited has no control.  As such, there is no guarantee that 
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender 
(iii) this e-mail has not been intercepted by a third party 
(iv) the contents of this e-mail are unaltered from the time of
transmission.  The presence of this footnote indicates that this 
message (including its attachments) has been processed by an 
automated anti-virus system; however it is the responsibility of 
the recipient to ensure that the message (and attachments) 
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), 
Pauline Best (UK), Paul Donovan Chief Executive (UK), 
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18. 
Number 326967 VAT Reg No. IE6346967G

******************************************************************************

---

From: <[email-masked]>
Date: Fri, 14 Nov 2003 14:27:16 +0200

Hi!

> It has also been suggested that the vendor-specific application ID could be
> changed between say v1.0 and v2.0 of the Diameter application.  Is this the way
> it is intended to work? 

Yes, in my opinion.

For example, if the "new version" of Diameter application defines
new command-codes and/or new AVPs with M-bit set, then it would
be handled by allocating a new Application-Id, as defined
in RFC3588, Sections 1.2.3 and 1.2.4.

Best Regards,
Mikko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext [email-masked]
Sent: 14 November, 2003 12:03
To: [email-masked]
Subject: [AAA-WG]: Request for Clarification of Diameter Capability Exchange 

Hi, 

We are looking at a scenario where two nodes, supplied by separate vendors, are communicated using a Diameter vendor-specific application defined by a third vendor.  We have been trying to understand exactly how the CER and CEA messages would work in this scenario and I would like to test our interpretation of RFC 3588.  We're assuming a separate Vendor-ID value for each of the three companies. 

Our understanding is that the Vendor-ID, Product-Name and Firmware-Revision AVPs refer to the vendor of each box and their product.  This contradicts the text in section 5.3.3 of RFC 3588 which states "The Vendor-ID AVP ... contains the ... value assigned to the vendor of the Diameter application", but appears consistent with the rest of 5.3.  As I've said, we're interpretting Vendor-ID as really being the vendor of the box, not the vendor of the Diameter vendor-specific application.  Is this correct? 

If so, what this means is that these three AVPs would probably only be used for logging by the recipient of the message (request or answer command).  A box produced by vendor B shouldn't be expected to know that version x.z of vendor A's box supports Diameter ABC and version x.y doesn't.  Therefore the important AVPs, in this scenario, for capabilities exchange are Supported-Vendor-ID (set to the value for vendor C who defined the Diameter application) and Vendor-Specific-Application-ID. 

So far so good, but we're imagining a scenario where the application will be phased in, so the functionality between different versions will be significantly different.  There appears to be no means in the capabilities exchange to negotiate the supported version of the Diameter application. 

Therefore the only mechanism we can see is for the recipient of a message  to reject the message if it: 
        a) gets a manadatory AVP that it doesn't understand 
        b) fails to receive a mandatory AVP that it requires. 

Which all means a successful capabilities exchange doesn't guarantee subsequent successful communication. 

It has also been suggested that the vendor-specific application ID could be changed between say v1.0 and v2.0 of the Diameter application.  Is this the way it is intended to work? 

Regards, 

John.