Subject: RE: Usage scenarios

From: <[email-masked]>
Date: Tue, 12 Feb 2002 10:26:21 -0600

Hi Alper,

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

We do not ask PANA to understand the MIP protocol but we would like to have the capability to encapsulate the MIP information such as the binding update, in the same time the user sends its credentials. Thus we do not have to execute many round trip messages between the foreign and the home domains.

Franck

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 12 Feb 2002 17:39:59 +0100

> * PANA for Diameter Mobile IPv6 Application

=> I don't see why we should have DIAMETER MIPv6
in the title.

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

=> So far I agree that this is a good use of PANA.

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

=> Agreed.

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

=> But these links work in this way, today. First 
authentication, then any specific signalling 
is sent after.

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

=> I disagree with this requirement. The integration 
of AAA and MIP is ana architectural mistake and 
we shouldn't allow this for MIPv6. 
The two functions are completely independant, reducing
the initial signalling, especially when there 
is obviously no ongoing connections is not a strong
motivation for integrating protocols.

Hesham