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

From: <[email-masked]>
Date: Mon, 15 Apr 2002 12:58:19 +0300

Hi Mark & Johan,

What text would you like modified, there seems to be many places
that could be modified.

I have already taken your editorial suggest, however.

John

> -----Original Message-----
> From: ext Mark Jones [mailto:[email-masked]]
> Sent: 10 April, 2002 20:29
> To: aaa-wg
> Subject: RE: [AAA-WG]: Message routing and vendor specific 
> applications
> 
> 
> Hi Johan,
> 
> I agree that message routing as described in the latest draft 
> does not take
> into account vendor-specific applications.
> 
> If I've correctly understood the requested change, the 
> Vendor-Id field would
> be added to the Realm Routing Table Entry and if the 
> Application-Id field
> contains the identifier of a IETF standard application, the 
> Vendor-ID field
> MUST be set to zero (0).
> 
> I also agree with the change suggested in your editorial side-issue.
> 
> Regards,
>        Mark
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Johan Johansson
> > Sent: April 10, 2002 1:29 PM
> > To: Johan Johansson
> > Cc: [email-masked]; aaa-wg
> > Subject: Re: [AAA-WG]: Message routing and vendor specific 
> applications
> >
> >
> > Please, someone comment on this one. I am reluctant to make a change
> > that nobody has reviewed.
> >
> > j
> >
> > Johan Johansson wrote:
> >
> > > Sure. I just want to get the issue reviewed first to make 
> sure I am
> > > not seeing a problem where there is none and then I'd 
> want to see some
> > > reaction to the solution alternatives I have suggested.
> > >
> > > j
> > >
> > > [email-masked] wrote:
> > >
> > >> Johan,
> > >>
> > >> Do you want to supply the text?
> > >>
> > >>
> > >> John
> > >>
> > >>> -----Original Message-----
> > >>> From: ext Johan Johansson [mailto:[email-masked]]
> > >>> Sent: 07 April, 2002 18:35
> > >>> To: aaa-wg
> > >>> Subject: [AAA-WG]: Message routing and vendor specific 
> applications
> > >>>
> > >>>
> > >>> Issue:                   Message routing and vendor specific
> > >>> applications
> > >>> Submitter name:          Johan Johansson
> > >>> Submitter email address: [email-masked]
> > >>> Date first submitted:    04-07-2002 Reference:
> > >>> Document:                Base Comment type:            Technical
> > >>> Priority:          S Section:                 2.7, 6.1, 
> 6.1.6, 6.10,
> > >>> 9.7.1
> > >>>
> > >>> Rationale/Explanation of issue:
> > >>>
> > >>> We allow vendor specific applications with their own 
> "namespaces"
> > >>> but we do not perform routing on them. Section 6.1.6 
> simply states:
> > >>>
> > >>> 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).
> > >>>
> > >>> On a side note this should probably be section 2.7, but the
> > >>> important part is that nowhere in these paragraphs is
> > >>> per-application routing mentioned, let alone 
> vendor-specific such.
> > >>>
> > >>> The preceding section 6.1 states
> > >>>
> > >>> 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.
> > >>>
> > >>> while 9.7.1 happily claims
> > >>>
> > >>>   One of Acct-Application-Id and 
> Vendor-Specific-Application-Id AVPs
> > >>>   MUST be present. If the Vendor-Specific-Application-Id
> > grouped AVP is
> > >>>   present, it must have an Acct-Application-Id inside.
> > >>>
> > >>> Pretty contradictory if you ask me.
> > >>>
> > >>> Finally, the section 2.7 describing the realm based 
> routing table says
> > >>>
> > >>>
> > >>>      - Application Identifier. A route entry can have a 
> different
> > >>>        destination based on the Acct-Application-Id for 
> accounting
> > >>>        messages) or Auth-Application-Id (for 
> non-accounting messages)
> > >>>        of the message. This field MUST be used as a secondary
> > key field
> > >>>        in routing table lookups.
> > >>>
> > >>> It seems to me that it would need to use vendor id 
> *and* application
> > >>> id to perform a proper lookup.
> > >>>
> > >>> Requested change:
> > >>>
> > >>> The solution is conceptually simple: make the routing 
> table store
> > >>> vendor id and application id and add text to 6.1.6 to take these
> > >>> into account when routing requests.
> > >>>
> > >>> We now have two ways to identify the application of a request.
> > >>> Either it has a "naked" Acct/Auth-Application-Id *or* it has a
> > >>> grouped Vendor-Specific-Application-Id AVP where the 
> Vendor-Id is
> > >>> non-zero. Granted, the Diameter standard vendor is an important
> > >>> special case but is it important enough to require a 
> two-stage lookup?
> > >>>
> > >>> What do you think?
> > >>>
> > >>> I'll sneak in an editorial side-issue. Shouldn't we change
> > >>>
> > >>>
> > >>> 6.10  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. Either the Auth-Application-Id 
> or the Acct-
> > >>>   Application-Id AVP MAY be present. Exactly one of the Auth-
> > >>>   Application-Id and Acct-Application-Id AVPs MAY be present.
> > >>>
> > >>> to
> > >>>
> > >>> 6.10  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 MUST be present.
> > >>>
> > >>> j
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> >
> >
> >
> >
> 
>

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 15 Apr 2002 15:22:25 -0400

> What text would you like modified, there seems to be many places

Assuming we're still going to refer to this as 'Realm-based' routing, I
think that there are two sections that need to be modified:

Section 2.7: Add the vendor-id to the realm based routing table. Are there
any objections to re-using the existing application id field in the
Realm-based Routing Table to store a vendor-specific application id?

Section 6.1: Change "Proxiable request messages MUST also contain either an
Acct-Application-Id AVP or an Auth-Application-Id AVP." to "Proxiable
request messages MUST also contain either an Acct-Application-Id AVP, an
Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP."

Regards,
       Mark

---

From: Johan Johansson <[email-masked]>
Date: Mon, 15 Apr 2002 21:51:33 +0200

>Realm-based Routing Table to store a vendor-specific application id?
The main objection is that vendor applications may have the same id as 
standard application since they do not share the same "numberspace", 
i.e. the vendor/app pair (0, 4) would identify the mobile ip application 
while (5902, 4) would identify vendor 5902's application 4..

>Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP."
Seems reasonable. I am working on a more complete suggestion that I will 
fire off within the next few hours.

j

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 15 Apr 2002 17:11:39 -0400

> while (5902, 4) would identify vendor 5902's application 4..

Agreed but the realm table entry is unambiguous if it contains both the
vendor-id (zero for IETF apps) and an application id. Both these fields must
be used together with the realm in selecting the destination host.

Anyway, rather than trying to second-guess, I'll wait for your proposed text
for section 2.7 :)

Regards,
       Mark

---

From: Johan Johansson <[email-masked]>
Date: Tue, 16 Apr 2002 00:48:41 +0200

>be used together with the realm in selecting the destination host.
That's exactly what I was after.

>Anyway, rather than trying to second-guess, I'll wait for your proposed text
And here, eventually, it is. Please improve phrasing and point out 
misconceptions. Also, I'm sure the those with more practice in rfc-ese 
will want to change the capitilization of some words.

2.7 - minimally change:

      - Application Identifier. A route entry can have a different
        destination based on the Acct-Application-Id for accounting
        messages) or Auth-Application-Id (for non-accounting messages)
        of the message. This field MUST be used as a secondary key field
        in routing table lookups.

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 Acct-Application-Id (for accounting
messages) or Auth-Application-Id (for non-accounting messages)
of the message. This field MUST be used as a secondary key field
in routing table lookups.

-----------

(bonus question: does this mean that accounting routes and authorization 
routes for the same application can not differ?)

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.

----------

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 9.7.1 is ok as is with the change to 6.1.

j

---

From: Johan Johansson <[email-masked]>
Date: Tue, 16 Apr 2002 00:53:53 +0200

Johan Johansson wrote:

> 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

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.

-----------

j