Subject: [AAA-WG]: Diameter Client request routing

From: Joe Harvell <[email-masked]>
Date: Mon, 19 Jan 2004 13:12:39 -0600

I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based Routing Table), 5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of Diameter Base Protocol, and I am a little confused about how a Diameter Peer is to be selected for sending a request from a Diameter Client.

Consider the case of a Diameter Client that does not implement Diameter Peer Discovery.  This means that Diameter Peers are statically configured.  The Capabilities Exchange process will definitely identify the Realm and Host of each Diameter Peer.  However, the only cases in which a peer can be identified as a candidate next hop for sending a particular request are as follows:

	1) when its Realm matches the Destination-Realm of a message with Destination-Realm only; and
	2) when its Realm and Host match the Destination-Realm and Destination-Host of a message with a Destination-Realm and Destination-Host.

So how does a Diameter Client identify a candidate peer for sending messages in the other cases?

Section 5.1 indicates that a Diameter Node should have established connections with a minimum of two (a primary and possibly multiple secondary) peers per realm.  Does the "realm" in this context mean that both peers are members of the same realm, or that both peers can route messages to a given Destination-Realm?  Can Diameter Agents forward requests for a Destination-Realm that is not their Realm?

When a Diameter Client has a request with a Destination-Realm and Destination-Host, will all the primary and secondary peers described in 5.1 be able to route the request to that Destination-Host in that Destination-Realm?

---
Joe Harvell
Shasta GGSN Development
Nortel Networks
+1 972.685.4886

---

From: <[email-masked]>
Date: Fri, 30 Jan 2004 16:30:56 +0200

Joe,

Sorry that I have not replied yet, I have been under a mountain of
other work.  I will try to sort this out early next week.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Joe Harvell
> Sent: 30 January, 2004 16:29
> To: Aittola Mikko (Nokia-NET/Helsinki)
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Diameter Client request routing
> 
> 
> Mikko:
> 
> So since 6.1 doesn't apply to Diameter Clients, my original questions 
> remain unanswered.  Any comments?
> 
> Harvell, Joe [RICH2:2Q40:EXCH] wrote:
> 
> > Mikko:
> >
> > I have read this section.  There is a good description of 
> how request 
> > forwarding and routing work for Diameter Agents.  However, 
> a Diameter 
> > Client is not a Diameter Agent.
> >
> > I did find an example in section 2.8.2 that suggests that Diameter 
> > Clients performs a "routing lookup."
> >
> >     The example provided in Figure 2 depicts a request
> >     issued from a NAS [Diameter Client], which is an
> >     access device, for the user [email-masked].  Prior
> >     to issuing th erequest, NAS performs a Diameter
> >     route lookup, using "example.com" as the key, and
> >     determines that the message is to be relayed to
> >     DRL, which is a Diameter Relay.
> >
> > To me, this sounds like a Diameter Client following step 3 
> on page 72 
> > in 6.1.  However, this procedure describes how to process a 
> received 
> > message; and this doesn't apply to messages originated by a 
> Diameter 
> > Client.  Also, the following description of request routing 
> from 6.1 
> > only applies to Diameter Agents:
> >
> >     Note that an agent can forward a request to a host
> >     described in the Destination-Host AVP only if the
> >     host in question is included in its peer table
> >     (see Section 2.7).  Otherwise, the request is
> >     routed based on the Destination-Realm only
> >     (see Sections 6.1.6).
> >
> >
> >
> > [email-masked] wrote:
> >
> >> Hi,
> >>
> >> May I suggest reading also Section 6.1, 'Diameter Request Routing 
> >> Overview'? :)
> >>
> >> It should be noted that according to the spec if Destination-Host 
> >> matches
> >> the value of Destination-Realm can be ignored.
> >>
> >>
> >> BR,
> >> Mikko
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]]On 
> >>> Behalf Of
> >>> ext Joe Harvell
> >>> Sent: 19 January, 2004 21:13
> >>> To: [email-masked]
> >>> Subject: [AAA-WG]: Diameter Client request routing
> >>>
> >>>
> >>> I have reviewed 2.6 (Peer Table), 2.7 (Realm-Based 
> Routing Table), 
> >>> 5.1 (Peer Connections), and 5.2 (Diameter Peer Discovery) of 
> >>> Diameter Base Protocol, and I am a little confused about how a 
> >>> Diameter Peer is to be selected for sending a request from a 
> >>> Diameter Client.
> >>>
> >>> Consider the case of a Diameter Client that does not implement 
> >>> Diameter Peer Discovery.  This means that Diameter Peers are 
> >>> statically configured.  The Capabilities Exchange process will 
> >>> definitely identify the Realm and Host of each Diameter Peer.  
> >>> However, the only cases in which a peer can be identified as a 
> >>> candidate next hop for sending a particular request are 
> as follows:
> >>>
> >>>     2) when its Realm and Host match the Destination-Realm and 
> >>> Destination-Host of a message with a Destination-Realm and 
> >>> Destination-Host.
> >>>
> >>> So how does a Diameter Client identify a candidate peer 
> for sending 
> >>> messages in the other cases?
> >>>
> >>> Section 5.1 indicates that a Diameter Node should have 
> established 
> >>> connections with a minimum of two (a primary and possibly 
> multiple 
> >>> secondary) peers per realm.  Does the "realm" in this 
> context mean 
> >>> that both peers are members of the same realm, or that both peers 
> >>> can route messages to a given Destination-Realm?  Can Diameter 
> >>> Agents forward requests for a Destination-Realm that is not their 
> >>> Realm?
> >>>
> >>> When a Diameter Client has a request with a Destination-Realm and 
> >>> Destination-Host, will all the primary and secondary 
> peers described 
> >>> in 5.1 be able to route the request to that 
> Destination-Host in that 
> >>> Destination-Realm?
> >>>
> >>> ---
> >>> Joe Harvell
> >>> Shasta GGSN Development
> >>> Nortel Networks
> >>> +1 972.685.4886
> >>>
> >>>
> >>
> >>
> >
> >
> 
>

---

From: <[email-masked]>
Date: Sat, 31 Jan 2004 14:14:49 +0200

Hi,

> then my only question is whether a Diameter Node's identity
> (what it sends for Origin-Host in CER) is expected to be unique 
> only within a Realm, or unique even across Realms.

According to the spec DiameterIdentity is unique even across Realms.

BR,
Mikko

> From: ext Joe Harvell [mailto:[email-masked]]
> Sent: 30 January, 2004 18:47
> This boils down to a difference of opinion on whether 6.1 applies to 
> Diameter Clients (and Diameter Servers for that matter).  If 
> this is the 
> case, then my only question is whether a Diameter Node's 
> identity (what 
> it sends for Origin-Host in CER) is expected to be unique 
> only within a 
> Realm, or unique even across Realms.
> 
> If 6.1 does apply to all Diameter Nodes, then that is not 
> clear in the 
> Diameter Base spec.  I have replied to your questions below...
> 
> >Can you describe an example problem-case that you think is 
> not covered by the
> >specification?
> >
> I have.  Refer to my original email.
> 
> >
> >Also, did you only look at the text in Section 6.1 without
> >regarding what is said in other parts of the spec, for
> >example in sub-sections of 6.1?
> >
> Yes, I have read the entire spec, with particular attention 
> to 6.1 and 
> its subsections.
> 
> > There is also text elsewhere
> >about the routing tables etc.
> >
> Yes, I have seen references to this.  In almost all cases, the text 
> describes the action of Diameter Agents or actions of Diameter Nodes 
> receiving requests and then forwarding/routing them.
> 
> The only case I have found where it is suggested that something other 
> than a Diameter Agent uses the routing mechanism described in 
> 6.1 is the 
> description of the example in 2.8.2, which I have already included.
> 
> >
> >I think it is not useful to copy-paste here all the routing 
> related text
> >that applies to Diameter Clients. It wouldn't make the text 
> any easier
> >to understand.
> >
> Have you even looked at Section 6.1 since I posed this question?
> 
> >
> >
> >BR,
> >Mikko
> >
> >
> >From: ext Joe Harvell [mailto:[email-masked]]
> >Sent: 30 January, 2004 17:28
> >I find nothing in 6.1 that describes how a Diameter Client 
> routes requests it originates.  Could you identify specific 
> text from that section that suggests it does apply to 
> Diameter Clients?
> >
> >Does anyone else have an opinon on this?
> >
> >I think Section 6.1 clearly does apply to Diameter Clients. Of course
> >there is identified parts that apply only to agents.
> >Yes, the parts that describe the routing mechanism.
> >
> >
> >I'm afraid I can't understand what kind of case you think is not
> >covered by the specification.
> >
> >
> >BR,
> >Mikko
> >
> >
> >  
> >From: ext Joe Harvell [mailto:[email-masked]]