Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft- 06

From: Pat Calhoun <[email-masked]>
Date: Wed, 11 Jul 2001 09:12:35 -0700

On Wed, Jul 11, 2001 at 11:10:51AM -0500, Thomas Panagiotis-PTHOMAS1 wrote:
> I think we are in sync now! :) Please see comments below.
> 
> > > Consider the session between the AAAH and the HA. What's the event/
> > > action for the transition from Idle to Pending on the AAAH side? 
> > 
> > Sending the HAR moves it from Idle to Pending, this is the first event
> > in the state machine. The HAA moves it to Open.
> >
> > > What's the event/action for the transition from Idle to Open on the
> > > HA side?
> >
> > Receiving, and successfully processing the HAA. This is the second event
> > in the state machine.
> 
> It's HAR right?

oops, right.

> 
> >
> > I am still missing the issue, though :(
> 
> It's only editorial. Below is the description of the session state machine
> in
> 10.1 of diameter-05.txt. If it is clear to everyone that HAR *is* a
> "Service-
> Specific authorization request", then there is no issue at all :)

you are correct, and yes I agree there is no issue :)

PatC
> 
>       State     Event                          Action     New State
>       -------------------------------------------------------------
>       Idle      Client or Device Requests      send       Pending
>                 access                         service
>                                                specific
>                                                auth req
> 
>       Idle      Service-Specific authorization send serv. Open
>                 request received, and          specific
>                 successfully processed         answer
> 
>  	Pending   Successful Service-Specific    Grant      Open
>                 Authorization answer           Access
>                 received
> 
> -Panos
> 
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: 11 July 2001 09:51
> To: Thomas Panagiotis-PTHOMAS1
> Cc: 'Pat Calhoun'; 'Martin Julien (ECE)'; [email-masked]'
> Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP
> draft- 06
> 
> 
> On Wed, Jul 11, 2001 at 09:18:40AM -0500, Thomas Panagiotis-PTHOMAS1 wrote:
> > > > So, if the above is the intent, then the Session-Timeout AVP
> > > > should be included (as optional) in the definition of the AMR/AMA,
> > > > HAR/HAA messages. In addition, the Authorization-Lifetime AVP must
> > > > be included (as mandatory) in the HAR message to inform the HA on
> > > > the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should
> > > > be noted somewhere that the trigger for initiating sessions is not
> > > > always an Auth Request from the Client, but MAY be an application
> > > > specific message (HAR) coming from a Server.
> > >
> > > How could the AAAH cause the FA to force the mobile to re-register? I'm
> > > not sure that I understand your point here.
> > 
> > Let me try one more time...
> > 
> > AAAH will have at least 2 session state machines (SMs) on behalf of a
> user.
> > One for the session with the serving FA (FA-AAAH) and one for the session
> > with the HA (AAAH-HA). Correct?
> yes
> 
> > 
> > Consider the session between the AAAH and the HA. What's the event/action
> > for the transition from Idle to Pending on the AAAH side? 
> 
> Sending the HAR moves it from Idle to Pending, this is the first event in
> the state machine. The HAA moves it to Open.
> 
> > What's the
> > event/action
> > for the transition from Idle to Open on the HA side?
> 
> Receiving, and successfully processing the HAA. This is the second event in
> the
> state machine.
> 
> I am still missing the issue, though :(
> 
> 
> > 
> > > > Diameter entities initiate sessions by sending Application-Specific
> > > > requests which MAY carry a proposed value for the Session-Timeout.
> > > > However, the receiver of the request has the last word on the value
> > > > of the Session-Timeout, which is sent in the corresponding answer.
> > > > Offering MIPv4 service to a user requires the establishment of
> > > > more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA,
> > > > where [ ] indicates the initiator of the session. The sessions
> > > > are tied together through the Accounting-Multi-Session-Id.
> > >
> > > The AAAH, acting as a server, always has the final say on the session
> > > and authorization timeouts.
> > 
> > I agree. How would this be enforced for the Session-Timeout value?
> > a) AAAH sends a HAR message to HA with a Session-Timeout value. HA MUST
> >    accept the value. In this case there is no need to return the value
> >    to AAAH.
> 
> correct.
> 
> > b) AAAH sends a HAR message to HA with the preferred Session-Timeout value
> >    and the Authorization-Lifetime AVP. If HA doesn't like the
> > Session-Timeout
> >    it can propose any value larger than the Authorization-Lifetime AVP. If
> >    AAAH doesn't like the value it sends back an error.
> 
> no, the HA cannot increase the Session-Timeout. However, if the HA is in a
> foreign network, I *suppose* it (or the AAAF processing the HAR/HAA) should
> be permitted to lower the Session-Timeout and/or Authorization-Lifetime
> AVPs.
> 
> > 
> > So, is (a) what you have in mind?
> 
> That was my initial thought, but (b) now sounds quite feasible.
> 
> PatC

---

From: Thomas Panagiotis-PTHOMAS1 <[email-masked]>
Date: Wed, 11 Jul 2001 11:10:51 -0500

It's HAR right?

-Panos

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: 11 July 2001 09:51
To: Thomas Panagiotis-PTHOMAS1
Cc: 'Pat Calhoun'; 'Martin Julien (ECE)'; [email-masked]'
Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP
draft- 06

user.
yes

correct.

PatC