Subject: [mobile-ip] Architectural Framework for LMM

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 04 Sep 2002 08:54:08 -0500

Folks,
  I volunteered to write a draft on an architectural framework for LMM. 
It has just been announced on the list.
  This document comes in between the requirements draft that Carl is 
editing and any solutions that will be adopted. Whenever a new protocol 
requires new entities in the network (certainly against the end-to-end 
principle of the Internet), WGs must define not only the requirements 
but also the architecture before any protocol selection is made. My 
draft aims at filling this gap on LMM.
  I'll be happy to entertain any questions and also to edit the document 
using any text provided, omments  made, new ideas emerged, etc.
  No contributions will go unnoticed, they will all be accounted for.

Regards,

-- 
Behcet

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 6 Sep 2002 18:55:06 +0900

Hi

I agree with Behcet that such a draft can be useful and here are some comments on his draft.

> 3.2 LMA Architecture
>
>  This architecture requires special care on the IP datagrams to be 
>  routed downstream.  The datagrams coming from the home agent 
>  tunneled to GLMA. GLMA decapsulates it and finds the home address of 
>  MN as the destination address. Using the binding cache entry GLMA 
>  reencapsulates the datagram to the corresponding lower care-of 
>  address. 

In above, it seems that GLMA uses 'home address' for data forwarding. It's better for 
GLMA to use 'RCOA'. When a packet arrives to LMA, destination address is RCOA. 
Searching binding cache with RCOA, LMA gets LCOA and encapsulate that packet 
to LCOA. In this manner, LMA doesn't have to do decapsulating and reencapsulating. 
(Only encapsulating once.) 

I wonder it is necessary for LMA to know MN's home address at all.

>  In Mobile IPv6, CNs send route optimized packets to MN.  Route 
>  optimized packets are processed by GLMA by for finding the home 
>  address of MN in the routing header and checking the regional 
>  binding cache entry in order to get the next LMA address to forward 
>  the packets to. GLMA then replaces the destination address with the 
>  downstream LMA address. LMAs downstream forward route optimized 
>  packets by modifying the destination address and this continues 
>  until MN receives the packet. 

In above, it seems that GLMA alters the destination address field of coming packets. It may 
cause some problem. It's better to use RCOA to get LCOA from binding cache.  

>  3.3 Domain change detection 
>  It is critical for the operation of any LMM protocol that MNs should 
>  be able to know if it is in its home domain (site) or in a visited 
>  domain. In neighbor discovery, routers advertise subnet prefixes. 
>  Subnet prefixes are obtained from site prefixes. Therefore routers 
>  can advertise site prefixes as part of neighbor discovery. This way 
>  MN can detect domain changes as described in [6]. 

I think what MN really has to know is not 'site' but 'available LMM lists and addresses.' MN 
only needs to know 1) the list of available LMAs and their addresses, 2) and their preference 
( hop counts) to select a suitable one among them. 

>  3.4 Route optimization 
>  
>  Problems associated with routing loops can be avoided as follows: 
>  Routers MUST be configured to send router advertisements with LMA 
>  extension on certain interfaces, e.g. avoiding AR to AR direct links. 
>  GLMA MUST be the only node in the domain to which CNs outside the 
>  domain send datagrams. 

It seems that above proposal makes GLMA single point of failure. 

>  5. Open Issues 
>    
>  Whether or not base MIPv4/v6 operation and LMM operation can be mixed 
>  once LMM start to be used. This is important for efficiency reasons. 
>  It may be advantageous for MN to communicate CNs in the same domain 
>  using the base protocol and to communicate CNs outside the domain 
>  using LMM. 

I agree this is important for Route Optimization. LMM gives extra cost of 'tunneling process 
and encapsulation header'. 

If a MN using LMM comes to receive large traffic from a CN without moving, it's more efficient 
to send LCOA to CN. It might be useful if MN can send RCOA or LCOA to CN according to its
own condition. 

According to Carl's LMM requirement draft, MN MUST NOT send LCOA outside of Local 
Coverage Area. Hence Route Optimization is impossible regardless of in what situation MN is.  

Even while using LMM, MN should be able to support 'Route Optimization' if it decides so. 

Best Regards

JinHyeock

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 06 Sep 2002 09:31:00 -0500

Hello JinHyeock,
  Thanks for your comments.
Regarding (for this email) domain change detection, IPv6 WG uses the 
term site, which I think corresponds to the domain we use in LMM. It 
seems that IPv6 WG has not yet resolved the site prefix issue. Reference 
[6] in my draft is an expired draft and reference 7 is the current one 
which tries to come up with a scoped address architecture for IPv6.
  I propose that the domain change detection be aligned with IPv6 WG 
work, i.e. with Reference 7.
 
  Regards,

>( hop counts) to select a suitable one among them. 
--behcet