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

From: Johan Johansson <[email-masked]>
Date: Sun, 07 Apr 2002 15:34:35 +0000

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: Bernard Aboba <[email-masked]>
Date: Wed, 10 Apr 2002 07:32:36 -0700 (PDT)

Assigned Issue #327.