Subject: Re: [MOBILE-IP] draft agenda (about Homeless draft)

From: cnyap <[email-masked]>
Date: Fri, 1 Dec 2000 23:06:44 -0000

Hi all,

About 6 months ago, IIP is being rejected in Mobile Working Group,
as "IIP concept is out of the scope of the working group".
Here goes:

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 06, 2000 1:34 PM
Subject: RE: Timeslot requests

>
> Hi,
>
> I have a couple of concerns regarding your request for
> timeslots at the Mobile IP WG sessions at IETF48.
>
> 1. The normal time allocated for any single topic for discussion
>    is about 10~20 minutes. You had asked for a total of an hour
>    for presenting two concepts (IIP and MVPN).
>
> 2. RFC2002, 2002bis and, Mobile IP for IPV6 are what has been well
>    accepted as the mechanisms for IP mobility. If you look at the
>    scope of the WG charter what we are essentially seeking is specific
>    solutions to make the MIP protocol suitable for deployment on a
>    large scale in the real world. What we are not seeking is a new
>    solution for doing mobility. As you mentioned IIP is yet another
>    solution for achieving IP mobility and this is outside the scope
>    of the charter.
>
>    However I do not mean to discourage the work that is being done in IIP.
>    Because of the limited time that we have at the meetings (IETF48) we
>    will be prioritizing the presentation topics based on the scope of the
>    charter. At the present time we do not see a great deal of interest in
>    IIP. If there is a sufficient amount of interest in IIP, then we can
>    possibly include it on the agenda, but at the present time I doubt
that.
>    It is up to you to generate interest in the IIP concept.
>
> The MVPN concept is something that is more applicable to the Mobile IP
> WG. Hence we will try and schedule a 10~15  minute slot for MVPN.
> We will be announcing the first draft agenda of the Mobile IP WG schedule
> next week.
>
> If you have any questions or concerns, please do not hesitate to contact
> me or Phil.
>
> Regards,
>
> -Basavaraj
>

last week, I was told that there is another draft has "IIP concept"
and it is accepted to have a time slot in IETF meeting.
Here goes:

----- Original Message -----
From: "Pekka Nikander" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, November 21, 2000 6:07 AM
Subject: Possibly joining draft-cnyap-iip-01.txt and
draft-nikander-mobileip-homelessv6-00.txt

> We recently published the initial results of our work considering
> Mobile IPv6 in ad hoc networks as an internet draft,
>
http://www.ietf.org/internet-drafts/draft-nikander-mobileip-homelessv6-00.tx
t
>
> Now I have been looking at related work, and it seems to me that
> your draft draft-cnyap-iip-01.txt is more or less based on the
> same fundamental ideas, but attempts to solve the problem in
> a different way.
>
> Now, my question is whether you are pursuing your work further,
> and if so, would you see any benefits if we attempt to join
> forces?
>
> Yours,
>
> --Pekka Nikander
>   Ericsson Research Nomadiclab

What is scope of the charter now?

Cheers
Chern Nam Yap

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 4 Dec 2000 23:34:17 +0200

Chern Yan Nap has raised the point whether our "Homeless Mobile IPv6"
draft is appropriate to be considered at the Mobile IP WG or not.
Based on that both their IIP draft and our Homeless draft try to
solve some of the same problems, though through a slightly different
angle, I try to highlight the differences between the drafts.
My aim is to keep this message solely on technical issues.

APPARENT DIFFERENCES

First, the superficial, immediately apparent differences:

   - Homeless is suggested to be experimental only (at least at
     this stage), IIP does not mention whether it aims to be
     on the standards track or not.

   - Homeless proposes an backward compatible extension to MIPv6.
     IIP proposes a completely new protocol.

   - Homeless is proposed for IPv6 only, IIP for both IPv4 and IPv6.
F
   - Homeless is _primarily_ targeted for infrastructureless operations
     where there may not be any home agents, home location registers,
     foreign agents, or visitor location registers.  On the other hand,
     it can utilize MIP home agents, Dynamic DNS, SIP, or other means
     as the initial discovery protocol.  And it proposes that home
     agents are used to solve the double jump problem.

     IIP, on the other hand, still relies more-or-less centralized
     components, the base home register (BHR) and temporary visit
     register (TVR).  However, it _does_ take the proposition that a TRV
     can be "upgraded" to act as a new BHR.

   - Homeless does not _need_ any new wire protocol, even though it
     does propose a couple new MIPv6 suboptions.  IIP proposes that
     signalling is performed out-of-band, using UDP packets.

KERNEL DATA STRUCTURE DIFFERENCES

The deeper, and more interesting difference lies in the proposed
kernel data structures.  I'll first consider IIP, and then describe
both what is proposed in Homeless, and the thinking behind it.

The IIP Binding Cache is based on

    <home/visit address, co-located address>

pairs.  The home/visit address is always used as a key to
search the cache when sending packets.  IIP specifies that
packets may be sent using the co-located address as the source
address, but it is not very specific how the receiver would
find the right socket.  !The sockets contain, as usual,
the home/visit addresses.

In the Homeless draft, the Binding Cache is replaced with what
we call "the Host Cache".  In a way, the Host cache is a
generalized data structure that more or less combines the
MIPv6 Binding Cache and Binding Update List into a single,
fully symmetric data structure.  To make this point more
apprarent, let me start from the standard MIPv6 Binding Cache.
Let's consider three Mobile Nodes, all communicating with
each other.  Furthermore, MN2 has two interfaces and it
currently uses different interface to talk to MN2 and to MN3,
and therefore it has two different COA1, MN1 COA1 and MN1 COA2.
The Binding Cache can be depicted as follows.

    +---------------------------+      +----------------------------+
    ! MN1                       !      ! MN2                        !
    !                           !      !                            !
    !sock <-> MN2 HA -> MN2 COA !      !sock <-> MN1 HA -> MN1 COA1 !
    !                           !      !                            !
    !sock <-> MN3 HA -> MN3 COA !      !sock <-> MN3 HA -> MN3 COA  !
    !                           !      !                            !
    +---------------------------+      +----------------------------+

    +---------------------------+
    ! MN3                       !
    !                           !
    !sock <-> MN1 HA -> MN1 COA2!
    !                           !
    !sock <-> MN2 HA -> MN2 COA !
    !                           !
    +---------------------------+

As a revision of this, let us now consider a scheme where
the Binding Cache could contain several COAs for a single host.
The data structures would look like the following.

    +---------------------------+       +----------------------------+
    ! MN1                       !       ! MN2                        !
    !                           !       !                            !
    !sock <-> MN2 HA -> MN2 COA !       !sock <-> MN1 HA -> MN1 COA1 !
    !                           !       !                   MN1 COA2 !
    !sock <-> MN3 HA -> MN3 COA !       !sock <-> MN3 HA -> MN3 COA  !
    !                           !       !                            !
    +---------------------------+       +----------------------------+

    +---------------------------+
    ! MN3                       !
    !                           !
    !sock <-> MN1 HA -> MN1 COA1!
    !                   MN1 COA2!
    !sock <-> MN2 HA -> MN2 COA !
    !                           !
    +---------------------------+

The next step is the realization that if we change the algorithm
that finds the right socket on the receiving end to look up
the socket by using the COAs instead of the HA, we can get rid of
the Home Address altogether.

    +---------------------------+       +---------------------------+
    ! MN1                       !       ! MN2                       !
    !                           !       !                           !
    ! sock <----------> MN2 COA !       ! sock <---------> MN1 COA1 !
    !                           !       !                  MN1 COA2 !
    ! sock <----------> MN3 COA !       ! sock <---------> MN3 COA  !
    !                           !       !                           !
    +---------------------------+       +---------------------------+

    +---------------------------+
    ! MN3                       !
    !                           !
    ! sock <---------> MN1 COA1 !
    !                  MN1 COA2 !
    ! sock <---------> MN2 COA  !
    !                           !
    +---------------------------+

Now we have came to the Homeless draft's Host Cache.  The only
problem is that programs that do not adhere with RFC 1958 will break...
(But we have some preliminary ideas how to fix it).

SIMILARITIES

Now, by my second reading of the IIP draft I must reconsider
my proposal to the IIP draft about the possible similarities.
What led me to believe that the drafts have similaries, are
the following features:

  - In the introduction, IIP claims to support multi-homed
    operations.  However, the draft does not specify how,
    though I think I can see how it could do it.
    (Homeless does support multi-homed operations, and
     clearly specifies how.)

  - And probably most importantly, IIP leaves the "orthodox"
    approarch that each MN has a home address; instead, home
    addresses are percieved as more or less temporary ones,
    and used for temporary packet forwarding to a large degree.

The second point is what definitely makes some of the attitude
behind the drafts similar - hence my view of "trying to solve
some of the same problems".  Othet than that, I don't
think that the solutions are necessarily that similar at all.

--Pekka Nikander