Subject: RE: [diameter] Capabilities Negotiation and proxies

From: [email-masked]
Date: Thu, 11 Jan 2001 03:54:44 +0200

why the value of Extension_ID can not use a bit of that Unsigned32.
for example :
       NASREQ              1 
       Strong Security     2 
       Resource Management 4 
       Mobile-IP           8 
       Accounting         16  

dongfeng.jing

> -----Original Message-----
> From: ext Pat Calhoun [mailto:[email-masked]]
> Sent: 11. January 2001 8:56
> To: [email-masked]; [email-masked]
> Subject: [diameter] Capabilities Negotiation and proxies
> 
> 
> All,
> 
> As discussed a few days ago, a proxy MAY wish to proxy ANY 
> type of message,
> regardless of the extension. Therefore, the current text in 
> the base protocol
> does not allow this behavior since it would require that 
> proxies advertise ALL
> possible extensions.
> 
> Therefore, I am proposing adding the last paragraph to section 2.5.3.
> Furthermore, I believe that ALL messages MUST include the 
> extension ID of the
> particular message. The reason being that a proxy would need 
> to identify a
> server in the home domain that can handle the message, but it 
> may not recognize
> the command.
> 
> Comments? Objections? Proposed Text?
> 
> PatC
> 
> 2.5.3  Extension-Id AVP
> 
>    The Extension-Id AVP (AVP Code 258) is of type Unsigned32 
> and is used
>    in order to identify a specific DIAMETER extension. This 
> AVP is used
>    in the Device-Reboot-Ind message in order to inform the peer what
>    extensions are locally supported. The Extension-Id MUST 
> also be present
>    in all messages that are defined in a separate DIAMETER 
> specification
>    and have an Extension ID assigned.
> 
>    Each DIAMETER extension draft MUST have an IANA assigned extension
>    Idenfier (see section 8.3). The base protocol does not require an
>    Extension-Id since its support is mandatory.
> 
>    There MAY be more than one Extension-Id AVP within a DIAMETER
>    Device-Reboot-Ind message. The following values are recognized:
> 
>       NASREQ              1 [7]
>       Strong Security     2 [11]
>       Resource Management 3 [29]
>       Mobile-IP           4 [10]
>       Accounting          5 [15]
> 
>       Furthermore, servers acting as Redirect or Proxy servers (see
>       Section 6.0) MAY wish to advertise support for ALL possible
>       extensions. Such servers are then responsible for finding a
>       downstream server that supports the extension of a particular
>       message. This is done by including the Extension-Id AVP with a
>       value of zero (0).
>