Subject: RE: [nemo] Route Optimization in Nemo

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Oct 2002 09:17:33 -0000

> -----Original Message-----
> From: Takeshi TANAKA [mailto:[email-masked]] 
> Sent: lundi 28 octobre 2002 08:10
> To: Pascal Thubert (pthubert); IETF NEMO
> Subject: Re: [nemo] Route Optimization in Nemo
> 
> 
> Hi Pascal, 
> 
> We are also interested in the RO problem of NEMO especially 
> in nested case.  We see that nested mobile nodes is 
> inevitable in a practical world deployment scenario.
> 
> First of, some comments on your RO-Taxonomy draft:
> 
> > 2.1 Nested tunnels optimization
> > Such a solution introduces the following problems:
> > "Pinball" routing ...
> > Packet size ...
> 
> I think the problem of nested tunnels can be further broken 
> down into: "pinball" routing
> - HA/MR processing resources consumption
> - increased latency
> increased in packet size
> - wireless link bandwidth consumption
> - network resource consumption
> - more packet fragmentation(by each termination)
> 
Sure ! Depending on the environment and the implementation, the gating
factor may not be the same in all cases.
> 
> > The potential approaches for avoiding the nesting of 
> tunnels include: 
> > Route Aggregation ... Surrogate ...
> > Internal Routing and gateway ...
> > RRH ...
> Routing header can be used to avoid problems you listed, but 
> I think naming the paragraph RRH is putting adding 
> presumptions on the method of constructing the Routing 
> Header, since there could be other method to collect 
> information needed to construct routing header.
> 

Agreed, I'll fix that. RRH could be listed as an example but it's not a
category. I'm not sure how to describe the category, though, and I
expect more discussion when I do, since I mean to differentiate from a
MANET based source routing. What do you think of "standard based source
routing"? Note that the RRH draft presents RRH as an IPv6 header, not a
MIP thing. Then the draft shows how that header could be used by MIP,
though the usage is not restricted to MIP. 

> 
> > 3. MR-to-CN
> >  ...
> >  accept the risk.  If not, the optimization may be limited to  
> > triangular routing MR->CN->HA->MR. ...
> I think packet delivery path in this case will not be a 
> triangular routing(MR->CN->HA->MR), but "dog-leg" routing 
> (MR->HA->CN, CN->HA->MR).
> 

Not sure: The MR can encapsulate packets to the CN instead of the home
agent, potentially at the expense of IPSec. The CN has to support the
encapsulation and it may accept to forward the inner packets even if it
does not trust the MR enough to optimize the reverse direction. This may
defeat ingress filtering, but then it's a matter of policy. Be prepared
for a long debate :)

> 
> > 6. Conclusion
> > ...MIPv6 seems to be...more difficult to probide a Nemo 
> solution with 
> > backward compatibility, since: ...
> > 2) The RR test has no negotiable option and is not open for 
> extension,
> What does this sentence mean?
> In MIPv6 draft #18, each messages in RR test can contain some 
> mobility option field.  These option fields can be used to 
> carry other information. In addition, we can modify the way 
> each cookie is generated at CN side if necessary.
> 

OK, I'm being crytic again. I was talking about the RR and CN as
described by MIP. Options give you additional information but there's no
such thing as a completion code or negotiation in RR test. As you
mention, we will have to modify the CN again. The MIP CN is already a
burden, I wonder how difficult it will be to add our stuff into it.  We
could have coped with a simple generic negociation like triangular
yes-no, CareOf yes-no... Which could have been beneficial to MIP as
well.

I tried a few things on the MIP list. Please see 'CoT' and the 'HAO, BE
processing' discussions in July (some appended). I understand it's not a
priority and they want to close the debate, our cost. Same for the HaO,
we would need a CN change to make it multihop. At that point, I believe
that a RH is better ;)

> For your "call for debate" in laying down the RO 
> requirements, it is a good idea.  We will try to write down 
> something concrete for futher discussion in the mailing list.
> 

:)

> On a side note, we think there wont be any time slots for 
> discussion about RO solutions in the upcoming IETF meeting, 
> but if we can laid down some set of requirements for RO, 
> perhaps we can request for a time slot to discuss the problem 
> scope of RO?
> 

Agreed, and it's up to the chairmen to do the first thing first. There's
this debate about the requirements for the basic Nemo that will take a
long time in the Agenda. I believe that understanding RO is important
for the design of Basic, but I agree it's not necessarily needed to
establish the requirements. 

Yet, since some of us are industrials, we can't wait 2 years to have
everything done by the book. If Nemo is too slow, I'm sure companies
will come up with proprietary solutions for the interim, at a cost; so
it's beneficial to start this thread already, even if it means a very
short entry in the Agenda, and offline meetings in Atlanta.

Will you be there?

> ------------
> Takeshi

Subject: [mobile-ip] CoT
From: "Pascal Thubert" <[email-masked]>
To: <[email-masked]>
Date: Mon, 1 Jul 2002 09:47:18 -0000

I understand that the RR test is meant for the CN to ensure that the remote
mobile node is actually who he says, at least as far as the Home Agent knows. So
a CN sends a secret via Home, and hopefully the REAL guy gets it. Then the REAL
guy could talk to the CN, using that secret to authenticate himself. Now, what
about the CareOf Test? Seems that is it mostly used to check that the path to
the MN works. To me, it looks like the first beat of a heartbeat more than a
HELLO; we're just missing the next beats to detect when the path becomes
unusable, in which case the home route should be used. Anyway, what bothers me
is that the CareOf address is part of the secret that comes with that test. When
the MN moves, a new test is needed before the BU, correct?

In general, I do not necessarily see the value of that secret in the CoT for
MIP. If the guy at the CoA has the secret from the HoT, then it's him, ain't it?

This line of thinking would end up with a flow like:

1) HoT once
2) BU, based on HoT only, when CoA change
3) CoT as a heartbeat

What do you think?

Pascal

Subject: RE: [mobile-ip] Re: summary of HAO, BE processing discussion
From: "Pascal Thubert" <[email-masked]>
To: Keiichi SHIMA / "?Oc^e <[email-masked]>, <[email-masked]>
Cc: "mat (mailer list)" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 18 Jul 2002 16:00:05 -0000

I think I've been a little cryptic:

Some devices such as a fridge may be happy to have a minimum set of
requirements for IPv6. Other devices such as clustered servers may not
be able to maintain a BCE at all because the cluster IP address is
shared among all the members of the cluster -- unless they perform a new
protocol to distribute the BCEs-. Furthermore, if the cluster uses a
dispatcher that is not on the return path, then the dispatcher cannot
provide the MIP termination, either. However, if that same dispatcher
terminates an IPSEC tunnel, or by other means to be defined later such
as piggy backing, it could be possible to trust a Home address option
and perform triangular routing. 

Using a Binding Cache as opposed to piggy backing the BU with each
packet assumes that memory scales better than CPU. This seems a
reasonable approach, so does delaying the support of piggybacking. But
still, we must allow for the case where this trade-off does not apply.
Say the dispatcher I just mentioned has a hardware accelerated crypto
engine; say it can cache some recent computations in a LRU fashion; say
it has limited memory capabilities to keep many BCEs long term; and say
it needs to serve requests for a huge amount of unrelated users; in that
case, the trade-off is the wrong choice, and triangular may be the best
can do, unless the client sources its requests with its CoA, which leads
to more open issues. MUSTing a Binding Cache in IPv6 outlaws this
configuration de facto. 

If we agree that there can be several levels of support by the CN for
RO, then we could define what the behaviour is for each level and how to
negotiate that between the CN and the MN. My suggestion was to do that
negotiation at RR test time so that no bind support would be necessary
unless both parties agree upon bi-directional route optimization.

A way to perform that negotiation is to give a meaning to the response
to HoTi and CoTi. This may be achieved by adding negative Return Code to
Hot Cot, and mostly by accepting an ICMP error as a 'no' response.

So 'No' to Both HoTi and CoTi means no bind updates, and usage of the
bidir MN-HA tunnel, which ensures compatibility with minimum and legacy
stacks, as per the draft
'Yes' to both HoTi and CoTi means let's go with the bind update, as per
the draft
'Yes' to CoTi only means support for Home Address option but not for
Bind Cache
'Yes' to HoTi only does not make sense to me at the moment ???

This is not exactly the way the draft presents things, mostly for the
triangular part. Also, the draft is heavily biased (e.g. 8.1) in such a
way as to let the reader believe that MIP could not work without support
of the Home Address option by all nodes, "since otherwise communications
may be impossible". I believe that this is misleading, and that we
should rather explain the different scenarios and pro/cons of each level
of support by the CN. I believe we          ShOuLd at least replace all
occurrences of MUST by SHOULD in 8.1. 

Does that make sense?

Pascal

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Keiichi SHIMA /
"?OEc^e
Sent: Thursday, July 18, 2002 7:19 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [mobile-ip] Re: summary of HAO, BE processing discussion

Let me add one thing.

From: Jari Arkko <[email-masked]>

> * IPv6 WG has in the past accepted the HAO as a mandatory
>    feature for all IPv6 nodes. Arguments have been made,
>    however, that the processing of the HAO has been changed
>    and the situation may now be different.

In addition, the current draft requires not only HAO but also BE.
This means all IPv6 nodes must implement a new extention header
(mobility header).

I never say that such a mechanism is bad at all.  It is good of
course.  But from the view of the fast deployment of both IPv6 and
Mobile IPv6, I personally think it better not to require additional
requirements...  This is not the view of the protocol designer,
though.

I'm probablly a bad designer and a bad scientist.  I just want a real
IPv6 and a Mobile IPv6...

Best Regards,

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Takeshi TANAKA <[email-masked]>
Date: Wed, 30 Oct 2002 12:27:04 +0900

Hi Pascal,

Sorry for late reply,

At Mon, 28 Oct 2002 09:17:33 -0000 

> though the usage is not restricted to MIP. 
We thought that category is for a solution that uses Routing Header
that can contain multiple addresses to avoid a path that goes through all HAs,
and yes I agree to call that category as "standard based source routing".

> defeat ingress filtering, but then it's a matter of policy. Be prepared
I misunderstood that "If not, the optimization..." means 
"If we do not modify CN behavior, the optimization", now understand.

> short entry in the Agenda, and offline meetings in Atlanta.
Yes, will be there with Chan Wah.

-----------------------------------------------
 Takeshi TANAKA
 Wireless Solution Laboratories, Panasonic
 e-mail: [email-masked]
 phone: +81-468-40-5494 / fax: +81-468-40-5183
-----------------------------------------------