Subject: RE: [AAA-WG]: Issue #327: Message routing and vendor specific applications

From: <[email-masked]>
Date: Tue, 16 Apr 2002 10:11:37 +0300

Hi Johan,

> Actually on second thought we should probably even change it to
> 
> ----------
> 
> - Application Identifier. An application is identified by a vendor id 
> and an application id. If the application is one defined by 
> the Diameter 
> workgroup the vendor id is 0. A route entry can have a different
> destination based on the application identification avp of 
> the message. 
> This is one of Acct-Application-Id (for accounting
> messages), Auth-Application-Id (for non-accounting messages) or 
> Vendor-Specific-Application-Id (for vendor specific messages). This 
> field MUST be used as a secondary key field
> in routing table lookups.

I think this is OK.

John

---

From: <[email-masked]>
Date: Tue, 16 Apr 2002 10:19:48 +0300

Hi Johan,

> For 6.1 and 6.1.6 only Mark has stated an opinion, but based on gut 
> feeling and Mark's emails I am suggesting that the optimized way of 
> using simply the Axxx-Application-Ids for non-vendor applications is 
> retained. Thus the relevant part of 6.1 that was
> 
>    The Destination-Realm AVP MUST be present if the message is
>    proxiable.  Proxiable request messages MUST also contain either an
>    Acct-Application-Id AVP or an Auth-Application-Id AVP. 
> 
> becomes
> 
> ----------
> 
> The Destination-Realm AVP MUST be present if the message is
> proxiable. Proxiable request messages MUST also contain an
> Acct-Application-Id AVP, an Auth-Application-Id AVP or a 
> Vendor-Specific-Application-Id AVP.

I think this change is OK.

> while 6.1.6 (relevant part) was
> 
>    Diameter request message routing is done via realms. A Diameter
>    message that is able to be proxied MUST include the target realm in
>    the Destination-Realm AVP. The realm MAY be retrieved from 
> the User-
>    Name AVP, which is in the form of a Network Access 
> Identifier (NAI).
>    The realm portion of the NAI is inserted in the Destination-Realm
>    AVP.
> 
>    Diameter agents MAY have a list of locally supported 
> realms, and MAY
>    have a list of externally supported realms. When a request is
>    received that includes a realm that is not locally supported, the
>    message is routed to the peer configured in the Realm Routing Table
>    table (see section 2.8).
> 
> I suggest changing it to, although it is a bit redundant with 
> regard to 6.1:
> 
> ----------
> 
> Diameter request message routing is done via realms and 
> applications. A 
> Diameter
> message that is able to be proxied MUST include the target realm in
> the Destination-Realm AVP and one of the application 
> identification AVPs 
> Auth-Application-Id, Acct-Application-Id or 
> Vendor-Specific-Application-Id. The realm MAY be retrieved 
> from the User-
> Name AVP, which is in the form of a Network Access Identifier (NAI).
> The realm portion of the NAI is inserted in the Destination-Realm
> AVP.
> 
> Diameter agents MAY have a list of locally supported realms and 
> applications, and MAY
> have a list of externally supported realms and applications. When a 
> request is
> received that includes a realm and/or application that is not locally 
> supported, the
> message is routed to the peer configured in the Realm Routing Table
> table (see section 2.7).

I think this is OK as well, the redundancy is not a problem, in my mind.

I think this should close out this issue?

John