Subject: RE: Usage scenarios

From: <[email-masked]>
Date: Mon, 11 Feb 2002 14:33:58 -0600

Hi Alper,

Glad to see that you agree on that scenario.

I was thinking that we could add the following text in the PANA Usage scenario draft to better explain how we could use PANA as the missing piece of Mobile IPv6 as you suggested:

* PANA for Diameter Mobile IPv6 Application

Mobile IP defines a method that allows a Mobile Node to change its point of attachment to the Internet with minimal service disruption. However, Mobile IP in itself does not provide any specific support for mobility across different administrative domains, which limits the applicability of Mobile IP in a large-scale commercial deployment.

Diameter extensions for Mobile IPv4 have already been specified in order to allow a MIPv4 node to receive services from service providers (home and foreign) and allowing the Diameter servers to authenticate, authorize and collect accounting information for those MIPv4 nodes. In the same way, a Diameter Mobile IPv6 application will be specified and the work is actually currently being done.

Even though MIPv4 and MIPv6 are similar when observed at high level, the two protocols are actually quite different when considering the support for Inter Domain deployment. Mobile IPv4 extended the Registration Request message to carry the user's credential to the local domain to get authenticated and get access to the network. Mobile IPv6 does not have the equivalent of a Foreign Agent as defined in Mobile IPv4, and as a result Mobile IPv6 does not define any mechanism by which the visited network can exhange messages with the mobile node to authenticate and authorize access to the network and use of resources. However, a protocol describing the interaction between the mobile node and the network in order for the mobile node to get access to the network resources, be authenticated and authorized is needed.

PANA can be a good candidate and fill the gap allowing the mobile node to send its credentials to the local network and performs authentication. Although as stated in [PANA_Reqts], PANA MUST NOT handle mobility of the PaC, the requirements state that PANA MUST be able to co-exist and not interfere with various mobility management protocols, such as Mobile IPv6.  

If PANA is applied directly to Mobile IPv6 scenarios, a mobile node may have to first interact with the network according to PANA procedure and, only once the mobile node has been authenticated and authorized, the mobile node performs Mobile IPv6 procedures. This may lead to inefficiencies in terms of signaling load over the access link and in terms of round trips between the foreign domain and the home domain required by the mobile node authentication. The former is an issue particularly for access links with limited and expensive bandwidth, the latter is in general an issue of signaling overload and in terms of latency.

For the reasons described above, we propose an additional scenario for PANA. We suggest that PANA SHOULD allow integration of the mobility and the authentication procedures for Mobile IPv6 in order to reduce the initial registration time latency, as required in RFC 2977 [RFC 2977].

                 +----+      +----+
                 |AAAL|------|AAAH|
+--+    +----+  /+----+      +----+  +--+
|MN|    |PAA/| /                     |HA|
|MN|    |AAAc|                       |HA|
+--+    +----+                       +--+

  <------>  <------------------------->
    PANA     Diameter MIPv6 Application

                Mobile IPv6
  <- - - - - - - - - - - - - - - - - >

According to the proposed scenario, the mobile node interacts with a PANA agent in the local network using PANA protocol to get authenticated and authorized (e.g. PAA can act ass AAA client according tot eh AA model). The mobile node also includes the mobility information it would normally use in Mobile IPv6 (e.g. an embedded Binding Update), in order to avoid the nedd for additional round trips (e.g. as described in [draft-le-aaa-diameter-mobileipv6-01.txt]).

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 06 February, 2002 8:12 PM
> To: Le Franck (NRC/Dallas); [email-masked]
> Subject: Re: Usage scenarios
> 
> 
> Frank,
> 
> This is a very good scenario.
> 
> We can show how to use PANA as the missing piece of Mobile 
> IPv6: an attended
> in
> the visited network to grant network access first, before the 
> mobile node
> registers
> with the home agent.
> 
> PANA is a better fit than PPP or 802.1x, because by using PANA
> we can keep the complete solution (Mobile IPv6 + PANA)
> L2 independent.
> 
> alper
> 
> 
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, February 06, 2002 4:13 PM
> Subject: Usage scenarios
> 
> 
> > Hello all,
> >
> > As another usage scenario, should we also consider the 
> usage of PANA for a
> Diameter Mobile IPv6 application?
> >
> > - A Diameter Mobile IPv6 application will most probably be 
> defined to
> allow a commercial deployement of Mobile IPv6 (Inter domain roaming)
> >
> > - But since Mobile IPv6 does not have the equivalent of a 
> Foreign Agent,
> MIPv6 does not define the equivalent of the MIPv4 
> Registration Request the
> user can use in order to send its credential to get 
> authenticated and get
> access to the local network
> >
> > - PANA could be a good candidate for the user to send its 
> credentials to
> the local network and performs authentication. Although I 
> agree that PANA
> must not handle mobility management; it should co-exist with MIPv6 and
> allows integration of the authentication and mobility 
> procedures as required
> in RFC 2977 in order to reduce the initial registration time latency.
> >
> > The requirement draft states that "Mobile IPv4 registration request
> message is used as the carrier for authentication extensions (MN-FA
> [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service 
> from the foreign
> agents. In that sense, designing the equivalent of Mobile  
> IPv4 registration
> request messages for general network access is the goal of 
> this work, but
> not defining the equivalent of MN-FA or MN-AAA extensions." 
> and has the
> following requirement: "PANA MUST NOT handle mobility 
> management of the PaC.
> But, it MUST be able to co-exist and not interfere with 
> various mobility
> management protocols, such as Mobile IPv4 [MIPV4], Mobile 
> IPv6 [MIPV6]" so I
> was thinking that we could add the equivalent of MIPv4 
> Registration Request
> for MIPv6 in the usage scenarios draft.
> >
> > Looking forward for your comments,
> >
> > Thank you,
> >
> > Franck
> >
> >
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 11 Feb 2002 19:19:11 -0800

Frank,

> I was thinking that we could add the following text in the PANA Usage
scenario draft to better explain how we could use PANA as the missing piece
of Mobile IPv6 as you suggested:
> Mobile IP defines a method that allows a Mobile Node to change its point
of attachment to the Internet with minimal service disruption. However,
Mobile IP in itself does not provide any specific support for mobility
across different administrative domains, which limits the applicability of
Mobile IP in a large-scale commercial deployment.
>
> Diameter extensions for Mobile IPv4 have already been specified in order
to allow a MIPv4 node to receive services from service providers (home and
foreign) and allowing the Diameter servers to authenticate, authorize and
collect accounting information for those MIPv4 nodes. In the same way, a
Diameter Mobile IPv6 application will be specified and the work is actually
currently being done.
>
> Even though MIPv4 and MIPv6 are similar when observed at high level, the
two protocols are actually quite different when considering the support for
Inter Domain deployment. Mobile IPv4 extended the Registration Request
message to carry the user's credential to the local domain to get
authenticated and get access to the network. Mobile IPv6 does not have the
equivalent of a Foreign Agent as defined in Mobile IPv4, and as a result
Mobile IPv6 does not define any mechanism by which the visited network can
exhange messages with the mobile node to authenticate and authorize access
to the network and use of resources. However, a protocol describing the
interaction between the mobile node and the network in order for the mobile
node to get access to the network resources, be authenticated and authorized
is needed.
>
> PANA can be a good candidate and fill the gap allowing the mobile node to
send its credentials to the local network and performs authentication.
Although as stated in [PANA_Reqts], PANA MUST NOT handle mobility of the
PaC, the requirements state that PANA MUST be able to co-exist and not
interfere with various mobility management protocols, such as Mobile IPv6.
>
> If PANA is applied directly to Mobile IPv6 scenarios, a mobile node may
have to first interact with the network according to PANA procedure and,
only once the mobile node has been authenticated and authorized, the mobile
node performs Mobile IPv6 procedures. This may lead to inefficiencies in
terms of signaling load over the access link and in terms of round trips
between the foreign domain and the home domain required by the mobile node
authentication. The former is an issue particularly for access links with
limited and expensive bandwidth, the latter is in general an issue of
signaling overload and in terms of latency.
>
> For the reasons described above, we propose an additional scenario for
PANA. We suggest that PANA

I was agreeing to all until this last sentence... I understand the
inefficiencies, but still I'd rather
not "integrate" mobile IPv6 into PANA.....

alper

SHOULD allow integration of the mobility and the authentication procedures
for Mobile IPv6 in order to reduce the initial registration time latency, as
required in RFC 2977 [RFC 2977].
> According to the proposed scenario, the mobile node interacts with a PANA
agent in the local network using PANA protocol to get authenticated and
authorized (e.g. PAA can act ass AAA client according tot eh AA model). The
mobile node also includes the mobility information it would normally use in
Mobile IPv6 (e.g. an embedded Binding Update), in order to avoid the nedd
for additional round trips (e.g. as described in
[draft-le-aaa-diameter-mobileipv6-01.txt]).

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Feb 2002 00:06:56 +0100 (CET)

> If PANA is applied directly to Mobile IPv6 scenarios, a mobile node may have
> to first interact with the network according to PANA procedure and, only
> once the mobile node has been authenticated and authorized, the mobile node
> performs Mobile IPv6 procedures. This may lead to inefficiencies in terms of
> signaling load over the access link and in terms of round trips between the
> foreign domain and the home domain required by the mobile node

Frank,

I think the above performance requirement has some problems.

Suppose I agree with the need to be able to send the MIPv6 signalling
message(s) in the same packets as the AAA message(s) for performance reasons,
then it would seem to also be a valid requirement that the same
packets also be capable of carrying 
 - IMAP login and synchronization messages
 - http requests to get the latest news, stock quotes, etc
 - etc

Where would this lead us?

I think the problem with these types of optimizations that you are suggesting
is that it is a very slippery slope and we don't have real-world experience
saying that taking the first step down that slippery slope is worth the
effort (and risk of sliding down).

  Erik