Re: [Dime] Route-Record in CCA

[Ravi <nrs2712 at gmail.com>]

Even I had the same opinion that Route-Record need not be present in the answer messages.
Then how do I explain this text from the bis 16.

"  A local realm may wish to limit this exposure, for example, by
   establishing credit limits for intermediate realms and refusing to
   accept responses which would violate those limits.  By issuing an
   accounting request corresponding to the authorization response, the
   local realm implicitly indicates its agreement to provide the service
   indicated in the authorization response.  If the service cannot be
   provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
   message MUST be sent within the accounting request;"


If a local realm agent/node needs to refuse a response which traverses intermediate realms, it needs to know the path the request has traversed. How would the local node know that? Is this done using Route-Record? Then should we not update section 6.2 "Diameter Answer Processing" to say that server needs to add the Route-Record AVPs from the request to the answer?

Another question on the same section....

"If the service cannot be provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error message MUST be sent within the accounting request"

How is this done? Another AVP?

On Wed, Mar 11, 2009 at 10:12 AM, Rajith R <rajithr at huawei.com> wrote:

IMHO, checking the Route-Record AVPs in response and deciding whether the
route is acceptable is needless b/c response path is same as request path
and server is anyways provisioned for checking the request path. Hence, no
need to have Route-Record AVP in responses.

The -bis draft probably shares this view & hence has removed this text.

Regards

Rajith


________________________________________

From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of

Gowda, Avinash
Sent: Tuesday, March 10, 2009 11:31 PM
To: Ravi; dime at ietf.org
Subject: Re: [Dime] Route-Record in CCA

Hi Ravi,

Following section in RFC 3588 will answer your question.

2.10. Diameter Path Authorization
Similarly, the local Diameter agent, on receiving a Diameter response
authorizing a session, MUST check the Route-Record AVPs to make sure
that the route traversed by the response is acceptable. At each
step, forwarding of an authorization response is considered evidence
of a willingness to take on financial risk relative to the session.
A local realm may wish to limit this exposure, for example, by
establishing credit limits for intermediate realms and refusing to
accept responses which would violate those limits. By issuing an
accounting request corresponding to the authorization response, the
local realm implicitly indicates its agreement to provide the service
indicated in the authorization response. If the service cannot be
provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
message MUST be sent within the accounting request; a Diameter client
receiving an authorization response for a service that it cannot
perform MUST NOT substitute an alternate service, and then send
accounting requests for the alternate service instead.

Thanks,
Avinash Gowda
________________________________________
From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of Ravi
Sent: Tuesday, March 10, 2009 10:52 PM
To: dime at ietf.org
Subject: [Dime] Route-Record in CCA

Hi,
   As per RFC  4006, the CCA message has the following ABNF format

<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
                                  < Session-Id >
                                  { Result-Code }
                                  { Origin-Host }
                                  { Origin-Realm }
                                  { Auth-Application-Id }
                                  { CC-Request-Type }
                                  { CC-Request-Number }
                                  [ User-Name ]
                                  [ CC-Session-Failover ]
                                  [ CC-Sub-Session-Id ]
                                  [ Acct-Multi-Session-Id ]
                                  [ Origin-State-Id ]
                                  [ Event-Timestamp ]
                                  [ Granted-Service-Unit ]
                                 *[ Multiple-Services-Credit-Control ]
                                  [ Cost-Information]
                                  [ Final-Unit-Indication ]
                                  [ Check-Balance-Result ]
                                  [ Credit-Control-Failure-Handling ]
                                  [ Direct-Debiting-Failure-Handling ]
                                  [ Validity-Time]
                                 *[ Redirect-Host]
                                  [ Redirect-Host-Usage ]
                                  [ Redirect-Max-Cache-Time ]
                                 *[ Proxy-Info ]
                                 *[ Route-Record ]
                                 *[ Failed-AVP ]
                                 *[ AVP ]

What is the purpose of having Route-Record AVP in CCA message? What problem
does it solve? As far as I know, the route-record AVP can be present only in
requests.