Subject: [Int-area] draft-vidya-ip-mobility-multihoming-interactions-00 - Request for review and comments

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 15 Mar 2007 01:40:59 -0700

All,
We have submitted a draft describing the interactions and architectural
usage models involving various IP mobility and multihoming protocols
that have/are being specified here at the IETF. We'd appreciate review
and comments from the community. 

Thanks,
Vidya

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 16 Mar 2007 03:33:37 +0900

Hi Vidya,

Thanks for this draft. It must be hard work to puzzle out this
complicated problem:)

I have a few comments.

- There are well summarized protocol descriptions in section4.1. I
   wonder if you can list the mobility and multihoming
   characteristics of each protocol maybe with some tables.

   For example, MIP6 provides permanent addresses (i.e. HoA)
   reachability, but not always guarantee the path reachability like
   SHIM6 does.  An IPv6 node may not be aware of unreachability of a MN
   unless it explicitly exchanges a binding with the MN (RO).

   The comparison of protocols is useful to see the common functions.
   In future, some of the functions may be taken by each protocol and  
can be
   standardized as a universal spec. for all the protocols.
   The policy exchange issue raised by Jari on this ML is just one  
example.
   Alternatively, if two protocols do a same operation (ex. keep- 
alive beacon),
   one of protocol can skip the operation as an optimization.

- MIP has special meaning to the "home" network. The consideration of
   returning home is somehow missing in this document.
   For example, MN has two interfaces attached to home network and
   foreign network simultaneously. This configuration has been
   discussed in Monami6 and not solved yet.

- We will have presentation about effectiveness of MCoA for MIP6
    handover at MIPSHOP and MOBOPTS meeting.  You may be interested in
    our presentation.  In our experimentation, a MN registerd two CoA
    assigned to EvDo and another wireless system called iburst.  No
    packet drop was observed during the L3 handover (vertical
    handoff). We used L2 indication implemented as 802.21.  MCoA is not
    originally designed for handover, but it provides good performance
    in some scenarios (not horizontal,but only vertical).

- In section 6.2, you conclude that the netlmm cannot support
   multihoming.  However, even if a MN obtains different IP addresses
   (let's say HoA1, HoA2) from relative MAG (MAG1 and MAG2), the prefix
   received from MAGs must be same. Thus, the traffic sent with HoA1
   can be routed to the default router (MAG2), because MAG1 and MAG2
   are reachable default router for the home prefix.  MAG is always
   able to filter out such traffic, but I believe IPv6 conceptually
   allows this operation.

- SCTP is a transport protocol and is out of scope in this document,
   but it does support multihoming.
   I tested SCTP and MIP6 integration on real implementation last year.
   As a result, if a MN has multiple interfaces and has active CoAs on
   each interface, SCTP can optimize the handover latency of MIP6.
   In addition to this, one of good feature is that SCTP is capable of
   changing association end-points regardless of IPv4 and IPv6.
   You can change end point address from IPv4 to IPv6 and vice versa.
   This is very good future for  mobility, though DSMIP is being  
stardized in MIP6 WG.

regards,
ryuji

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 19 Mar 2007 06:41:24 -0700

Hi Ryuji,
Thanks for the comments.  

> -----Original Message-----
> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: Thursday, March 15, 2007 11:34 AM
> To: Narayanan, Vidya
> Cc: Internet Area
> Subject: Re: [Int-area] 
> draft-vidya-ip-mobility-multihoming-interactions-00 - Request 
> for review and comments
> 
> Hi Vidya,
> 
> Thanks for this draft. It must be hard work to puzzle out 
> this complicated problem:)
> 

We've written too many protocols here at the IETF :) 

>    characteristics of each protocol maybe with some tables.

Sounds like a good idea. We'll keep this in mind for the next revision. 

>    In future, some of the functions may be taken by each 
> protocol and can be
>    The policy exchange issue raised by Jari on this ML is 
> just one example.
>    Alternatively, if two protocols do a same operation (ex. 
> keep- alive beacon),

Yes, that is the intention and I agree a table improves readability. 

>    discussed in Monami6 and not solved yet.

Thanks for pointing this out. We will give some thought to the
implications of that. 

>     in some scenarios (not horizontal,but only vertical).

I can definitely see the  benefit of MCoA for vertical handoffs. I will
try and attend the presentation. I may have a conflict for MOBOPTS, in
which case, I'll talk to you offline. 

>    able to filter out such traffic, but I believe IPv6 conceptually

NetLMM is going with the prefix-per-MN model. Also, if the MN has
configured an address each on each interface, it would expect packets
coming in at each interface to have the address corresponding to that
interface. So, I'm not sure how we could send packets destined to one
interface to a MAG that would forward the packets to another interface
of the MN. Perhaps we can discuss this further this week. 

>    This is very good future for  mobility, though DSMIP is 
> being stardized in MIP6 WG.
> 

That is an interesting point. We need to define what the scope is for
this work and that's really the problem. To take on SCTP and more
protocols might mean that this document becomes too big to be useful and
that is a concern. We'll think about it some more to see how we can
handle this problem. 

Thanks,
Vidya

> > We have submitted a draft describing the interactions and 
> > architectural usage models involving various IP mobility and 
> > multihoming protocols that have/are being specified here at 
> the IETF. 
> > We'd appreciate review and comments from the community.
> >
> > Thanks,
> > Vidya
> >