Subject: Re: [Mip4] New Version Notification for draft-gundavelli-mip4-multiple-tunnel-support-00 (fwd)

From: George Tsirtsis <[email-masked]>
Date: Wed, 14 Jan 2009 10:54:58 +0000

Hi Sri,

I just had a look at the draft.
Since I was not in the last IETF meeting could you summarize what the
plan is with this draft? Is this something the WG considers taking up?

If yes, I think it would be useful to spell out what the scope of this
work is in comparison to the equivalent work in the MEXT (i.e., MCoA
and Flow Movement). I did this early on for DSMIPv4 and it helped
things significantly.

BTW, I am not sure I like the whole notion of 'Interface bandwidth".
This is something notoriously difficult to set right and make sense
of, especially on wireless links. Instead the rough link priority
adopted in MIPv6-MCoA is easier to deal with and should satisfy your
needs, without turning this into a QoS protocol...which would be a
nightmare..

Regards
George

On Wed, Dec 10, 2008 at 3:25 AM, Sri Gundavelli <[email-masked]> wrote:
>
> Please comment on this work item. We presented this
> at Minneapolis.
>
>
> Sri
>
>
> ---------- Forwarded message ----------
> Date: Mon,  8 Dec 2008 00:51:42 -0800 (PST)
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for
>    draft-gundavelli-mip4-multiple-tunnel-support-00
>
>
> A new version of I-D, draft-gundavelli-mip4-multiple-tunnel-support-00.txt
> has been successfuly submitted by Sri Gundavelli and posted to the IETF
> repository.
>
> Filename:        draft-gundavelli-mip4-multiple-tunnel-support
> Revision:        00
> Title:           Multiple Tunnel Support for Mobile IPv4
> Creation_date:   2008-12-08
> WG ID:           Independent Submission
> Number_of_pages: 17
>
> Abstract:
> This document defines extensions to Mobile IPv4 protocol for allowing
> a mobile node or a mobile router with multiple interfaces to register
> a care-of address for each of the available interfaces and to
> simultaneously establish multiple Mobile IP tunnels to the home
> agent, each through a different interface path.  This capability is
> required for enabling a mobile node to utilize all the available
> wireless access links and build an higher aggregated data pipe to the
> home agent by setting the home address reachability over all of those
> tunnel paths.
>
>
>
> The IETF Secretariat.
>
>
> --
> Mip4 mailing list: [email-masked]
>   Web interface: https://www.ietf.org/mailman/listinfo/mip4
>    Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>
--
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 19 Jan 2009 10:31:45 -0800 (PST)

Hi George,

Sorry for the late reply. Please see inline.

> plan is with this draft? Is this something the WG considers taking up?

I hope so. That's the plan and there is interest. We need this for
our mobile router deployments.

> and Flow Movement). I did this early on for DSMIPv4 and it helped

Ok. The problem statement between MCOA4 and MCOA6 is similar. The
ability for the mobile to setup multiple tunnels to the home agent
through different interfaces, is largely same. The presence of foreign
agent/types of registrations, NAT presence introduces some differences
and issues.

> needs, without turning this into a QoS protocol...which would be a

The draft is exposing the information about the interface through which
a mobile node is attached and marks the binding associated with this
attach. The interface type (WiMAX, WiFI, LTE ..etc) will definetly provide
a sufficient hint for the home agent. In some radio environments, if
the link bandwidth is predictable, it can certainly expose the same to
the home agent. I agree with you that its not always predictable, hence
it is optional, making it useful only when present. The exposed parameters
are sufficient for the tunnel peers to build efficient traffic policies
and leverage the links in a much more efficient manner.

Sri