Subject: Re: [AAA-WG]: Re: Route-Record AVP in Indication message

From: Patrice Calhoun <[email-masked]>
Date: Wed, 11 Apr 2001 15:05:09 -0700

>OK. The DSI message is NOT a response to the request.    That's say the
>AAA3 use Destination-Realm to route the DSI message and send the
>DSI "directly" to AAA1 instead of AAA2.   Here is the problem.  AAA2
>would NEVER receive any RESPONSE after send out the request.
>

The following text below states that AAA2 must keep all pending messages
in a queue. So, if these messages are queued, the appropriate responses
can be generated by AAA3, and they would include the correct routing AVPs.

7.3  Failover/Failback Procedures

   In the event that a transport failure is detected with a peer, it is
   necessary for all pending request, query and indication messages to
   be forwarded to an alternate server, if possible. This is commonly
   referred to as failover.

   In order for a Diameter node to perform failover procedures, it is
   necessary for the node to maintain a pending message queue for a
   given peer. When a response is received, the message is removed from
   the queue. The Hop-by-Hop Identifier field MAY be used to match the
   corresponding response with the queued request.

   [...]

PatC

---

From: Michael Chen <[email-masked]>
Date: Wed, 11 Apr 2001 14:20:56 -0700

Pat,

  I guess you misunderstood what I meant. Let me try it again.

Here is the request send to AAA4
AAA1->AAA2->AAA3---- link broken ---->AAA4

AAA3----send DSI---->AAA1

AAA3 must generate DSI and send it back to AAA1.
This DSI is NOT a response to the request so it MUST NOT include
the route-record AVPs that were present in the request.
AAA3 route the message base on Destination-Realm AVP and let's
say this DSI message routing result is  "directly" to AAA1 instead
of AAA2. My question is AAA2 keeping the pending request but AAA2
did NOT receive reply in this case.

Patrice Calhoun wrote:

DSI message you mention here is *not* a response to the
request that generated the message, it MUST NOT include the route-record AVPs
that were present in the request.

> AAA1(a.com) AAA2(b.com)  AAA3(c.com)   AAA4(d.com)
  >----------  -----------  -----------   ------------
  >
  >     ----------->
  >     route-record=aaa1.a.com
  >
  >                 ------------->
  >                 route-record=aaa1.a.com
  >                 route-record=aaa2.b.com
  >
  >                               -----link broken---
  >
  >                 <-------------
  >                 route-record=aaa3.c.com
  >     <-------------
  >     route-record=aaa3.c.com
  >     route-record=aaa2.b.com

---

From: Michael Chen <[email-masked]>
Date: Wed, 11 Apr 2001 17:06:18 -0700

In Diameter MobileIP draft

 Section 5.7
 " If the mobile node requests a home agent in the foreign network by
   setting the home address field to all ones, and the AAAF authorizes
   the request, the AAAF MUST set the Home-Agent-In-Foreign-Network bit
   to one."

There are some text need clarify and some text is missing here.

1.  If the mobile node sets the home address field equal to 255.255.255.255
    in  its Registration Request, the Foreign Agent MUST set the Mobile-Node-
    Home-Address-Requested flag to one.  In addition, the FA MUST include the
    MIP_Mobile_Node_Address AVP set to all ones to inform the AAA to set the
    Home-Agent-In-Foreign-Network bit to one if it's policy allows.

2.   Just to be explicit, it could help to include text stating that the
Foreign Agent
      MUST NOT send the MIP_Mobile_Node_Address AVP set to
      0.0.0.0  if   the mobile node sets the home address field equal to
0.0.0.0  in
      its Registration Request.

3.   Also, to be explicit, the Foreign Agent MUST NOT send the
      MIP_Home_Agent_Address AVP set to either
      0.0.0.0  or 255.255.255.255 if   the mobile node sets the home agent
address
       field equal to 0.0.0.0  or 255.255.255.255 in  its Registration
Request.

4.   As a question, what would happen if the Mobile Node sends a registration
      request with both the home address and home agent address set to
255.255.255.255?
      Is this already disallowed by Mobile IP?  If not, something must be
specified in Diameter
      since these settings conflict- should the FA send immediately send back
a MIP-Reg-Reply
      indicating failure, or should the request go to the AAA which would then
respond to the FA
      with a DSI or AMA?