[Netext] next steps for netext

Hi Jari

IMHO,  we should prioritize flow mobility which
is required by both 3GPP and 3GPP2.

BR
Frank

----- Original Message ----- 
From: "Jari Arkko" <jari.arkko at piuha.net>
To: <netext at mail.mobileip.jp>; "Rajeev Koodli" <rajeev.koodli at gmail.com>; 
"Basavaraj Patil" <basavaraj.patil at nokia.com>
Sent: Friday, April 03, 2009 2:31 AM
Subject: [Netext] next steps for netext

> 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 