Subject: RE: [AAA-WG]: Vendor Command Code resolution

From: <[email-masked]>
Date: Thu, 27 Jun 2002 10:58:33 +0300

Hi Bernard,

> > Since, this will be just a pool of experimental command codes, which means that
> > the same experimental command code may be reused in several vendor specific
> > application, we need application IDs and the Vendor ID in the Diameter header
> > (as of today, i.e. let be as is) to guarantee avoiding conflict.
> 
> Yes.

Actually, if the experimental command code contains an application id, isn't that enough?
It might not be elegant, but it works.

John

---

From: Pete McCann <[email-masked]>
Date: Thu, 27 Jun 2002 10:02:28 -0500

Hi,

 > It might not be elegant, but it works.

Do you mean that the command would contain a Vendor-Specific
Application ID AVP?  I don't think you want to try encoding the
application ID within the command code, especially if we want to limit
the number of bits in the experimental space.

Also, I am having trouble reconciling this statement with your
suggested text:

 > In the event that the Command-Code field contains an experimental 
 > command, the four-octet Vendor-ID field contains the IANA assigned 
 > "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value. 
 > If the Command-Code field contains an IETF standard Command, the Vendor-ID 
 > field MUST be set to zero (0). Any vendor using an experimental Diameter 
 > command MUST use their own Vendor-ID.

This text seems to keep VSCs; the experimental space would differ from
VSCs in name only, or would only serve to limit the number of VSCs
that could be allocated by a single vendor by restricting VSCs to a
particular range of command codes.  Will that really satisfy the
IESG's concerns?

As an alternative, in line with what you might have been suggesting
earlier, why don't we just remove the Vendor-ID from the Diameter
header, and require any experimental command to include a
vendor-specific application ID AVP.  That way, to demultiplex the
command, you would need to look for the AVP, but processing for the
standard commands would be streamlined.  This would allow vendors to
create as many experimental applications as they have Application IDs,
and the experimental command code space could be re-used across
different (vendor, application) pairs.  This approach would be pretty
non-optimal in terms of processing required for vendor specific
commands, but might be much more likely to answer Randy's concerns.

Here is some proposed text for Section 3:

3  Diameter Header

   A summary of the Diameter header format is shown below. The fields
   are transmitted in network byte order.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Ver      |                 Message Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R P E r r r r r|                  Command-Code                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Hop-by-Hop Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      End-to-End Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
      This Version field MUST be set to 1 to indicate Diameter Version
      1.

   Message Length
      ...

   Command-Code
      The Command-Code field is three octets, and is used in order to
      communicate the command associated with the message. The 24-bit
      address space is managed by IANA (see section 11.2).

      Command-Code values in the range 0xffff00 through 0xffffff are
      reserved for experimental use.  Commands in this range MUST
      include a Vendor-Specific Application ID (see section 6.11)
      as the first AVP.  The Vendor-Specific Application ID, together
      with the Command-Code value, determines the meaning of the
      experimental command.

   Hop-by-Hop Identifier
      ...      

Also, change 6.11 to say:

  6.11  Vendor-Specific-Application-Id AVP

     The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
     Grouped and is used to advertise support of a vendor-specific
     Diameter Application. Exactly one of the Auth-Application-Id and
     Acct-Application-Id AVPs MAY be present.

     This AVP MUST also be present as the first AVP in all
     experimental commands defined in the vendor-specific application.

     AVP Format

        <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                          1* [ Vendor-Id ]
                                          0*1{ Auth-Application-Id }
                                          0*1{ Acct-Application-Id }

So this approach reserves 256 experimental codes, which should be more
than enough for any application.  They can be re-used across different
vendors and across different applications within a vendor, if
necessary.  They are off the fast-path for standard command
processing.  If the IESG wants to remove/deprecate the use of the
space later they can do so without changes to the base protocol,
although I am not sure about how this would affect the deployed base.

-Pete

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 28 Jun 2002 18:44:57 -0400

>  > It might not be elegant, but it works.

I think the same experimental command code is difficult to be reused in 
several vendor specific application, if a single Diameter node 
is trying to support those application with different Vendor-IDs.

This would affect the way of command dictionary lookup.  

How do you think what the dictionary lookup key should be for the
suggested change?  In the -11 draft, command dictionary is looked up
by using Command-Code and Vendor-ID (both appear in the Diameter
header) as the lookup key.  If lookup key is going to include
information contained in an AVP as well as Command-Code, that would
complicate message parser implementation (no good at all, please don't
do that!!).  On the other hand, if lookup key uses only Command-Code,
it would work only when different vendors use different code values in
experimental command code space....

Yoshihiro Ohba