Subject: [Dime] Vendor-Specific-Application-Id AVP

From: Tina TSOU <[email-masked]>
Date: Thu, 22 Mar 2007 10:19:33 +0100

----- Original Message ----- 
  From: Tina TSOU 
  To: MORAND Lionel RD-CORE-ISS ; [email-masked] 
  Cc: Tom-PT Taylor ; [email-masked] 
  Sent: Thursday, March 22, 2007 9:45 AM
  Subject: Vendor-Specific-Application-Id AVP

  Hi Victor and Lionel,
  Issue 33: Why is there a need to Vendor-Specific-Application-Id AVP 
  •Details: If application id is flat and vendor app ids are in this same space, why is there a need to indicate the Vendor-Id ? The intent and usage of the AVP is never fully understood. 
  •Status: No activity

  Attached please find ITU-T Rs (Comparable to 3GPP Rx, Gq) which related to this issue.
  Does it work in a reasonable way?

  B. R.
  Tina

  8           Use of the Diameter base protocol
  With the clarifications listed in the following sub-clauses the Diameter Base Protocol defined by IETF RFC 3588 shall apply.

  8.1        Securing Diameter Messages
  For secure transport of Diameter messages, the method defined in ETSI TS 133 210 (3GPP TS 33.210) shall be used.

  8.2        Accounting functionality
  Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used on the Rs interface.

  8.3        Use of sessions
  As described in sub-clauses 6.1 and 6.2, operation for a given session may be stateful or stateless. Stateless operation is always indicated definitively by a value of NO_STATE_MAINTAINED in an Auth-Session-State AVP returned by the PD-PE in the AA-Answer response to the initial AA-Request. For stateful operation, the Session-Id AVP shall be present in all messages passing between the SCE and the PD-PE, as described in RFC 3588. The Session-Termination-Request (STR) and Session-Termination-Answer (STA) commands defined in RFC 3588 shall be used in order to terminate the Diameter user sessions. For stateless operation, the Class AVP returned in the AA-Answer response to the initial AA-Request shall be present in all messages passing between the SCE and the PD-PE. The Diameter user session shall be terminated by sending an AA-Request containing the Class AVP and the Resource-Reservation-Mode AVP with a value of RESOURCE_RELEASE (3).

  8.4        Transport protocol
  Diameter messages over the Rs interface shall make use of SCTP (RFC 2960) and shall utilize the new SCTP checksum method specified in RFC 3309.

  8.5        Routing considerations
  This sub-clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host for routing.

  The SCE obtains the contact address of the PD-PE for a given user through the means identified in sub-clause 7.3.1/Y.2111. Both the Destination-Realm and Destination-Host AVPs shall be present in the request. 

  To ensure that messages are routed to the correct application at the destination host, the Diameter message header of each message sent shall contain either the Rs application identifier (16777235) or the Gq application identifier (16777222) as agreed during CER/CEA negotiation. (See the next sub-clause.)

  8.6        Advertising Application Support
  The Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands are specified in the Diameter Base Protocol (RFC 3588). The Diameter base application identifier (0) shall be used in the Diameter message header of these messages.

  The SCE and the PD-PE shall advertise the support of the Rs and/or Gq applications by including an instance of the Vendor-Specific-Application-Id grouped AVP within the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands for each application supported, according to the following rules:

  (1)         The SCE shall advertise support of the Rs application if it supports stateless operation and of the Gq application if it supports stateful operation. It shall advertise both applications if it supports both operating modes.

  (2)         The PD-PE shall respond by indicating the subset of applications it is prepared to support, out of those offered by the SCE. If this subset is empty, the PD-PE's response shall be as described in section 5.3/RFC 3588.

  If both the SCE and the PD-PE indicate support of the Rs application, then the Rs application identifier (16777235) shall be used in the Diameter message header of all subsequent messages exchanged within this association. Otherwise the Gq application identifier (16777222) shall be placed in those headers.  

  Support of the Rs application within the CER/CEA is indicated by supplying an instance of the Vendor-Specific-Application-Id containing a Vendor-Id AVP set to ITU-T (11502) and an Auth-Application-Id AVP set to Rs (16777235). Support of the Gq application within the CER/CEA is indicated by supplying an instance of the Vendor-Specific-Application-Id containing a Vendor-Id AVP set to 3GPP (10415) and an Auth-Application-Id AVP set to Gq (16777222).

  NOTE – The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands at the command level (as opposed to the Vendor-Id instances within the Vendor-Specific-Application-Id AVPs as described in the previous paragraph) shall indicate the manufacturer of the Diameter node as per RFC 3588.

  The SCE and PD-PE shall advertise the support of AVPs specified in 3GPP, ETSI, and ITU-T documents by including the values 10415 (3GPP), 13019 (ETSI) and 11502 (ITU-T) in three different instances of the Supported-Vendor-Id AVP in the CER and CEA commands respectively.
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 22 Mar 2007 07:56:27 -0400

Hi Tina,

I'm assuming you meant 8.6, comments inline:

>     The Capabilities-Exchange-Request and Capabilities-Exchange-Answer
>     commands are specified in the Diameter Base Protocol (RFC 3588).
>     The Diameter base application identifier (0) shall be used in the
>     Diameter message header of these messages.
>
>     The SCE and the PD-PE shall advertise the support of the Rs and/or
>     Gq applications by including an instance of the
>     Vendor-Specific-Application-Id grouped AVP within the
>     Capabilities-Exchange-Request and Capabilities-Exchange-Answer
>     commands for each application supported, according to the
>     following rules:
>
>     (1)         The SCE shall advertise support of the Rs application
>     if it supports stateless operation and of the Gq application if it
>     supports stateful operation. It shall advertise both applications
>     if it supports both operating modes.
>
>     (2)         The PD-PE shall respond by indicating the subset of
>     applications it is prepared to support, out of those offered by
>     the SCE. If this subset is empty, the PD-PE's response shall be as
>     described in section 5.3/RFC 3588.
>
>     If both the SCE and the PD-PE indicate support of the Rs
>     application, then the Rs application identifier (16777235) shall
>     be used in the Diameter message header of all subsequent messages
>     exchanged within this association. Otherwise the Gq application
>     identifier (16777222) shall be placed in those headers.
>

Ok. Are you planning to populate any other  app-id avps as well ?

>     Support of the Rs application within the CER/CEA is indicated by
>     supplying an instance of the Vendor-Specific-Application-Id
>     containing a Vendor-Id AVP set to ITU-T (11502) and an
>     Auth-Application-Id AVP set to Rs (16777235). Support of the Gq
>     application within the CER/CEA is indicated by supplying an
>     instance of the Vendor-Specific-Application-Id containing a
>     Vendor-Id AVP set to 3GPP (10415) and an Auth-Application-Id AVP
>     set to Gq (16777222).
>
>     NOTE/ /– The Vendor-Id AVP included in
>     Capabilities-Exchange-Request and Capabilities-Exchange-Answer
>     commands at the command level (as opposed to the Vendor-Id
>     instances within the Vendor-Specific-Application-Id AVPs as
>     described in the previous paragraph) shall indicate the
>     manufacturer of the Diameter node as per RFC 3588.
>
>     The SCE and PD-PE shall advertise the support of AVPs specified in
>     3GPP, ETSI, and ITU-T documents by including the values 10415
>     (3GPP), 13019 (ETSI) and 11502 (ITU-T) in three different
>     instances of the Supported-Vendor-Id AVP in the CER and CEA
>     commands respectively.
>

This seems ok to me. In relation to issue #33, the vendor-id would be 
more interesting to the Rs/Gq application rather than anything else to 
do with diameter processing so using it in CER/CEA is ok. As I 
mentioned, this means that the vendor-id will not be relevant in any 
diameter base protocol decision making, i.e. routing.

regards,
victor