Subject: [AAA-WG]: Proposed text for Issue 75

From: Pat Calhoun <[email-masked]>
Date: Thu, 12 Jul 2001 10:47:59 -0700

All,

Before I go on I want to mention that we have two alternatives.
The first, is to rely solely on configuration to allow server-initited
messages to be routed to NASes. In today's networks, such configuration
doesn't exist. If we decide to take this option, we will have to include
a disclaimer in the draft stating that if reverse routing isn't setup,
server-initiated messages will not work, and any application relying on
these would perhaps fail.

The second option is to include the text below, which allows a server
to retain the list of hops taken for a message, and use the list of
hops are source routes for reverse messages.

If folks feel that making this explicitely supported in the protocol
is needed, then the text below would capture the above ideas.

I would welcome the following:
1. Do you think the text is needed, or simply configuration
2. Is the text below sufficient?

Thanks,

PatC
----
5.3.X  Alternate-Peer AVP

   The Alternate-Peer AVP (AVP Code TBD) is of type diameterIdentity,
   and contains the URI of an alternate peer that MAY be used in server-
   initiated requests, when routing using the Source-Route AVP.

[...]

6.1.X  Relaying and Proxying Server-Initiated Requests

   Server-initiated messages MUST include the Source-Route AVPs, whose
   contents are identical to the Record-Route AVPs received in requests
   from the access device for the given session, but in the reverse
   order. Agents receiving requests with one or more Source-Route AVP
   MUST use the last Source-Route AVP in the request to determine the
   request's next hop.

   In the event that the next hop encoded in the Source-Route is not
   reachable, an alternate peer MAY be used if the peer in question had
   advertised such peers via the Alternate-Peer AVP in the CER or CEA
   message.

[...]

6.8.X  Source-Route AVP

   The Source-Route AVP (AVP Code TBD) is of type DiameterIdentity.
   This AVP is used for routing decisions by agents for server-initiated
   messages. The order of the Source-Route AVPs MUST be the inverse of
   the Route-Record AVPs of auth messages received by the server for the
   session in question.