Subject: [netext] charter revision

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Jan 2010 00:40:40 +0200

This is what I have currently:

Mobility Extensions (netext)

Last Modified: 2010-01-25

Additional information is available at tools.ietf.org/wg/netext

Chair(s):

    * Rajeev Koodli <[email-masked]>
    * Basavaraj Patil <[email-masked]>

Internet Area Director(s):

    * Ralph Droms <[email-masked]>
    * Jari Arkko <[email-masked]>

Internet Area Advisor:

    * Jari Arkko <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/netext
Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html

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.
The working group will produce a problem statement and a
specification of the localized routing mechanism.

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. This functionality is complementary to implementation
techniques that allow distributed MAG implementations to move tasks
around without a visible impact at the protocol level, and the
initial LMA discovery work in the NETLMM WG. An applicability statement
describing the situations where the new functionality is or is not
applicable has to be included in the specification.

Hiding access technology changes from host IP layer: Proxy mobility is
based on the assumption that changes in host IP stacks are
undesirable.  However, link layer implementations can hide the
actually used physical interfaces from the IP stack. For instance, one
IP layer interface might transmit packets over different media, as is
common practice in certain radio networks. This can be used to achieve
inter-access handovers or flow mobility, i.e., the movement of
selected flows from one access technology to another.  It is assumed
that that an IP layer interface can simultaneously attach to multiple
MAGs (possibly over multiple media). The hiding mechanisms also need
to work together with existing RFC 5213 handover hint mechanisms.  The
specification of any actual link layer mechanisms is outside the scope
of the working group, but the group works on the following:

- Informational applicability statement that analyzes the issues
  involved with this approach and characterizes the contexts in which
  such use is or is not appropriate.

- The working group will determine what protocol extensions are
  required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs)
  to support the ability for an interface (at the IP layer) to
  transmit packets over different media, the ability to distribute
  specific traffic flows on different media components of that
  interface, and making this work with the handover hints in the base
  protocol. The relevant protocol extensions will be developed as
  necessary. The WG will assume that there the host has an interface
  that is capable of employing multiple media.

Radius Extensions to PMIP6: In order to enable network based
mobility using PMIP6, the policy profile needs to signal a set of
attributes and policies to the MAG and LMA. New Radius attributes
need to be specified that are relevant to PMIP6 based
mobility. This work item will specify Radius extensions and
attributes specific to PMIP6.

The work in this charter is entirely internal to the network and does
not affect host IP stack operation in any way (except perhaps through
impacting packet forwarding capacity visible to the hosts). The working
group is not allowed to specify new IP layer protocol mechanisms to signal
mobility related events between the host and the network.

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.

Goals and Milestones:

Done          WG chartered
Done          Initial WG draft on Bulk Refresh
Done          Decision on the inclusion of possible additional work items
Done          Initial WG draft on LMA Redirection
Done          Initial WG draft on Localized Routing Problem Statement
Mar 2010          Submit Bulk Refresh to IESG for publication as a 
Proposed Standard RFC
Mar 2010          Submit LMA Redirection to IESG for publication as a 
Proposed Standard RFC
Mar 2010        Initial WG document on RADIUS extensions to PMIP6
May 2010          Submit Localized Routing Problem Statement to IESG for 
publication as an Informational RFC
May 2010        Initial WG draft on Localized Routing Solution
Jul 2010        Initial WG document on Applicability Statement on 
Multiple Media on One Interface
Jul 2010        WG decision on what Proxy Mobile IPv6 support is needed 
to support multiple media on one interface
Oct 2010        Initial WG document(s) on Proxy Mobile IPv6 Extensions 
to Support Multiple Media on One Interface
Dec 2010        Submit RADIUS extensions to PMIP6 to IESG for 
publication as a Proposed Standard
Dec 2010        Submit Applicability Statement on Multiple Media on One 
Interface to IESG for publication as Informational RFC
Feb 2011        Submit Proxy Mobile IPv6 Extensions to Support Multiple 
Media on One Interface for publication as Proposed Standard RFC(s)
Feb 2011          Submit Localized Routing Solution to IESG for 
publication as a Proposed Standard RFC

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Jan 2010 10:20:18 +0200

Rajeev,

> I am not in favor introducing extra milestones. 
> They delay the work, and we have already spent over a year (1.5 years)
> since Dublin IETF.
>   

I understand your frustration. But I'm not sure if you are reacting to 
the concept of an additional justification and investigation step -- the 
current text does not actually call for that. It only calls for the 
working group to determine what extensions are necessary. I think that's 
reasonable and natural.

But maybe the answer is already obvious, and I'm just not seeing it. Can 
you list what extensions are necessary to support this functionality? Is 
there one or multiple?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Jan 2010 11:03:04 +0200

Rajeev,

OLD:

Hiding access technology changes from host IP layer: Proxy
mobility is based on the assumption that changes in host IP
stacks are undesirable. However, link layer implementations
can hide the actually used physical interfaces from the IP
stack. For instance, a single interface might transmit
packets over different media, as is common practice in
certain radio networks. This can be used to achieve
inter-access handovers or flow mobility, i.e., the movement
of selected flows from one access technology to another. The
specification of any actual link layer mechanisms is outside
the scope of the working group, but the group works on the following:

NEW:

Hiding access technology changes from host IP layer: Proxy mobility is
based on the assumption that changes in host IP stacks are undesirable.
However, implementation techniques can hide the underlying physical
interfaces from the IP stack. For instance, a "logical interface" may
enable packet transmission and reception over different physical media.
Such techniques can be used to enable inter-access handovers and flow
mobility, i.e., the movement of selected flows from one access
technology to another. The specification of any actual link layer
mechanisms is outside the scope of the working group, but the group
works on the following:

I like the change to a logical interface. (But you were commenting on
an older version of the charter text. The current text read: "...  For
instance, one IP layer interface might transmit packets over different
media, as is common practice in certain radio networks....")

OLD:

NEW:

- Informational applicability statement that analyzes the issues
involved with a logical interface that supports multiple physical media,
and documents the contexts where its use is appropriate and where it is
not.

I can make this change, but I thought we had a few people commenting
that the charter text was too specific for a particular implementation.
I wanted to refer to the general approach and not repeat it here.

OLD:

- The working group will determine if protocol extensions are required
between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to
support the ability for a single host interface to transmit packets
over different media and the ability to distribute specific traffic
flows on different media components of that single interface. The
relevant protocol extensions will be developed as necessary. The WG
will assume that there the host has an interface that is capable of
employing multiple media.

NEW:

- The working group will work on protocol extensions to Proxy Mobile
IPv6 (involving LMA - MAG and MAG - MAG signaling) to support the
distribution of specific traffic flows over different physical media
when a mobile node is attached to them simultaneously (flow mobility).
The working group will also work on Proxy Mobile IPv6 extensions for
handover of flows from one physical interface to another (inter-access
handovers). The WG will assume but not mandate that the host will have a
logical interface that is capable of supporting multiple physical media.

I'm fine with stating that the group will work on extensions, but I do
want to see the step where the group determines what those extensions
are. Unless, of course, we already know perfectly what those extensions
are :-)

The assumption part can actually be completely removed, because there's
a more detailed statement about it earlier on (look at the new charter
text).

Goals and Milestones:

May 2009 WG chartered
Jul 2009 Initial WG draft on Bulk Refresh
Jul 2009 Decision on the inclusion of possible additional

work items

Sep 2009 Initial WG draft on LMA Redirection
Sep 2009 Initial WG draft on Localized Routing
Dec 2009 Submit Bulk Refresh to IESG for publication as a

Proposed Standard RFC

Jan 2010 Submit LMA Redirection to IESG for publication as a

Proposed Standard RFC

Mar 2010 Initial WG document on RADIUS extensions to PMIP6
Apr 2010 Submit Localized Routing to IESG for publication as

a Proposed Standard RFC

OLD:

May 2010 Initial WG document on Applicability Statement on

Jun 2010 WG decision on what Proxy Mobile IPv6 support is

needed to support multiple media on one interface

Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions

Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for

Dec 2010 Submit Applicability Statement on Multiple Media on

One Interface to IESG for publication as Informational RFC

Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support

Multiple

NEW:

May 2010 Initial WG document on Applicability Statement
of Logical Interface over multiple physical interfaces
Sep 2010 Initial WG documents on Proxy Mobile IPv6
extensions for Flow Mobility and Inter-access Handovers over the Logical
Interface
Oct 2010 Submit RADIUS extensions to Proxy Mobile IPv6 to IESG
for publication as a Proposed Standard
Dec 2010 Submit Applicability Statement of Logical Interface
over multiple physical interfaces to IESG for publication as
Informational RFC
Feb 2011 Submit Proxy Mobile IPv6 extensions for Flow Mobility
and Inter-access Handovers over the Logical Interface for publication as
Proposed Standard RFCs

I like your formulation, but I would like to retain the step about
decising what extensions are needed.

Jari

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Monday, January 25, 2010 2:41 PM
To: [email-masked]
Subject: [netext] charter revision

Chair(s):

Internet Area Advisor:

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/netext
Archive:
http://www.ietf.org/mail-archive/web/netext/current/maillist.html

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.
The working group will produce a problem statement and a
specification of the localized routing mechanism.

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. This functionality is
complementary to implementation techniques that allow
distributed MAG implementations to move tasks around without
a visible impact at the protocol level, and the initial LMA
discovery work in the NETLMM WG. An applicability statement
describing the situations where the new functionality is or
is not applicable has to be included in the specification.

Hiding access technology changes from host IP layer: Proxy
mobility is based on the assumption that changes in host IP
stacks are undesirable. However, link layer implementations
can hide the actually used physical interfaces from the IP
stack. For instance, one IP layer interface might transmit
packets over different media, as is common practice in
certain radio networks. This can be used to achieve
inter-access handovers or flow mobility, i.e., the movement
of selected flows from one access technology to another. It
is assumed that that an IP layer interface can simultaneously
attach to multiple MAGs (possibly over multiple media). The
hiding mechanisms also need to work together with existing
RFC 5213 handover hint mechanisms. The specification of any
actual link layer mechanisms is outside the scope of the
working group, but the group works on the following:

Radius Extensions to PMIP6: In order to enable network based
mobility using PMIP6, the policy profile needs to signal a
set of attributes and policies to the MAG and LMA. New Radius
attributes need to be specified that are relevant to PMIP6
based mobility. This work item will specify Radius extensions
and attributes specific to PMIP6.

The work in this charter is entirely internal to the network
and does not affect host IP stack operation in any way
(except perhaps through impacting packet forwarding capacity
visible to the hosts). The working group is not allowed to
specify new IP layer protocol mechanisms to signal mobility
related events between the host and the network.

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.

Goals and Milestones:

Done WG chartered
Done Initial WG draft on Bulk Refresh
Done Decision on the inclusion of possible
additional work items
Done Initial WG draft on LMA Redirection
Done Initial WG draft on Localized Routing Problem Statement
Mar 2010 Submit Bulk Refresh to IESG for publication as a
Proposed Standard RFC
Mar 2010 Submit LMA Redirection to IESG for publication as a
Proposed Standard RFC
Mar 2010 Initial WG document on RADIUS extensions to PMIP6
May 2010 Submit Localized Routing Problem Statement
to IESG for
publication as an Informational RFC
May 2010 Initial WG draft on Localized Routing Solution
Jul 2010 Initial WG document on Applicability Statement on
Multiple Media on One Interface
Jul 2010 WG decision on what Proxy Mobile IPv6 support
is needed
to support multiple media on one interface
Oct 2010 Initial WG document(s) on Proxy Mobile IPv6
Extensions
to Support Multiple Media on One Interface
Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for
publication as a Proposed Standard
Dec 2010 Submit Applicability Statement on Multiple
Media on One
Interface to IESG for publication as Informational RFC
Feb 2011 Submit Proxy Mobile IPv6 Extensions to
Support Multiple
Media on One Interface for publication as Proposed Standard RFC(s)
Feb 2011 Submit Localized Routing Solution to IESG for
publication as a Proposed Standard RFC

_______________________________________________
netext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 26 Jan 2010 14:12:04 -0500

> 
> But maybe the answer is already obvious, and I'm just not 
> seeing it. Can you list what extensions are necessary to 
> support this functionality? Is there one or multiple?

Flow Mobility:

- protocol between LMA and (target) MAG to support forwarding of one or
more flows 
  - Request/Respone messaging
- the protocol will carry one or more MH options, including such flow
tuple parameters as HNP, IPv4 address, QoS parameters, etc.

Inter-access handover:

- MAG - MAG protocol: perhaps we can re-use PFMIP6 with appropriate MH
options
- Target MAG - AAA protocol: this is feasible when an auth protocol is
assumed to be in place upon inter-access handovers within the same PMIP6
domain; I am not sure extensions are necessary.

As you can see, this does not have to be complicated.

I am sure the docs will go through the normal WG iteration which will
ensure robustness.

Thanks,

-Rajeev

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 26 Jan 2010 14:18:13 -0500

As a follow up, I believe there are a few drafts already.
Folks, you may please identify your drafts.

Here's one:
http://tools.ietf.org/html/draft-koodli-netext-flow-handover-01

Thanks,

-Rajeev

> [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
> Sent: Tuesday, January 26, 2010 11:12 AM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [netext] charter revision
> 
> 
>  
> 
> > 
> seeing it. 
> > Can you list what extensions are necessary to support this 
> > functionality? Is there one or multiple?
> 
> Flow Mobility:
> 
> - protocol between LMA and (target) MAG to support forwarding 
> of one or more flows
> - the protocol will carry one or more MH options, including 
> such flow tuple parameters as HNP, IPv4 address, QoS parameters, etc.
> 
> Inter-access handover:
> 
> - MAG - MAG protocol: perhaps we can re-use PFMIP6 with 
> appropriate MH options
> - Target MAG - AAA protocol: this is feasible when an auth 
> protocol is assumed to be in place upon inter-access 
> handovers within the same PMIP6 domain; I am not sure 
> extensions are necessary.
> 
> I am sure the docs will go through the normal WG iteration 
> which will ensure robustness.
> 
> Thanks,
> 
> -Rajeev
>  
>   
> 
> 
> 
> > 
> > Jari
> > 
> >

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Jan 2010 11:29:47 -0800 (PST)

----- Original Message ----
> From: "Koodli, Rajeev" <[email-masked]>
> To: Jari Arkko <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, January 26, 2010 1:12:04 PM

I think we should not get into the solution space now. We should have a flexible charter item as we have now and then evaluate the solution space.

So I support the current wording in the charter.

Regards,

Behcet

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 26 Jan 2010 16:26:49 -0500

Hi Behcet,

The issue is not solution space. It's whether we know what extensions we are going to work on.
I believe we do, as I pointed out below, and as evidenced by the presence of a few IDs.
 
Regards,

-Rajeev

> From: Behcet Sarikaya [mailto:[email-masked]] 
> Sent: Tuesday, January 26, 2010 11:30 AM
> To: Koodli, Rajeev; Jari Arkko
> Cc: [email-masked]
> > - protocol between LMA and (target) MAG to support 
> forwarding of one 
> > or more flows
> such flow 
> appropriate MH 
> protocol is 
> > assumed to be in place upon inter-access handovers within the same 
> > PMIP6 domain; I am not sure extensions are necessary.
> > 
> I think we should not get into the solution space now. We 
> should have a flexible charter item as we have now and then 
> evaluate the solution space.
>

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Wed, 27 Jan 2010 09:56:40 +0800

Hi Rajeev, all,

I have highlighted some other drafts in the areas of flow mobility and
inter RAT handoff

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

Partial handoff of flows (flows tied to a sub group of prefixes) from
one interface to another. 

[2]
http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-dormant-binding-
00

Fast handoff in PMIP for a multi interface node when there is sudden
disconnection via unstable interface.

Thanks.

BR,
Mohana

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Koodli, Rajeev
> Sent: Wednesday, January 27, 2010 3:18 AM