Subject: Re: [diameter] Re: [AAA-WG]: Host-Name and Destination-NAI AVPs

From: David Frascone <[email-masked]>
Date: Mon, 12 Feb 2001 08:13:45 -0600

But, there is already a difference in the real world, and it's not that
confusing.  If you try to connect to http://user@domain, it won't work.  If
you try to send e-mail to www.somedomain.org, it won't work.

I think all he wants to do is clean it up, and use Fully Qualified Domain
Names where a host-name would be appropriate, and use NAI's where user-names
would be more appropriate.

It seemed like a simple change that would clear up ambiguity, not add it.

--Dave

On Mon, Feb 12, 2001 at 04:28:45AM +0200, [email-masked] wrote:
> I only think User_Name and Host_Name and Desatination _NAI should be 
> have same format, otherwise it will be confused and complex. I also think
> that three should have different definitely impact on message in different
> circumstance,
> So if you want change one, it wont have great impact on others .
> 
> Dongfeng Jing
> R&D Engineer, Advanced Internet Technologies, Nokia China R&D Center
> NOKIA (CHINA) INVESTMENT CO.,LTD.
> Nokia House 1, No.11, He Ping Li Dong Jie, Beijing, 100013 PRC
> Phone:  +86 10 8422 9922 ext. 2875, MP: +86 13910822740, 
> fax:       +86 10 8422 2439
> e-mail: [email-masked]
> 
> > -----Original Message-----
> > From: ext David Spence [mailto:[email-masked]]
> > Sent: 11. February 2001 5:12
> > To: Patrice Calhoun
> > Cc: [email-masked]; [email-masked]
> > Subject: [diameter] Re: [AAA-WG]: Host-Name and Destination-NAI AVPs
> > 
> > 
> > Patrice Calhoun wrote:
> > > 
> > > All,
> > > 
> > > I would like to see if anyone agrees with me that the Host-Name and
> > > Destination-NAI AVPs should contain FQDN, instead of NAIs. 
> > Originally, I
> > > believe that they contained NAIs for the purposes of 
> > routing, but the
> > > User-Name is an NAI, and in its absence the Routing-Realm 
> > can be used. So, I
> > > really do not see a reason for making the Destination-NAI 
> > and Host-Name AVP be
> > > an NAI. FQDNs can be used to resolve the name to an IP 
> > address, which is much
> > > more useful.
> > > 
> > > Comments?
> > > 
> > > PatC
> > 
> > Whoa, slow down a minute.  This sounds to me like a major 
> > change, and since
> > you didn't explain how it would work, I don't see how I can 
> > either agree or
> > disagree with it.
> > 
> > O.k.  Let me excercise my brain a bit and see if I can 
> > imagine what you
> > might have in mind and what the implications might be.
> > 
> > My first set of assumptions concerns how the protocol is 
> > intended to work as
> > specified in Alpha2.  Not all of this is actually stated in 
> > Alpha2, but
> > probably should be.
> > 
> > I assume that if the Destination-NAI AVP contains an NAI then 
> > it has the
> > format server@realm where "server" identifies the last hop server and
> > "realm" identifies the last hop realm.  Such an AVP, if it 
> > appeared in a
> > message of type Request or Query could be used to route the 
> > message to its
> > final destination.
> > 
> > Note:  The terms route or routing as used in this memo refer 
> > to the process
> > of message forwarding through a chain of proxies at the application
> > (Diameter) layer -- not to the activity of routing packets at 
> > the network
> > (IP) layer.
> > 
> > Similarly, I assume that if the Host-Name AVP contains an NAI 
> > then it has
> > the format client@realm where "client" identifies the 
> > Diameter client (e.g.,
> > NAS) within the service provider's realm and "realm" 
> > identifies the last hop
> > realm to which a message of type Indication containing the 
> > AVP should be
> > routed.
> > 
> > I assume that messages of type Response or Answer are routed using
> > information in either the Route-Record AVPs or the 
> > Proxy-State AVP, but that
> > messages from server to client of type Indication will 1) not contain
> > Route-Record AVPs, 2) may be routed by the information 
> > contained in the
> > Proxy-State AVP (if present), but 3) must contain a Host-Name 
> > AVP that can
> > be used for routing.
> > 
> > Now let me state my assumptions concerning your proposal above.
> > 
> > The Destination-NAI and Host-Name AVPs will contain the fully 
> > qualified
> > domain name (host name) of the source or destination (depending on the
> > message type) client or server in the proxy chain.  It may 
> > contain dots but
> > no @ signs.  I assume you will probably rename the 
> > Destination-NAI AVP to
> > something like Destination AVP, so I will use the term 
> > Destination AVP in
> > what follows to avoid confusion.
> > 
> > In the case of the Destination AVP, the FQDN will be the host 
> > name of the
> > host on which the Diameter server is running.  Now of course 
> > this host name
> > may be totally different than and might not contain any part of the
> > destination realm name.  In fact, it might not contain the 
> > name of any realm
> > used by any network.  So if a Diameter proxy has a realm 
> > routing table which
> > it uses to route Request messages containing a User-Name AVP, 
> > for example,
> > such a routing table can not be used to route on Destination 
> > AVP.  In fact,
> > I assume that the Destination and Host AVPs will be 
> > relatively useless for
> > routing purposes except perhaps for the last hop routing decision.
> > 
> > So my question is, how is routing supposed to work if you 
> > implement your
> > above proposal?
> > 
> > One possibility is that you could create an AVP of type 
> > Grouped that would
> > contain two AVPs: one indicating the realm and the other the 
> > FQDN.  The
> > realm would be used for routing at all but the last hop, and 
> > the FQDN would
> > be used for the last hop routing decision.
> > 
> > I don't believe that some of the messages that currently 
> > contain Host-Name
> > or Destination-NAI AVPs currently contain any other AVP 
> > encoding the realm
> > to which the message should be routed.  For example the STI 
> > message contains
> > no other AVP except the Host-Name AVP that could be used for routing.
> > 
> > I think routing on the FQDNs themselves (except at the last 
> > hop) is a bad
> > idea for the following reasons:
> > 
> > 1) Creating a route table for FQDNs I think would be very 
> > difficult.  What
> > part of the FQDN do I route on?  With an NAI, I route on the 
> > part after the
> > @ sign except at the last hop.
> > 
> > 2) Creating a route table for FQDNs is unapealing because 
> > proxies would then
> > need two route tables: one for realms and one for FQDNs.
> > 
> > 3) Many different realms may be served by the same Diameter 
> > server.  I am
> > not absolutely sure that the routing to the server should 
> > always be the same
> > for all of the realms served by the server.  I can imagine 
> > that different
> > proxies and brokers might be involved in the chain even 
> > though the endpoint
> > is the same.  Even if this does not need to be the case, it 
> > may be anyway
> > because it will be difficult to enforce consistency between the realm
> > routing table and the FQDN routing table.  If the proxies and 
> > brokers keep
> > state information, inconsistent routing for messages relating 
> > to the same
> > session would be problematic.  For example, the Access-Response and
> > Session-Termination-Indication messages for a given session 
> > should follow
> > the same route.  Therefore they should use the same routing table.
> > 
> > Another possibility is that you could use something like the 
> > Record-Route
> > system for routing on FQDNs.  Then there is no need for an 
> > FQDN routing
> > table, and all messages of a session take the same route.  
> > But sessions may
> > be long-lived, so this idea creates backup-recovery problems.
> > 
> > In conclusion, if I've recreated your line of thinking 
> > properly, then I
> > really don't like the above proposal and would prefer to keep 
> > using NAIs. 
> > But, of course, I may have misunderstood entirely.
> > 
> > -- 
> > David Spence                            email: 
> > [email-masked]
> > Interlink Networks, Inc.                phone: (734) 821-1203
> > 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> > Ann Arbor, MI 48108           
> > U.S.A.
> >

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 11:10:59 -0500

David,

I'm not sure if you fully see what my issue is.  My issue is how do proxies
"route" Diameter messages?  If you route on User-Name, then you have a realm
routing table that routes on names selected from the realm name-space.  If
you had to route on a Destination AVP and that AVP contains an FQDN, then
you would be routing on a name selected from the DNS which is a different
name space.  My point is that routing (except perhaps at the last hop)
should always be on the basis of names selected from the same name space.

Unfortunately, I don't know what Pat had in mind for routing because he
didn't say.  It occurs to me that in the client-to-server direction he may
have assumed that the User-Name would always be present and that the
Destination AVP would only be used at the last hop.  That would solve my
problem stated in the previous paragraph but raise others (which I won't go
into in this message).

However, I don't think that the routing for the server-to-client direction
has been very well thought out. Responses and Answers use  a different form
of routing than Indications.  Furthermore, Responses and Answers have an
analogue in RADIUS and so are better understood.  Indication messages have
no analogue in RADIUS.  These are messages sent in the server-to-client
direction long after a session has been established.  They are
server-initiated -- not in response to any message from the client.  In the
possibly very long interval since the session was established, session state
may or may not have been lost by intervening servers.  If session state
survives, it needs to be kept up-to-date by routing through the same servers
involved in session establishment.  If state has been lost or the original
servers are no longer up, then the Indication messages need to be routed
some way.  In the absence of state to assist in the routing, Indication
messages need to contain an AVP that proxies can "route" on.  Once again, I
think this AVP should contain an identifier selected from the same name
space as the names that proxies generally route on, which would be the realm
name space.

These are complicated issues.  I hope this helps.

Dave S.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 08:18:15 -0800 (PST)

> should always be on the basis of names selected from the same name space.

This is *exactly* what I have in mind. NAIs are used thoughout the proxy
chain, until the last hop where FQDN is used. Again, an FQDN is not used
against the routing table, but agains the clients file.

PatC

---

From: Barney Wolff <[email-masked]>
Date: Mon, 12 Feb 2001 11:58:44 -0500

And suppose my proxy behaves like the 800-lb gorilla?  Since you
can't enforce any particular routing algorithm on a proxy, and
can't even do a good job of detecting "violations" from upstream,
why try to specify it?

I still don't get it - 80% of the reason for going through a
proxy is that you don't know where the right server is, and
really don't want to know.  So why all this fuss on having
things closer to the NAS try to tell the proxies what to do?
I'm having that Through-the-Looking-Glass feeling here.

Barney Wolff

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 09:05:15 -0800 (PST)

> can't even do a good job of detecting "violations" from upstream,

I think that one of the fundamental problems with RADIUS is it's lack of
specification in proxying. I believe that it doesn't hurt to "suggest" how a
proxy can route packets, and let the more experienced developers come up with
better scheme. This way we can assume that all Diameter implementations will
at least do what the protocol was intended to do.

PatC

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 12:55:31 -0500

> against the routing table, but agains the clients file.

Great!

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 13:28:39 -0500

> at least do what the protocol was intended to do.

My concern is that the protocol carry the information required to make
fairly complex proxying possible for a variety of different kinds of proxies
-- stateful and stateless, routing and broker, etc.  I certainly don't mean
to limit how it can be done.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 11:03:33 -0800 (PST)

Here is my first try at some proposed text to handle what we've been
discussing so far (pardon the section numbers). I would appreciate some
comments on the text.

PatC
----

[...]

y.z  Message Forwarding

   When a Diameter entity receives a Diameter message of type Request,
   Query or Indication that includes a Destination AVP, and the host
   specified in the AVP can be contacted directly, the message MUST be
   forwarded to the host in question.

   The Destination AVP is used when the destination of the message is
   fixed, such as:

      - Authentication requests that span multiple round trips
      - A Diameter message that uses a security mechanism that makes use
        of a pre-established session key shared between the source and
        the final destination of the message.
      - Server initiated messages that MUST be received by a specific
        Diameter client (e.g. NAS), such as the Session-Termination-Ind
        message, which is used to request that a particular user's
        session be terminated.

   Proxies receiving messages that contain the Destination AVP MUST
   verify whether they are able to forward Diameter messages to the host
   specified in the AVP, and if so, MUST forward the message to the host

Calhoun et al.             expires July 2001                   [Page 37]

Internet-Draft                                             February 2001

   in question. Otherwise, the message routing procedures described in
   section 8.0 MUST be followed.

y.z.1  Destination AVP

   The Destination AVP (AVP Code 293) [1] is of type OctetString, and
   contains the Fully Qualified Domain Name (FQDN) of the intended
   recipient of the message. This AVP MUST be present in all unsolicited
   server initiated messages.

8.0  Message Routing

   This section describes the expected behavior of a Diameter server
   acting as a proxy or redirect server.

8.1  Realm-Based Message Routing

   Diameter request, query and indication message routing is done
   through the use of the realm portion of the Network Access Identifier
   (NAI), and an associated realm routing table (see section 8.1.1). The
   NAI has a format of user@realm, and Diameter servers have a list of
   locally supported realms, and MAY have a list of externally supported
   realms. When a request, query or indication message is received that
   includes a realm that is not locally supported, the message is
   proxied to the Diameter entity configured in the "route" table.

   Figure 2 depicts an example where DIA1 receives a request to
   authenticate user "[email-masked]". DIA1 looks up "abc.com" in its local
   realm route table and determines that the message must be proxied to
   DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3
   checks its realm route table, and determines that the realm is
   locally supported, and processes the authentication request, and
   returns the response. How the response actually makes it back to the
   sender of the original request is described in the next section.

Calhoun et al.             expires July 2001                   [Page 38]

Internet-Draft                                             February 2001

                   (Request)                  (Request)
            (User-Name=[email-masked])    (User-Name=[email-masked])
      +------+      ------>      +------+      ------>      +------+
      |      |                   |      |                   |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+      <------      +------+      <------      +------+
                   (Response)                 (Response)
            (User-Name=[email-masked])    (User-Name=[email-masked])

      mno.net                    xyz.com                    abc.com
                       Figure 2: Realm-Based Routing

   Note the processing rules contained in this section are intended to
   be used as general guidelines to Diameter developers. Certain
   implementations MAY use different methods than the ones described
   here, and still be in compliance with the protocol specification.

8.1.1  Realm-Based Routing Table

   All Realm-Based routing lookups are performed against what is
   commonly known as the Domain Routing Table (see section 13.0). A
   Domain Routing Table Entry contains the following fields:
      - Domain Name. The Domain Name is analogous to the realm portion
        of the NAI.  This is the field that is typically used as a
        primary key in the routing table lookups. Note that some
        implementations perform their lookups based on longest-match-
        from-the-right on the realm rather than requiring an exact
        match.
      - Extension Id. It is possible for a routing entry to have a
        different destination based on the extension identifier of the
        message. This field is typically used as a secondary key field
        in routing table lookups.
      - Local Action. The Local Action field is used to identify how a
        message should be treated. The following actions are supported:
           1. LOCAL - Diameter messages that resolve to a routing entry
              with the Local Action set to Local can be satisfied
              locally, and do not need to be forwarded to another
              server.
           2. PROXY - All Diameter messages that fall within this
              category MUST be forwarded to a next hop server. The local
              server MAY apply its local policies to the message by
              including new AVPs to the message prior to forwarding.
              See section 8.4 for more information.
           3. REDIRECT - Diameter messages that fall within this
              category MUST have the identity of the home Diameter
              server(s) appended, and returned to the sender of the

Calhoun et al.             expires July 2001                   [Page 39]

Internet-Draft                                             February 2001

              message. See section 8.3 for more information.
      - Server Identifier - One or more servers the message is to be
        forwarded to.  When the Local Action is set to PROXY, this field
        contains the identities of the server(s) the message must be
        forwarded to. When the Local Action field is set to REDIRECT,
        this field contains the Home Diameter server(s) for the realm.

   It is important to note that Diameter servers MUST support at least
   one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do
   not need to support all modes of operation in order to conform with
   the protocol specification.  Servers MUST NOT reorder AVPs with the
   same AVP Code.

8.2  Proxy and Redirect Server handling of requests

   When a message of type request, query or indication is received by a
   proxy or redirect server, and it is determined that the request
   cannot be locally handled, the next hop for the request is determined
   in the following order:
      1. If the Destination AVP is present, and the host specified in
         the AVP can be directly contacted, the message is forwarded to
         the host (see section y.z for more information)
      2. If the Routing-Realm AVP is present, a routing table lookup is
         performed using the domain specific in the AVP, or
      3. A routing table lookup is performed using the domain portion of
         the NAI found in the User-name AVP.

   A message that does not contain any of the above AVPs MUST NOT be
   routed.  If the message in question cannot be handled locally, a
   Message-Reject-Ind is sent with the Result-Code AVP set to an
   appropriate error condition.

[...]

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 14:52:57 -0500

O.k.  Here are a few comments.  See below.

>    section 8.0 MUST be followed.

Suppose a Diameter client is sending the second message in an authentication
sequence that spans multiple round trips.  How does it know what information
to include in the Destination AVP?  In other words, how does it find out the
FQDN of the home server engaged in the sequence?

>    acting as a proxy or redirect server.

I thought we decided to get rid of redirect servers.

>    through the use of the realm portion of the Network Access Identifier

and in addition, for load balancing purposes, a routing tie may be broken by
hashing the user portion of the NAI...

>    proxied to the Diameter entity configured in the "route" table.

It might be less confusing of the material in sec. 8.2 appeared here so we
aren't confused as to where the NAI came from.

>             (User-Name=[email-masked])    (User-Name=[email-masked])

What's the difference between Destination and Routing-Realm?  Why do we need
both?

>          the NAI found in the User-name AVP.

In the STI message specification included in one of your earlier emails, you
included a Route-Record AVP.  What would that be for unless Route-Record is
included in this list?

What happened to Host-Name?  Do we ever route on that?

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 12:43:24 -0800 (PST)

> O.k.  Here are a few comments.  See below.

Cool.
> FQDN of the home server engaged in the sequence?

fair enough. Additional language required in the I-D to state that the
Host-Name from the response is used in the Destination AVP.

> I thought we decided to get rid of redirect servers.

not that I am aware of.

> hashing the user portion of the NAI...

See my previous e-mail about the use of Pearson's hashing algorithm, and the
problems it causes since we have a protocol that does capabilities
negotiation. FWIW, DHCP uses it in a much different way than it was discussed
at the interim meeting.

> aren't confused as to where the NAI came from.

hmm... I would much prefer to keep things separate. I could, however, state
that the realm comes from Routing-Realm or User-Name AVPs. I am just trying to
introduce the concept of routing here, and not get into what is used to route.

> What's the difference between Destination and Routing-Realm?  Why do we need

Destination contains the FQDN of the host the message is intended for. It has
a single possible receiver. Routing-Realm contains the realm the message is
intended for. One does not "route" based on the Destination AVP, but I
included it here to make ssure that proxies handle the Destination NAI first.

> included a Route-Record AVP.  What would that be for unless Route-Record is

Record-Route is only used in responses. I had stated that the Route-Record
didn't belong in the STI message, and have since fixed the I-D.

> What happened to Host-Name?  Do we ever route on that?

nope.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 12:49:10 -0800 (PST)

> > In the STI message specification included in one of your earlier emails,
you > > included a Route-Record AVP.  What would that be for unless
Route-Record is > > included in this list?
> didn't belong in the STI message, and have since fixed the I-D.

hold on. Route-Record MAY be present in the STI. When a message is proxied,
each proxy adds its Route-Record to the message. So, if an MRI is generated,
it has a way to get back.

The text in Section 8.4.1,2 and 3 discuss how the Route-Record works, and I am
including it here as well (but it has hardly changed from the draft-ietf-aaa
version).

PatC
----

8.4.1  Proxying Requests

   In addition to the rules defined in section 8.2, the following
   procedures MUST be handled by proxy servers handling messages of type
   request, query or indication.

   A proxy server MUST check for forwarding loops before proxying a
   message of type Request, Query or Indication. Such as message has
   been looped if the server finds its own address in a Route-Record
   AVP.

   A Diameter server that proxies a message or type Request, Query or
   Indication MUST append a Route-Record AVP, which includes its
   identity.  Diameter Servers that receive messages MUST validate the
   last Route-Record AVP in the message and ensure that the host
   identified in the AVP is the same as the sender of the message.

   A Proxy Server MAY also include the Proxy-State AVP in a message of
   type Request or Query, which is used to encode local state
   information. The Proxy-State AVP is guaranteed to be present in the
   corresponding response.

   The message is then forwarded to the downstream Diameter server, as
   identified in the Domain Routing Table.

   Proxy Server MUST save the Identifier in request messages, and update
   the header field with a locally unique value. The saved identifier

Calhoun et al.             expires July 2001                   [Page 43]

   MAY be encoded in the Proxy-State AVP, and will be required in the
   processing of the corresponding response.

8.4.2  Proxying Responses

   A proxy server MUST only process messges of type Response or Answer
   whose last Route-Record AVP matches one of its addresses. Any
   responses that do not conform to this rule MUST be dropped. The last
   Route-Record AVP MUST be removed from the message before it is
   forwarded to the next hop, which is identified by the second to last
   Route-Record AVP.

   If the last Proxy-State AVP in the message is targeted to the local
   Diameter server, the AVP MUST be removed.

   If a proxy server receives a response with a Result-Code AVP
   indicating a failure, it MUST NOT modify the contents of the AVP. Any
   additional local errors detected SHOULD be logged, but not reflected
   in the Result-Code AVP.

   Prior to forwarding the response, proxy servers MUST restore the
   original value of the Diameter header's Identifier field.

8.4.3  Route-Record AVP

   The Route-Record AVP (AVP Code 282) is of type OctetString, and
   contains the Fully Qualified Domain Name of the Proxy appending this
   AVP to a Diameter message.

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 17:18:37 -0500

> Host-Name from the response is used in the Destination AVP.

O.K. So the Host-Name always indicates the source FQDN and the Destination
always indicates the destination FQDN.

> negotiation. FWIW, DHCP uses it in a much different way than it was discussed

O.K. so use of Pearson's hash is not in the spec at this time.

> included it here to make ssure that proxies handle the Destination NAI first.

It was a stupid question.  I was getting confused.

> didn't belong in the STI message, and have since fixed the I-D.

Bob Kopacz suggests that it will get added to Indication messages as they
are forwarded for loop control -- but not for routing.

> > What happened to Host-Name?  Do we ever route on that?

Because Host-Name always indicates source.  Somehow, I was thinking that
Host-Name identified the client and Destination identified the home server
which would, of course, make routing confusing.  So I think I understand
now.

> PatC

One more question.  I believe a server-to-client Indication message would
contain a Routing-Realm AVP for routing purposes.  How does the server that
originates the message know what realm name to insert in the Routing-Realm
AVP?

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 14:48:34 -0800 (PST)

> > See my previous e-mail about the use of Pearson's hashing algorithm, and
the > > problems it causes since we have a protocol that does capabilities
> O.K. so use of Pearson's hash is not in the spec at this time.

unless I hear otherwise from the WG, I have made my comments on this one
topic, and it doesn't work as people had originally intended.

> It was a stupid question.  I was getting confused.

Perhaps it wasn't properly described, hence the question.

> are forwarded for loop control -- but not for routing.

He is correct.

> originates the message know what realm name to insert in the Routing-Realm

Well, a server initiated message would have to be to a box that it has talked
to before, but I believe that the question is what is the realm, if all you
have is the hostname. Is this correct?

If so, then I believe that it would be everything after the first '.'. Should
we instead include an "Originated-Realm" AVP?

PatC

---

From: David Spence <[email-masked]>
Date: Mon, 12 Feb 2001 17:55:44 -0500

> have is the hostname. Is this correct?

That's the question!

> we instead include an "Originated-Realm" AVP?

I like the Origin-Realm AVP idea better than trying to guess the realm given
the domain name.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 14:57:30 -0800 (PST)

> > If so, then I believe that it would be everything after the first '.'.
Should > > we instead include an "Originated-Realm" AVP?
> I like the Origin-Realm AVP idea better than trying to guess the realm given

Done. I will add this, and I believe that the next version will have a pretty
solid forwarding and routing section.

Thanks for all your help!

PatC

---

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 12 Feb 2001 17:56:36 -0500

Hi Pat and Dave,

I put together a diagram which I think represents what
you two are saying about how Diameter does routing.

It's more than 80 columns, so I'm sending it as an 
attachment to avoid line-wrapping.  It's a simple .txt 
file based on one of the diagrams in the base draft.

I hope it's right.

Bob K.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 15:08:48 -0800 (PST)

Bob,

Great pictures! I will think up of a way to add these to the spec. I think
that they really add alot of value.

Yes, the pictures are correct.

As for the question, as Dave and I mentioned, When a Host-Name AVP is added to
a message, the new Origin-Realm AVP MUST also be added. This will provide the
Realm required for the Routing-Realm AVP in the server initiated messages.

PatC

---

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 12 Feb 2001 18:38:16 -0500

I missed the new Origin-Realm AVP, I guess I only read the first
50 or 60 emails you guys exchanged.  It seems like an Origin-Realm
AVP would be just the ticket to complete the routing picture, unless
there are more complicated routing situations.

> From: Patrice Calhoun [mailto:[email-masked]]
> Sent: Monday, February 12, 2001 6:09 PM
> To: Bob Kopacz
> Cc: David Spence; Pat Calhoun; Aaa-Wg
> Subject: RE: [diameter] Re: [AAA-WG]: Message Forwarding and Routing
> Proposed text
>
>
> Bob,
>

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 12 Feb 2001 15:46:07 -0800 (PST)

> there are more complicated routing situations.

It is a rather complicated problem, but it looks like we have it nailed down.
If someone has a more complicated routing situation, then I would like to hear
about it. Otherwise, I think we have all cases handled. I would really hate to
have to introduce additional complexity :(

I have tried to get your pictures into 80 characters, but it looks like the
laws of physics will prevent me from adding such clarifying diagrams :(

PatC

---

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 13 Feb 2001 08:34:55 -0500

Hi Pat and Dave,

Here's some thoughts:

1. Rename some of the AVPs, for clarification.

a. Since you have an Origin-Realm AVP, rename Routing-Realm to
   Destination-Realm.

b. Since the "-Realm" part of Origin-Realm and Destination-Realm
   clarifies the content, rename the Destination AVP to
   Destination-DN (=destination domain name) or Destination-FQDN.

c. Rename the Host-Name AVP to Origin-DN (or Origin-FQDN).
   This seems a more accurate name, as Host-Name might suggest the
   server's name.

   So now we have a nice symmetric set of AVPs: 
   Origin-Realm, Destination-Realm, Origin-DN, and Destination-DN.

   Also, the Error-Reporting-NAI AVP, if it still exists, might
   become the Error-Reporting-DN AVP.

2. Require that Destination-Realm, if known, must be included in
   every Request/Query/Indication message.

   This means the NAS, when building a request, would extract the
   realm portion of the User-Name and create the Destination-Realm.

   My thinking is that this provides some benefits:

a. User-Name is not involved in routing, so we have one less AVP
   player in the routing game.

b. Things are simpler for hops along the way.  Instead of fishing
   around for an optional Routing-Realm, falling back to the
   User-Name, and parsing the User-Name for the realm, a server just
   looks for Routing-Realm.  

   Even if the Routing-Realm isn't present, it's no use looking at
   the User-Name.  User-Name will either not be present, or will not
   include a realm.

   If Routing-Realm is not present in the Request sent by the NAS,
   then the first hop proxy fills it in.  The Routing-Realm might not
   be present in the NAS's Request because (i) the Request has been
   sent before the NAS has answered the call, or (ii) this is a login
   request, so the user name has no realm portion.

c. User-Name is not so overloaded.  User-Name is used for
   identifying the user, but isn't used in routing.

3. So my understanding of the routing rules becomes:

a. REQUESTs must contain Origin-Realm, Destination-Realm if
   known, and Origin-DN.

   Routing is by Destination-Realm, which the first hop proxy fills
   in if the NAS omitted this AVP.

   The NAS's Request contains no Route-Record AVPs.

   The Request that the home server receives contains N Route-Record
   AVPs, where N = the number of proxies.

b. RESPONSEs must contain Origin-Realm, Destination-Realm,
   Origin-DN, Destination-DN.  The Response's Destination-Realm is
   the Request's Origin-Realm.

   The Response sent by the home server contains the N Route-Record
   AVPs received in the Request.  

   Each proxy removes one Routing-Record AVP.

   The Response received by the NAS contains no Route-Record AVPs.

   For all but the last hop, the response is forwarded by
   Routing-Record.  

   The last hop is routed by Destination-DN.

c. INDICATIONs must contain Origin-Realm, Destination-Realm,
   Origin-DN, Destination-DN.

   The Indication sent by the home server contains no Route-Record
   AVPs.

   Each proxy adds one Routing-Record AVP.

   The Indication received by the NAS contains N Route-Record AVPs,
   where N = the number of proxies.

   Routing is by Destination-Realm.

Bob K.

---

From: Wei Wang <[email-masked]>
Date: Mon, 19 Feb 2001 14:33:09 -0500

>    become the Error-Reporting-DN AVP.

I don't like the "DN" somehow -- maybe because "DN" means 
DistinguishedName in the directory world. FQDN may be okay. But 
why not just say "Host", since a FQDN identifies a host or hosts.

>    request, so the user name has no realm portion.

So the User-Name is still involved in routing, although probably 
only for the first hop proxy.

>    AVPs, where N = the number of proxies.

The first hop proxy should also be able to fill in the 
Origin-Realm and Origin-DN(-Host) if missing, since it should know 
about those for sure. Right?

Regards,

-- 
Wei Wang                  mailto:[email-masked]
Interlink Networks, Inc.  http://www.interlinknetworks.com
[Tel] 734-821-1204        [Fax] 734-821-1235

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 19 Feb 2001 11:42:57 -0800 (PST)

Sorry I never responded to this original e-mail (just occured to me now)

> why not just say "Host", since a FQDN identifies a host or hosts.

I decided upon *-FQDN.

> only for the first hop proxy.

It never is. The Destination-Realm is always used, and MUST be present in ANY
message that can be proxied. 

> about those for sure. Right?

But why make special cases for the proxy. These AVPs are mandatory in ALL
messages.

PatC