[Netext] next steps for netext

Hi Jari,

I've a concern with the planned charter. The list is too random and
cherry picked and I dont believe proper input from all the folks went into
this. There are many other items that are required for a reasonable
deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
years, some of them that were left out in the base spec, some that we
realized as gaps when compared to other SDO protocols and some as
optimizations that we realized while implementing PMIP6, these items
should be in the initial scope.

I understand the charter needs to be limited in scope, but just 3 or 4
random items, I'm not sure if this helps in short term PMIP6 requirements.
I've no issue with the currently listed items, but there are other items
that should get equal or higher priority.

For example, item #6, is absolutely required, from the perspective of
having a complete specification of 5213. There we allowed a mobile node to
perform handoff betweek two interfaces. We defined all the hooks on the
network side, but we did not provide how a terminal vendor can support
that. A simple informational draft on how some one move prefixes between
interfaces will greatly help. Some guidance on how to create a virtual
interface and also some related notes for each platform (Linux, BSD,
Android ..etc). This should not fall in the controversial discussion scope
of same address on two interfaces etc, thats a different problem, or about
the issue of enhancing mobile node's capabilities. This is just
informational work, required to leverage what 5213 already supports.

Item #2, is required. The multimob BOF raised some issues, we need to
show how multicast services can be enabled in PMIP network. May be this
wont require extensions, a simple draft covering those aspects will help.

I think, the charter should be bit more relaxed and more extensive. As I
see it, atleast the folks are interested in doing the work. We should add
atleast 4 or 5 more items to this list. I've identified some of the
potential work items below.

Regards
Sri

--------------------------------------------------------------------

1. Dynamic LMA Assignment

In blade architecture systems or in a load balancer configuration, the 
PDNGW
should have the ability to dynamically assign a LMA on the fly, along the
lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
[RFC-4433].
Currently, GTP provides such semantics and this is a important requirement
for deployment. Here the goal is to

a.) Expose a single IP address to the SGW
b.) The exposed IP address should not be in path once the assignment is
done.

[LMA1]---
   |      |
[LMA2]--[LMA]==========[MAG]
   |      |
[LMA3]---

Along the lines of:

http://tools.ietf.org/html/draft-korhonen-netext-redirect-01

2. Multicast Support in Proxy Mobile IPv6

We need an informational specification on how multicast support can be
enabled in Proxy Mobile IPv6 environment. Behcet has done extensive 
analysis
on
this. This is required and critical for enabling any multicast services.
However,
Behcet may disagree with the scope of the work.

3. Bulk Registration Support

This is a simple extension which helps in signaling optimization, along 
the
lines of:

http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02

4. Partial Failover Support

We need a mechanism to notify the peer on revoke a partial set of 
bindings.

http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
txt

5. Group Identifier Support for Proxy Mobile IPv6

This provides a simple and a generic semantic for assigning a group
identifier
to a mobile node's binding. GTP has very similar semantics, Connexion Set
Id.
Both #3 and #4 can leverage this. Additionally, in load balancer systems
where
the load balancer is in path for all signaling messages, it can use this 
as
a
tag for redirecting the message.

http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00

6. Virtual-Interface Support on IP host for supporting Inter-tech 
handoffs:

RFC-5213 supports handoff between two interfaces. The ability to move
prefixes between interfaces. In other words address continuity is assured
with any IPv6 host on the planet and with absolutely no changes. This 
meets
even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
not assured is the aspect of session continuity. Which requires a virtual
interface implementation on the host, by binding the address/prefix to a
virtual interface and by not exposing the physical interface or by hiding
the handoff events from the layer-3 stack.

In essence, we need an informational specification which provides some
general guidance to how to leverage the feature support provided in
RFC-5213,
along the lines of:

http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00

7. Route Optimization for Proxy Mobile IPv6

There were atleast 4 drafts in this area on Route Optimization. Marco
Liebsch
analyzed this exensively:

http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
txt

8. Prefix Management in Proxy Mobile IPv6 support

Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
to a given mobile node's interface. It might be useful to specify how the
LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
AAA to manage this aspect. Behcet has one draft on this.

9. Partial Handoff Support

We are missing some semantics in 5213 for moving a subset of the prefixes
between interfaces as part of the inter-tech handoff. This is about 
defining
a new handoff value. This allows partial flow management, but moving the
flows associated to a prefix, as a whole group.

http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00

10. CMIPv4/PMIP Interworking

This is probably required to specify how an IPv4-only can move between
CMIP and PMIP environments.

http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
meghana-netlmm-pmipv6-mipv4-00.txt

11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6

On Fri, 3 Apr 2009, Jari Arkko 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
>