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

From: Thomas Panagiotis-PTHOMAS1 <[email-masked]>
Date: Wed, 4 Jul 2001 15:18:39 -0500

hmmm... I understood it differently. So we need at least some
text to clarify things :), maybe as part of issue 82? Here's
what I thought...

Session Management is generic and defined across applications
(MIPv4,Dial-up,...). The Session-Timeout AVP is tied to a 
Session-Id, therefore each session has its own Session-Timeout.
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.

So, if the above is the indent, 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.

-Panos

-----Original Message-----
From: Martin Julien (ECE) [mailto:[email-masked]]
Sent: 04 July 2001 03:43
To: 'Thomas Panagiotis-PTHOMAS1'; Martin Julien (ECE)
Cc: [email-masked]'
Subject: RE: Issue 89: Editorial comments - Mobile-IP draft-06

Hi Thomas,

See comments.

> From: Thomas Panagiotis-PTHOMAS1 [mailto:[email-masked]]
> 
> Hi Martin,
> 
> I have a question with one of your comments in issue #89 
> (which is now in
> the resolved list).
> 
> >> ...
> >> 8) Section 2.4, I don't think it is very clean, with 
> regards to the 
> >> specification, to expect that the HA will be responsible 
> of forwarding
> >> the Session-Timeout, the Authorization-Lifetime, the 
> MIP-FA-to-MN-Key
> >> and the MIP-FA-to-HA-Key AVPs in the HAA. When I see those 
> attributes 
> >> in the HAA, I always have to remind me that they are 
> meaningless to the 
> >> HAA, but only meaningful to make easier the conversion of 
> the HAA into
> >> a AMA in the AAAH, which I consider not very useful 
> anyway, since the
> >> AAAH still needs to check that they have been included 
> properly. Well,
> >> my opinion is that we should remove them from there, since they are
> >> meaningless to the AAAH that receives the HAA. 
> > 
> > ok. A few revisions of the base protocol base, less state 
> was required on 
> > the AAAH. Nowadays, though, I agree that the AAAH can 
> easily keep this 
> > state information (or add it to Proxy-State if it really wants to).
> > ...
> 
> Don't we need to have the Session-Timeout AVP in the HAR/HAA messages
> to refer to the session created between the AAAH and the HA?

My understanding is that the Session-Timeout AVP is used to represent
the time limit of a user-session in a Diameter node. It is used in 
the AMR to inform the AAAH about the maximum duration of the session in
the Diameter client. That means that the AAAH can accept the hint, or
change it for a lower value. It is then forwarded to the HA in the HAR,
in order to clean the session accordingly at the session-timeout. So,
basically, my understanding is that the FA, the AAAF, the AAAH and the
HA should have the same value of the Session-Timeout, right? It seems
to be only one final value of the Session-Timeout, which is decided by
the AAAH. What I am not sure is if the HA could lower down again the
value of the Session-Timeout? That would be a possible good reason for
including the Session-Timeout AVP in the HAR???? Any thoughts?

Note that the Session-Timeout is also discussed in issue 82.

Now that we´re talking about it, I am wondering a couple of things.
The problem is that the Authorization Session State-Machine (10.1) 
says that when the Session-Timeout expires on a Diameter client,
then an STR is sent. However, when it expires on the AAAH, nothing
needs to be sent, only clean-up occurs. That would mean that the FA
and the HA would send simultaneously an STR, which would make the
AAAH receive 2 STR for the same session, while it is already cleaning
the session. Receiving 2 STR is fine, since the AAAH have to support
MIP roaming between different FAs. However, it is not so good to be
already cleaning the session in the AAAH, while 2 STR are expected.
Unless I don't have a good understanding of the 
Session-Timeout AVP, I think it would not work very well. What do you
think? Maybe an issue should be raised about it.

Martin

> Thanks,
> -Panos

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 10 Jul 2001 09:26:13 -0700

> Session-Id, therefore each session has its own Session-Timeout.

correct.

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

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

PatC