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

From: <[email-masked]>
Date: Tue, 20 Jan 2004 13:59:55 +0200

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:
> 
> 	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: Joe Harvell <[email-masked]>
Date: Wed, 28 Jan 2004 12:54:05 -0600

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).

---

From: Joe Harvell <[email-masked]>
Date: Fri, 30 Jan 2004 14:28:58 +0000

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.
>
> 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:
>
>>> From: [email-masked] [mailto:[email-masked]]On 
>>> Behalf Of
>>> ext Joe Harvell
>>> 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
>>>
>>>
>>
>>
>
>