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

From: <[email-masked]>
Date: Fri, 28 Jun 2002 13:17:04 +0300

Hi Pete,

> 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.

Actually, this is what I was getting at,  I think your text is good, so I will
make the updated changes.

Thanks,
John
 
> 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: Bernard Aboba <[email-masked]>
Date: Fri, 28 Jun 2002 05:32:52 -0700 (PDT)

> > commands, but might be much more likely to answer Randy's concerns.

Question: do changes need to be made to routing in order for this to
work?