Subject: [nemo] Re: Comments on ROProblem.doc (was: NEMO RO Problem)

From: "Fan Zhao" <[email-masked]>
Date: Wed, 6 Oct 2004 19:50:04 -0700 (PDT)

Dear Alex,

Thank you very much for your comments.
Please see the details in line.

Best regards,
fan
 
> Dear Fan, I've read the document and have comments on it.
> 
> Please submit it as an Internet Draft, should be easy.  If problems
> formatting, boilerplate, deadlines, whatever - I can help.
Thanks for your encouragements. I really appreciate your help.

> 
> The document is longish and tries to do many things.  Not only it looks
> at defining a NEMO problem in great detail, but it also offers goals for
> RO, Rx requirements and even RO performance evaluation metrics.
> 
I can narrow down the scope of draft based on the requirements of WG.

> > As it has been understood for a long time that the routing path in 
> > the Internet is asymmetric
> 
> The path taken by packets of the same session between two fixed
> communicating ends depends on the order of the src and dst fields.  Same
> end's outgoing and incoming packets may take different paths.  Also,
> packets of the same session and in the same direction, may take
> different paths, varying with time and network load.
> 
Exactly. 

> > More preciously, location
> 
> precisely
>
Yes, thanks.
 
> > Although in MIPv6 the Care-of-Address represents the location of 
> > attachment to the Internet, a single Care-of-Address is not 
> > sufficient any more to represent the location of VMN/MR in nested 
> > NEMO because it sometimes represents the point of attachment to the 
> > upper level of mobile network.
> 
> I don't understand this.  Why is it necessary to have more than one
> CoA  to represent the location of a VMN/MR in a nested NEMO?
> 
Except the case of root-MR, one CoA represents the location inside the
mobile network associated with MR. In the nested NEMO, MR/VMN/LFN (except
root-MR) is not accessible by using its CoA as the destination IP address
without being forwarded by HA. The “location” here is the position
relative to the Internet. 

> > The “optimal route” inside the NEMO network is formed by the decision
> >  of each MR along the outbound and inbound path
> 
> An "optimal route" is formed by route segments, not by "decisions" no?
>
In the outbound direction, MR just forwards the packets to its default
router. However in the inbound direction, based on the solution, MR
forwards the packets to the next hop. I do not quite understand the route
segments. Can you explain it more?
 
> > When MRi associates with MRj, it may choose MRj as the default router
> > 
> Yes ok, but I don't know where this leads to.  "Looping problems"?
>
What I want to say here is how the outbound path inside the nested 
NEMO is formed. 
 
> > The inbound path inside the nested NEMO may be different from the 
> > outbound path. However, since the route inside the NEMO network does
> >  not involve HA, the optimal route is based on the decision of each 
> > MR.
> 
> ...is based only on the decision of MR's, and not that of the remote 
HA's.
OK.

> > If the intersection of p1 and p2 is not empty, denoted by <MR_1,i1, 
> > MR_1,i2, …, MR_1,ik> = <MR_2,j1, MR_2,j2, …, MR_2,jk> where i1 < i2 <
> >  … < ik and j1 < j2 < … < jk.
> 
> If it is not empty then what?  Premature end?
>
Sorry about it. The correct sentence is “If the intersection of p1 and 
p2 is not empty, denoted by <MR_(1,i1), MR_(1,i2), …, MR_(1,ik)> = 
<MR_(2,j1), MR_(2,j2), …, MR_(2,jk)> where i1 < i2 < … < ik and 
j1 < j2 < … < jk, then ideally the optimal path between node1 and node2
 is <MR_(1,1), MR_(1,2), …, MR_(1,i1), MR_(2, j1-1), …, MR_(2,2), 
MR_(2,1)>.” Note that MR_(1,i1) is equal to MR_(2, j1).
 
> > Ideally the optimal path between node1 and node2 is <MR_1,1, MR_1,2,
> >  …, MR_1,i1, …, MR_2,2, MR_2,1>.
> 
> I do not see what the second indices represent (1,2,i1,2,1).  Maybe a
> graphical picture would be suggestive.
> 
> What is in plain English the optimal path?  The one that is the
> intersection of the two sets?
>
                |----MR2---MR3—LFN3  
                |
Root-MR---MR1---|
                |
                |----MR4---MR5-LFN5
In the nested NEMO like above, the optimal route between LFN3 and LFN5 
is MR3<->MR2<->MR1<->MR4<->MR5.

We probably can say the optimal route in this situation is the route
 turning around at the first MR that is aware of how to forward the data
 packets from one node to another without going out of the nested NEMO.

> > Worse than MIPv6, in nested NEMO network the packets are forwarded to
> >  multiple intermediate boxes
> 
> ... (the HA's)
>
OK.
 
> > As a TCP/UDP connection is identified by a 4-tuple <source IP 
> > address, source port, destination IP address, destination port>, in 
> > order to maintain the continuous session, the end point must use the 
> > same IP addresses during the session.
> 
> Not only for TCP connections are the stable IP addresses needed, but
> also for ICMP (ping).
>
That is right.
 
> > As IP address perfectly represents both identity and location of end
> >  host in the fixed network, we usually just put emphasis on one and 
> > sometimes even mix their meanings. However, in the mobile network 
> > environment, we need to represent the binding between identity and 
> > location that is what the binding between home- address and 
> > care-of-address does.
> 
> > Similar with MIPv4 and MIPv6, NEMO focuses on the solution in data 
> > plane rather than in the signaling plane
> 
> What's the data and signalling planes?  Is a BU signalling plane?
>
Thanks for asking. I should have more words about it.
In NEMO the routing decision is carried in each data packet, such as IP-
in-IP header. Signaling plane method mostly involves the specific 
signaling message to exchange the information and build up some state. It 
is possible to design a new NEMO signaling protocol for CN to acquire the 
binding information of mobile node and for HA to broadcast the binding 
information into the routing infrastructure. It does not require the 
special payload in the data packet instead of signaling messages. In some 
situation where a lot of data packets are sent and mobile node is fairly 
stable, signaling method is much efficient. However one drawback is that 
it requires more fundamental changes or a brand new protocol, which will 
be a big hurdle of deployment. (Considering that how ISPs are reluctant 
to upgrade to IPV6.)

Yes, BU is signaling message but we here categorize NEMO as a data plane 
method because it introduces large changes in the data packet.
 
> > a RO solution in data plane may qualify as a necessary step before
> 
> An RO solution would most probably use BU's, is this data or signalling?
> 
> > a nature extension
> 
> natural...
>
OK.
 
> > MR may choose to perform RO function just with its HA if the number 
> > of different CNs is large and all CNs scatter around the Internet
> 
> Is this equivalent to saying MR may choose to _not_ do RO?  I don't see
> how MR does RO only with its HA.
>
Yes, it becomes like in NEMO basic support. In other words, this is a 
tradeoff between simplicity and unoptimization. There are a lot of 
factors to influence MR’s decision to do RO or not. Depending on the 
solution, the better route than that in NEMO basic support is still 
possible because other MR can perform RO function. 

But so far it seems to me that NEMO basic support and RO solution are 
united under the term of CR (CA). HA is defined from the perspective of 
MR and is CR (CA) from the perspective of CN. I have not got time to 
match the already proposed RO solutions. But at least in RRH, the 
intermediate MR overwrites the source IP address with its own CoA can be 
thought as performing RO function with one CR that is HA of the child 
MR.  
 
> > 1.7.4 Security vs. optimal route In NEMO basic support, it is very 
> > possible that there pre-exists the security association between MR 
> > and HA, which helps resist the various attack. However in NMEO RO 
> > solution, as the MR-HA tunnel may not exist and there is no 
> > pre-existing security association between two entities from the 
> > different domains, it is more challenging to maintain the same 
> > security strength as in NEMO basic support.
> 
> An insecure RO solution for mobile hosts risks a CN and a MH.  An
> insecure RO solution for NEMO risks not only CN and MH but also the
> bunch of LFN's in the moving network.
> 
> It is difficult to do per-host RR tests (as currently RFC3775 does) for
> all the hosts within the MNP.
>
Yes, good points.
 
> Alex