Subject: [nemo] [NEMO, NetLMM] for comments : The Problem Statements for NEMO in NetLMM domains

From: "Joo-Chul Kevin Lee" <[email-masked]>
Date: Mon, 5 Mar 2007 12:43:52 +0900

Dear folks.

I submitted a new internet-draft "The Problem Statements for NEMO in NetLMM
domains".

I think if the home network of a mobile router belongs to the NetLMM domain
and the mobile router moves in the NetLMM domain the MAG can't handle
packets
sent by nodes attached to the mobile network.

because the MAG may not know how to handle the packets based on
the mobile network prefix allocated to the mobile network. (the MAG
knows how to handle packets based on the prefix allocated to the
mobile router)

Comments are welcomed for this draft.
http://www.ietf.org/internet-drafts/draft-lee-netlmm-nemo-ps-00.txt

Abstract:
   The NetLMM protocol provides local mobility to the mobile node
   without requiring any modification of mobile node.  The NetLMM domain
   provides this service by maintaining forwarding state for the mobile
   node's prefix.  In case that the mobile node is a mobile router in
   the NetLMM home network the NetLMM domain may not have the forwarding
state
   for the mobile network prefix, so it can't forward packets from nodes
   within the mobile network, that is to say, existing NetLMM protocols
   do not consider mobile routers enough.

Best regards,
J. Lee

---------- Forwarded message ----------
From: [email-masked] <[email-masked]>
Date: Mar 1, 2007 5:50 AM
Subject: I-D ACTION:draft-lee-netlmm-nemo-ps-00.txt
To: [email-masked]

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

        Title           : The Problem Statements for NEMO in NetLMM domains
        Author(s)       : D. Kaspar, J. Lee
        Filename        : draft-lee-netlmm-nemo-ps-00.txt
        Pages           : 13
        Date            : 2007-2-28

   The NetLMM protocol provides local mobility to the mobile node
   without requiring any modification of mobile node.  The NetLMM domain
   provides this service by maintaining forwarding state for the mobile
   node's prefix.  In case that the mobile node is a mobile router in
   the home network the NetLMM domain may not have the forwarding state
   for the mobile network prefix, so it can't forward packets from nodes
   within the mobile network, that is to say, existing NetLMM protocols
   do not consider mobile routers enough.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-netlmm-nemo-ps-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-lee-netlmm-nemo-ps-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-lee-netlmm-nemo-ps-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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
Joo-Chul Kevin Lee (ETRI)
Electronics and Telecommunications Research Institute.
161 Kajong-dong, Yusong-Gu, TAEJON, 305-350, KOREA
E-mail : [email-masked]/[email-masked] Tel : +82-042-860-1021
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Mar 2007 11:46:56 +0100

Joo-Chul, here are preliminary comments.  I think the Problem Statement 
NEMO for NETLMM is definitely worth the effort.

Joo-Chul Kevin Lee wrote:
> Dear folks.
> 
> I submitted a new internet-draft "The Problem Statements for NEMO in
>  NetLMM domains".
> 
> I think if the home network of a mobile router belongs to the NetLMM
> domain and the mobile router moves in the NetLMM domain the MAG can't
> handle packets sent by nodes attached to the mobile network.
> 
> because the MAG may not know how to handle the packets based on the
> mobile network prefix allocated to the mobile network. (the MAG knows
> how to handle packets based on the prefix allocated to the mobile
> router)

I think that is right.  If the PMA (HA) and MAG (AR) use Proxy Mobile 
IPv6, as in draft-sgundave, then I think there are issues about how the 
CN-to-LFN packets are encapsulated.

Normally, a MIPv6 HA would encapsulate a packet once towards MR.  With 
Proxy MIP6 there would be a need for double encapsulation, once towards 
AR and once towards MR.

this NEMO NETLMM ps draft says:
>    [netlmm-goals] describes the goals (or requirements) for NetLMM.
>    Section 3.7 "Support for Unmodified Mobile Nodes (Goal #7)" of
>    [netlmm-goals] says that the NetLMM solution should be able to
>    support any mobile node without requiring localized mobility
>    management software on the mobile node.  In this context, the mobile
>    node can be an ordinary host or a node that has some kind of global
>    mobility protocol.

Can we say that the mobile node can be a Mobile Router that runs NEMOv6?

this NEMO NETLMM ps draft says:
>   The NetLMM protocol has two principal functional entities, which are
>    called MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor).
>    The LMA maintains a collection of routes for individual mobile nodes
>    and it will be used while the mobile node moves around in the NetLMM
>    domain.  The route information that the LMA keeps is, however, only
>    for the packets based on the subnet prefix allocated to the mobile
>    node itself.  Thus, if a mobile router joins the NetLMM domain as a
>    home network and moves around among MAGs that belong to the NetLMM
>    domain a MAG may not know how to handle the packets from nodes
>    attached to the mobile router because there is no way to inform the
>    MAG and LMA of the mobile network prefix.

Can we refine the problem.  And try to illustrate a packet from CN to 
LFN and what are the needed encapsulations.

Can we talk about ingress filtering.  What happens if a MR forwards a 
packet from its LFN towards CN through the AR?  The src address of that 
packet is LFN's address.  Is that packet ingress-filtered by AR?  Is 
there a risk for that?

Alex

> <http://www.ietf.org/internet-drafts/draft-lee-netlmm-nemo-ps-00.txt>
> 
> 
> 
> Abstract: The NetLMM protocol provides local mobility to the mobile
> node without requiring any modification of mobile node.  The NetLMM
> domain provides this service by maintaining forwarding state for the
> mobile node's prefix.  In case that the mobile node is a mobile
> router in the NetLMM home network the NetLMM domain may not have the
> forwarding state for the mobile network prefix, so it can't forward
> packets from nodes within the mobile network, that is to say,
> existing NetLMM protocols do not consider mobile routers enough.
> 
> Best regards, J. Lee
> 
> ---------- Forwarded message ---------- From:
> [email-masked] <mailto:[email-masked]>* 
> <[email-masked] <mailto:[email-masked]>> Date:
> Mar 1, 2007 5:50 AM Subject: I-D ACTION:
> draft-lee-netlmm-nemo-ps-00.txt To: [email-masked]
> <mailto:[email-masked]>
> 
> Author(s)       : D. Kaspar, J. Lee Filename        :
> draft-lee-netlmm-nemo-ps-00.txt Pages           : 13 Date
> : 2007-2-28
> 
> <http://www.ietf.org/internet-drafts/draft-lee-netlmm-nemo-ps-00.txt>
> 
> 
> [email-masked] <mailto:[email-masked]>
>  with the word unsubscribe in the body of the message. You can also
> visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change
> your subscription settings.
> 
> logging in, type "cd internet-drafts" and then "get
> draft-lee-netlmm-nemo-ps-00.txt".
> 
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Send a message to: [email-masked] <mailto:[email-masked]>. In
> the body type: "FILE
> /internet-drafts/draft-lee-netlmm-nemo-ps-00.txt".
> 
> NOTE:   The mail server at ietf.org <http://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.
> 
> _______________________________________________ I-D-Announce mailing
> list [email-masked] <mailto:[email-masked]> 
> Joo-Chul Kevin Lee (ETRI) Electronics and Telecommunications Research
> Institute. 161 Kajong-dong, Yusong-Gu, TAEJON, 305-350, KOREA E-mail
> : [email-masked]/[email-masked] 
> <http://[email-masked]/[email-masked]> Tel : +82-042-860-1021 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________