[Netext] next steps for netext

Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan) Sat, 04 April 2009 01:41 UTC

From: "Mohana.Jeyatharan at sg.panasonic.com"
Date: Sat, 04 Apr 2009 09:41:09 +0800
Subject: [Netext] next steps for netext
In-Reply-To: <3d57679a0904030749r270610fdge147b7aa5e19af88@mail.gmail.com>
References: <49D5BB60.4090407@piuha.net> <3d57679a0904030749r270610fdge147b7aa5e19af88@mail.gmail.com>
Message-ID: <5F09D220B62F79418461A978CA0921BD033F82A8@pslexc01.psl.local>

Hi Rajeev,

RFC 5213 already supports intertechnology handoffs.
As you mentioned, perhaps we could document some host implementations that needs to be done
and look into further optimizations and extensions we have to perform to insert
Multihoming cabilities and vertical handoff optimizations for PMIPv6. 

When operators deploy PMIPv6 they would probably need such extensions and why should we
limit this capability for PMIPv6? We need to start some work in IETF here as well.

BR,
Mohana


> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Rajeev Koodli
> Sent: Friday, April 03, 2009 10:50 PM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] next steps for netext
> 
> Hi Jari,
> 
> thanks for the start on the charter.
> 
> Regarding multiple interface support and inter-access 
> handovers: the primary issue is the ability to use the same 
> address across interfaces. This can be considered a 
> functionality that needs to be turned on, e.g., through the 
> use of virtual interfaces. This is not a "host change" per 
> se, at least we can be clear about it in the charter. As 
> Ryuji pointed out, IPv6 is (still?) disabled by default on 
> Windows OS. Does enabling it constitute a "host change"?
> 
> I think we need to consider problems which need to be solved 
> (in addition to the good debate which may sometime turn here 
> and there :-) ).
> 
> Regards,
> 
> -Rajeev
> 
> 
> On Fri, Apr 3, 2009 at 12:31 AM, Jari Arkko 
> <jari.arkko at piuha.net> wrote:
> > In the meeting we ended up having a big argument about the 
> multihoming 
> > and handover parts. I don't know what to do about that yet, but I 
> > would still like to suggest that the other parts should 
> move forward. 
> > I edited the charter from the web site. Comments appreciated:
> >
> > -------
> >
> > Network-Based Mobility Extensions (NETEXT)
> >
> > Last Modified: 2009-04-03
> >
> > Chair(s):
> > TBD
> >
> > Internet Area Director(s):
> > Ralph Droms <rdroms at cisco.com>
> > Jari Arkko <jari.arkko at piuha.net>
> >
> > Internet Area Advisor:
> > TBD
> >
> > Mailing Lists:
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> > Description of Working Group:
> >
> > Proxy Mobile IPv6, specified in RFC 5213, is a 
> network-based mobility 
> > protocol. It uses a Mobile Access Gateway (MAG) and a Local 
> Mobility 
> > Anchor
> > (LMA) to allow hosts to move around within a domain while keeping 
> > their address or address prefix stable. Proxy Mobile IPv6 has been 
> > incorporated into a number of products and deployments are 
> starting. 
> > Certain deployment considerations, including localized routing and 
> > bulk refresh of lifetime are already emerging.
> >
> > The working group will focus on the following topics relevant for 
> > network-based mobility:
> >
> > Localized Routing: a specification for routing traffic between the 
> > MAG(s) without involving the LMA. That is, allow the MAGs to route 
> > traffic between hosts from one MAG to another, without 
> being tunneled 
> > all the way to the LMA. This reduces latency and backhaul load. 
> > Applications such as voice can benefit from the reduced 
> latency. Hosts 
> > are not affected, as they still send and receive their 
> packets via the MAG.
> >
> > Bulk Refresh: a specification of improving the signaling load for 
> > binding lifetime refresh. The current specifications call for the 
> > handling of each mobility session independent of each other. When a 
> > large number of hosts are served by a single MAG, a 
> periodic refresh 
> > of the binding lifetimes can lead to a signaling storm. The 
> purpose of 
> > the Bulk Refresh feature is to construct a protocol feature that 
> > allows such refreshes to occur on a per-MAG basis.
> >
> > LMA Redirection: a specification for allowing an LMA to 
> redirect a MAG 
> > to another LMA. This is primarily needed as a way to perform load 
> > balancing, and is complementary to the initial LMA 
> discovery work in the NETLMM WG.
> >
> > The proposed activity will be complementary to the existing IETF 
> > Working Groups, notably the NETLMM and MEXT WGs. ?The 
> NETEXT working 
> > group will also act as the primary forum where new 
> extensions on top 
> > of the Proxy Mobile
> > IPv6 protocol can be developed. The addition of such new 
> extensions to 
> > the working group involves addition of the extension to 
> this charter 
> > through the normal rechartering process.
> >
> > Milestones
> >
> > May 2009 ? ? ? ? ? ? WG chartered
> > July 2009 ? ? ? ? ? ? ?Initial WG draft on Bulk Refresh 
> September 2009 ?
> > Initial WG draft on LMA Redirection November 2009 ? Initial 
> WG draft 
> > on Route Optimization December 2009 ? Submit Bulk Refresh 
> to IESG for 
> > publication as a Proposed Standard RFC January 2009 ? ? ? 
> Submit LMA 
> > Redirection to IESG for publication as a Proposed Standard 
> RFC April 
> > 2010 ? ? ? ? ? ?Submit Route Optimization to IESG for 
> publication as a 
> > Proposed Standard RFC
> >
> >
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>