Subject: [mobile-ip] I-D ACTION:draft-sarikaya-mobileip-lmmframework-00.txt

From: [email-masked]
Date: Wed, 04 Sep 2002 07:55:46 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Architectural Framework for Localized Mobility 
                          Management
	Author(s)	: B. Sarikaya
	Filename	: draft-sarikaya-mobileip-lmmframework-00.txt
	Pages		: 10
	Date		: 2002-9-3
	
This document defines an architectural framework for localized 
mobility management (LMM) in Mobile IPv4 and Mobile IPv6. LMM 
requires new architectural entities to be added to the architectures 
of Mobile IPv4 and v6. Also the availability of localized mobility 
management must be advertised by the localized mobility agents. The 
document defines these entities and their interactions with the 
existing entities and changes required to router/agent advertisements. 
The document also identifies a number of open issues whose resolution 
is crucial to the standardization of LMM protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-lmmframework-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sarikaya-mobileip-lmmframework-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sarikaya-mobileip-lmmframework-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 6 Sep 2002 18:40:47 +0900

Hello B. Sarikaya

As the author of the I-D ([8] in your draft) about the routing optimization in LMM, 
I want to write some comments on your draft.

In your draft...

> 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 HMIPv6, a MAP does not have any information about HoA of MN.
In yout draft, you say that the GLMA finds the HoA of MN in the routing 
header, and checks the binding cache. It is conflict with the scheme of 
HMIPv6. Although the HMIPv6 is one of examples of LMM, I think that 
the MAP (or GLMA) need not know the HoA of MN. 
RCoA and LCoA have 1:1 mapping relationship, and the MAP (or GLMA)
is sufficient to only know the binding between RCoA and LCoA.
    
Another... you say that GLMA replaces the destination address with the 
downstream LMA address. That is not possible, since IPv6 packets generally 
have AH. The replacement of desitination address is not allowable.

> GLMA MUST be the only node in the domain to which CNs outside the 
> domain send datagrams.

In large localized domain, only one GLMA is not sufficient to cover so many 
MNs. GLMA must receive all BU from MNs, process them, send BAck 
to the MNs, and process all packets destined for the MNs(tunneling)
LMA's loads may be more heavy than HA's load
, since HA's loads are alleviated with the route optimization of MIPv6.
Maybe, the price of LMA is higher than the one of HA.

.....

Let me add some my insistence.
I sugget that LMM should support the real routing optimization 
(send LCoA to CNs ouside MN's domain), that is, 
an MN and a CN can communicate directly without LMA's tunneling.
The RO can alleviate the intermediate mobility agent's heavy loads 
as well as optimize data-packet routing.

Youn-Hee Han.

Samsung AIT.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Sep 2002 10:25:10 -0500

Hello Youn-Hee,
Presently the draft is being revised and version 1 is going to be issued
soon in which some of your comments will be incorporated.
Specific comments in-line.

>have AH. The replacement of desitination address is not allowable.
You are suggesting a different packet processing algorithm, so I am
going to consider this method to be mentioned as well in the draft.

>Maybe, the price of LMA is higher than the one of HA.
Single points of failure is a known problem and there are ways of
dealing with it.

>as well as optimize data-packet routing.
RO yes for CN to RCoA but not CN to LCoA. After the route optimized
packet arrives in the domain, LMM takes over. This is fundamental to
LMM. Hope you agree with this.

>Samsung AIT.
--behcet