Subject: [netext] yet another charter version

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

Mobility Extensions (netext)

Last Modified: 2010-01-26

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, a
"logical interface" at the IP layer may enable packet transmission and
reception over different physical media.  Such techniques 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.

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 
Logical Interface over Multiple Physical Interfaces
Jul 2010        WG decision on what Proxy Mobile IPv6 support is needed 
to support logical lnterface over multiple physical interfaces
Oct 2010        Initial WG document(s) on Proxy Mobile IPv6 Extensions 
to Support Logical Interface over Multiple Physical Interfaces
Dec 2010        Submit RADIUS extensions to PMIP6 to IESG for 
publication as a Proposed Standard
Dec 2010        Submit Applicability Statement on Logical Interface over 
Multiple Physical Interfaces to IESG for publication as Informational RFC
Feb 2011        Submit Proxy Mobile IPv6 Extensions to Support Logical 
Interface over Multiple Physical Interfaces for publication as Proposed 
Standard RFC(s)
Feb 2011          Submit Localized Routing Solution to IESG for 
publication as a Proposed Standard RFC

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 26 Jan 2010 10:37:53 -0500

Jari,

Thanks for the new version. I share views with Rajeev and others and I
believe that the new charter reads much better. Nonetheless, I'd suggest
removing the following sentence: 

" It is assumed that that an IP layer interface can simultaneously
attach to multiple MAGs (possibly over multiple media). "

I had previously made a point that an MN may need to move from one MAG
to another and if the MN can only operate one radio technology at a time
(single-radio handover) then the multiple-MAG attachment does not apply.
I don't think we need to make this strong assumption.

By removing that sentence we allow both singe-radio and simultaneous
attachment solutions to be documented.

Juan Carlos

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jari Arkko
> Sent: Tuesday, 26 January, 2010 4:06 AM
> To: [email-masked]
> Subject: [netext] yet another charter version
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 26 Jan 2010 08:57:28 -0800

Carlos,

I think I understand your point regarding the conflict between supporting inter access handovers on MN that can only operate a single radio at a time and the simultaneous MAG attachment assumption now captured in the charter. 

I however differ on the way we should resolve your concern.

IMHO, rather than making the charter more vague by removing the sentence, we should be more specific to cover the situation you're outlining.

How about the following:

"For inter-access handovers, it is assumed that a single IP layer interface can sequentially attach to different type of accesses and/or media. For flow mobility, it is assumed that that a single IP layer interface can simultaneously attach to multiple MAGs (possibly over multiple media)."

--julien

> Behalf Of Zuniga, Juan Carlos
> Sent: Tuesday, January 26, 2010 7:38 AM
> To: Jari Arkko; [email-masked]
> Subject: Re: [netext] yet another charter version
> 
> Jari,
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 27 Jan 2010 11:00:14 -0500

Julien,

To me the charter should be strict regarding deliverables and guidelines
and vague regarding the solutions.
That's why I was originally suggesting simply removing the sentence.
However, I would not have a strong opinion against the text you propose,
just with one small correction to address both single and dual-radio
cases:

OLD

"For inter-access handovers, it is assumed that a single IP layer
interface can sequentially attach to different type of accesses and/or
media. For flow mobility, it is assumed that that a single IP layer
interface can simultaneously attach to multiple MAGs (possibly over
multiple media)."

NEW

"For inter-access handovers, it is assumed that a single IP layer
interface can attach sequentially or simultaneously to different MAGs 
through different types of accesses and/or media. For flow mobility, 
it is assumed that that a single IP layer interface can simultaneously 
attach to multiple MAGs (possibly over multiple media)."

Regards,

Juan-Carlos

> Behalf Of Laganier, Julien
> Sent: Tuesday, 26 January, 2010 11:57 AM
> To: Zuniga, Juan Carlos; Jari Arkko; [email-masked]
> I think I understand your point regarding the conflict between
> supporting inter access handovers on MN that can only operate a single
> radio at a time and the simultaneous MAG attachment assumption now
> captured in the charter.
> 
> IMHO, rather than making the charter more vague by removing the
> sentence, we should be more specific to cover the situation you're
> outlining.
> 
> How about the following:
> 
> "For inter-access handovers, it is assumed that a single IP layer
> interface can sequentially attach to different type of accesses and/or
> media. For flow mobility, it is assumed that that a single IP layer
> interface can simultaneously attach to multiple MAGs (possibly over
> multiple media)."
> 
> --julien
> 
> > > 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
> > > Hiding access technology changes from host IP layer: Proxy
mobility
> > is
> > > group is not allowed to specify new IP layer protocol mechanisms
to
> > > signal
> > > Done          Decision on the inclusion of possible additional
work
> > > items
> > > Mar 2010          Submit LMA Redirection to IESG for publication
as
> a
> > > May 2010          Submit Localized Routing Problem Statement to
> IESG
> > > for
> > > Dec 2010        Submit Applicability Statement on Logical
Interface
> > > over
> > > Multiple Physical Interfaces to IESG for publication as
> Informational
> > > RFC

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 27 Jan 2010 08:24:31 -0800

Thanks Carlos, the massaged text you proposed looks good.

(and FWIW I agree we should not wander too much into solution specifics in a charter, but in this case we were discussing interface features that are not a part of the solution, but the foundation on which we have to build the solution.)

--julien

> From: Zuniga, Juan Carlos [mailto:[email-masked]]
> Sent: Wednesday, January 27, 2010 8:00 AM
> To: Laganier, Julien; Jari Arkko; [email-masked]
> Subject: RE: [netext] yet another charter version
> 
> Julien,
> 
> > > Thanks for the new version. I share views with Rajeev and others
> and
> > I
> > > > Certain deployment considerations, including localized routing
> and
> > > bulk
> > > > LMA Redirection: a specification for allowing an LMA to redirect
> a
> > > MAG
> > > > "logical interface" at the IP layer may enable packet
> transmission
> > > and
> > > > mechanisms.  The specification of any actual link layer
> mechanisms
> > is
> > > > extensions to the working group involves addition of the
> extension
> > to

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 27 Jan 2010 09:14:37 -0800 (PST)

It is not clear to me if Netext should do inter-access/technology handovers. This subject is probably more appropriate for Mipshop where they already have a context transfer and a handover protocol extension to PMIPv6.

My suggestion is Netext should concentrate on flow mobility, as stated in the proposed charter.

Regards,

Behcet
----- Original Message ----
> From: "Laganier, Julien" <[email-masked]>
> To: "Zuniga, Juan Carlos" <[email-masked]>; Jari Arkko <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wed, January 27, 2010 10:24:31 AM
> (and FWIW I agree we should not wander too much into solution specifics in a 
> charter, but in this case we were discussing interface features that are not a 
> part of the solution, but the foundation on which we have to build the 
> solution.)
> 
> --julien
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 27 Jan 2010 18:57:18 -0500

Hi Juan-Carlos,

> OLD
> 
> "For inter-access handovers, it is assumed that a single IP 
> layer interface can sequentially attach to different type of 
> accesses and/or media. For flow mobility, it is assumed that 
> that a single IP layer interface can simultaneously attach to 
> multiple MAGs (possibly over multiple media)."
> 
> 
> NEW
> 
> "For inter-access handovers, it is assumed that a single IP 
> layer interface can attach sequentially or simultaneously to 
> different MAGs through different types of accesses and/or 
> media. 

Two questions:

1. what does "sequentially or simultaneously attach" mean? What is
inter-access handover when you have simultaneous attachment?

2. What does "different types of access and/or media" mean? I don't see
the difference between access and media here; I do admit that we have
been quite loose in using them interchangeably.

Thanks,

-Rajeev

>For flow mobility, it is assumed that that a single IP 
> layer interface can simultaneously attach to multiple MAGs 
> (possibly over multiple media)."
> 
> Regards,
> 
> Juan-Carlos
> 
> 
> 
> > > Thanks for the new version. I share views with Rajeev and 
> others and
> > I
> > > believe that the new charter reads much better. Nonetheless, I'd 
> > > suggest removing the following sentence:
> > >
> > > to another and if the MN can only operate one radio 
> technology at a 
> > > time (single-radio handover) then the multiple-MAG 
> attachment does 
> > > not
> > apply.
> > > > General Discussion: [email-masked] To Subscribe: 
> > > > 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
> > > > handling of each mobility session independent of each 
> other. When
> a
> > > > LMA Redirection: a specification for allowing an LMA to 
> redirect a
> > > MAG
> > > > actually used physical interfaces from the IP stack. 
> For instance,
> > a
> > > > assumed that that an IP layer interface can 
> simultaneously attach
> > to
> > > > need to be specified that are relevant to PMIP6 based mobility. 
> > > > This work item will specify Radius extensions and attributes 
> > > > specific to PMIP6.
> > > >
> > > > The proposed activity will be complementary to the 
> existing IETF 
> > > > Working Groups, notably the NETLMM and MEXT WGs. The NETEXT 
> > > > working group
> > > will
> > > > extensions to the working group involves addition of 
> the extension
> > to

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 28 Jan 2010 11:15:51 -0500

Hi Rajeev,

> From: Koodli, Rajeev [mailto:[email-masked]]
> Sent: Wednesday, 27 January, 2010 6:57 PM
> To: Zuniga, Juan Carlos; Laganier, Julien; Jari Arkko; [email-masked]

I had originally proposed removing these descriptions, as I find them
wordy. However Julien had suggested being more specific and he then
suggested the OLD text. My addition to the NEW text was just a
clarification on the handover part.

> inter-access handover when you have simultaneous attachment?

There are two ways to perform a handover: break-before-make, or
make-before-break. Both have advantages and disadvantages at the radio
level that we don't need to discuss here. What we care is that in the
break-before-make you can only have one radio active at a time and
therefore you can only attach in sequence, whereas in the
make-before-break case you can have two radios active at a time and
therefore you 'may' attach to two MAGs simultaneously for a certain
period of time.

> been quite loose in using them interchangeably.

This wording came from Julien, and I see your point that it is probably
a bit redundant. Perhaps for inter-access handover we should keep using
'access' instead of 'medium' consistently, i.e. remove "and/or media"
from the proposed text.

Cheers,

Juan-Carlos

> > > > I had previously made a point that an MN may need to move from
> one
> > > MAG
> > > > > reception over different physical media.  Such techniques can
> be
> > > used
> > > > >   involved with this approach and characterizes the contexts
in
> > > which
> > > > >   required between the Proxy Mobile IPv6 network nodes (MAGs
> and
> > > > LMAs)
> > > > >   interface, and making this work with the handover hints in
> the
> > > base
mobility.
> > > > > The work in this charter is entirely internal to the network
> and
> > > does
> > > > > impacting packet forwarding capacity visible to the hosts).
The
> > > > working
> > > > > also act as the primary forum where new extensions on top of
> the
> > > > Proxy
> > > > > Jul 2010        WG decision on what Proxy Mobile IPv6 support
> is
> > > > needed

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 28 Jan 2010 08:17:46 -0800

Juan Carlos and Rajeev,

Zuniga, Juan Carlos wrote: 
> Koodli, Rajeev [Laganier, Julien] wrote:
> [...]
> > 2. What does "different types of access and/or media" mean? I don't
> > see the difference between access and media here; I do admit that we
> > have been quite loose in using them interchangeably.
> 

FWIW - That would be fine with me.

--julien

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 28 Jan 2010 14:26:15 -0500

Hi,

> > > interface can attach sequentially or simultaneously to different 
> > > MAGs through different types of accesses and/or media.
> > 
> 
> I had originally proposed removing these descriptions, as I 
> find them wordy. However Julien had suggested being more 
> specific and he then suggested the OLD text. My addition to 
> the NEW text was just a clarification on the handover part.
> 

I would support removing it.

> There are two ways to perform a handover: break-before-make, 
> or make-before-break. Both have advantages and disadvantages 
> at the radio level that we don't need to discuss here. What 
> we care is that in the break-before-make you can only have 
> one radio active at a time and therefore you can only attach 
> in sequence, whereas in the make-before-break case you can 
> have two radios active at a time and therefore you 'may' 
> attach to two MAGs simultaneously for a certain period of time.
> 

Sure, there is break-before-make and make-before-break. How does that
come into play here?

The problem we are trying to solve is how does the target MAG determine
it is an inter-access handover, and the associated protocol extensions. 

We should be stating the problem rather than describe radio level
handover details, no?

> see
> This wording came from Julien, and I see your point that it 
> is probably a bit redundant. Perhaps for inter-access 
> handover we should keep using 'access' instead of 'medium' 
> consistently, i.e. remove "and/or media"
> from the proposed text.
> 

Good.

-Rajeev

> Cheers,
> 
> Juan-Carlos
> 
> 
> > Thanks,
> > 
> > -Rajeev
> > 
> > 
> > 
> > >For flow mobility, it is assumed that that a single IP  layer 
> > > > > > techniques that allow distributed MAG 
> implementations to move
> > > tasks
> > > > > > initial LMA discovery work in the NETLMM WG. An 
> applicability
> > > > > statement
> > > > > > to achieve inter-access handovers or flow mobility, 
> i.e., the
> > > > > movement
> > > > > > not affect host IP stack operation in any way 
> (except perhaps
> > > > through
> > > > > > Feb 2011        Submit Proxy Mobile IPv6 Extensions 
> to Support
> > > > > Logical
> > > > > > Interface over Multiple Physical Interfaces for 
> publication as
> > > > > Proposed
> > > > > > Standard RFC(s)

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 28 Jan 2010 17:24:36 -0500

Hi Rajeev,

> Sent: Thursday, 28 January, 2010 2:26 PM
layer
> I would support removing it.

That's fine with me.

> We should be stating the problem rather than describe radio level

I agree. 

In that case, we should probably cut the wordy example descriptions and
just state the problem. 

The way I read the original description from Jari, without the examples
and assumption, seems quite clear to me. Something like this:

"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. Such techniques 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 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:"

Juan Carlos

> > > > > > From: [email-masked] [mailto:netext-
> [email-masked]]
> > On
> > > > > > > Proxy Mobile IPv6, specified in RFC 5213, is a network-
> based
> > > > > mobility
> > > > > > > protocol. It uses a Mobile Access Gateway (MAG) and a
Local
> > > > > Mobility
> > > > > > > traffic between hosts from one MAG to another, without
> being
> > > > > tunneled
> > > > > > > of selected flows from one access technology to another.
> It
> > is
> > > > > > > - The working group will determine what protocol
extensions
> > > > > > > Mobile IPv6 protocol can be developed. The addition of
such
> > new
> > > > > > > Done          Initial WG draft on Localized Routing
Problem
> > > > > Statement
> > > > > > > May 2010          Submit Localized Routing Problem
> Statement
> > to
> > > > > IESG
> > > > > > > for
> > > > > > > Oct 2010        Initial WG document(s) on Proxy Mobile
IPv6
> > > > > > Extensions
> > > > > > > Feb 2011          Submit Localized Routing Solution to
IESG

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 28 Jan 2010 18:40:08 -0500

> 
> The way I read the original description from Jari, without 
> the examples and assumption, seems quite clear to me. 
> Something like this:
> 
> 
> "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. Such techniques 
> 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 hiding mechanisms also 
> The specification of any actual link layer mechanisms is 
> outside the scope of the working group, but the group works 
> on the following:"
> 

This looks good to me.

Thanks,

-Rajeev

> > > This wording came from Julien, and I see your point that it is 
> > > probably a bit redundant. Perhaps for inter-access handover we 
> > > should keep using 'access' instead of 'medium'
> > > > > > media. For flow mobility, it is assumed that that a 
> single IP
> > > layer
> > > > > > interface can simultaneously attach to multiple 
> MAGs (possibly
> > > over
> > > > > > multiple media)."
> > > > > >
> > > > > > --julien
> > > > > >
> > > > > > > > all the way to the LMA. This reduces latency 
> and backhaul
> > > load.
> > > > > > > > also need to work together with existing RFC 
> 5213 handover
> > > hint
> > > > > > > > - Informational applicability statement that 
> analyzes the
> > > > issues
> > > > > > > >   interface, and making this work with the 
> handover hints
> > in
> > > > the
> > > > > > base
> > > > > > > > also act as the primary forum where new 
> extensions on top
> > of
> > > > the
> > > > > > > Proxy

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 28 Jan 2010 15:44:37 -0800

Hi Rajeev,

> We should be stating the problem rather than describe radio level

There has been no consensus for host changes to support network based mobility management extensions for inter-access handover and flow mobility.
 
So there's been a compromise in which we maintain the assumption that the host is not changed and the interface between IP and the network remains unchanged, and under this assumption, the WG would be allowed to develop inter-access handover and flow mobility extensions.

The text I have discussed with Juan Carlos outlines the assumption under which the WG has to work to solve the problem.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 28 Jan 2010 15:51:32 -0800

> > > > 1. what does "sequentially or simultaneously attach" mean? What
> > > > is inter-access handover when you have simultaneous attachment?
> > > >
> > >
> > The problem we are trying to solve is how does the target MAG
> > determine it is an inter-access handover, and the associated protocol
> > extensions.
> >

No.

Stating the problem is not sufficient. As we've discussed for a long time now there is no consensus for host changes in the context of network based mobility management. So the compromise we're trying to make here, is that the WG can solve the problem of network-based inter access handovers and flow mobility when an interface to the network hides the different accesses, thus not requiring changes to the host. So sure, let's state the problem to be solved, but along with the assumptions that are being made for this work to be chartered.

--julien

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 28 Jan 2010 19:41:22 -0500

Julien,

I don't see where we are disagreeing. 

Jari's latest charter text is fine with me.

I do have an issue with an intermediate milestone (cf. my other emails).

Otherwise, we are close to being done with this version.

-Rajeev

> From: Laganier, Julien [mailto:[email-masked]] 
> Sent: Thursday, January 28, 2010 3:45 PM
> To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; [email-masked]
> > > make-before-break. Both have advantages and disadvantages at the 
> > > radio level that we don't need to discuss here. What we 
> care is that 
> > > in the break-before-make you can only have one radio active at a 
> > > time and therefore you can only attach in sequence, 
> whereas in the 
> > > therefore you 'may'
> > determine it is an inter-access handover, and the 
> associated protocol extensions.
> > 
> There has been no consensus for host changes to support 
> network based mobility management extensions for inter-access 
> handover and flow mobility.
>  
> So there's been a compromise in which we maintain the 
> assumption that the host is not changed and the interface 
> between IP and the network remains unchanged, and under this 
> assumption, the WG would be allowed to develop inter-access 
> handover and flow mobility extensions.
> 
> The text I have discussed with Juan Carlos outlines the 
> assumption under which the WG has to work to solve the problem.
> 
> --julien
> 
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 28 Jan 2010 19:51:10 -0500

Hi Jari,

Other than the intermediate milestone which I am not favor of (please
see other emails), I have revisions on the deliverables below.

Thanks,

-Rajeev

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Tuesday, January 26, 2010 1:06 AM
> To: [email-masked]

OLD:

> is needed 
> Interface over 
> Informational RFC
> Interface over Multiple Physical Interfaces for publication 
> as Proposed Standard RFC(s)

NEW:

Oct 2010	    Initial WG document on Proxy Mobile IPv6 Extensions 
to Support Flow Mobility using a Logical Interface over Multiple
Physical Interfaces
Oct 2010	    Initial WG document on Proxy Mobile IPv6 Extensions 
to Support Inter-access Handovers using a Logical Interface over
Multiple Physical Interfaces
Dec 2010        Submit RADIUS extensions to PMIP6 to IESG for 
publication as a Proposed Standard
Dec 2010        Submit Applicability Statement on Logical Interface over

Multiple Physical Interfaces to IESG for publication as Informational
RFC
Feb 2011        Submit Proxy Mobile IPv6 Extensions to Support Flow
Mobility using Logical 
Interface over Multiple Physical Interfaces for publication as Proposed
Standard RFC
Feb 2011        Submit Proxy Mobile IPv6 Extensions to Support
Inter-access Handovers using Logical 
Interface over Multiple Physical Interfaces for publication as Proposed
Standard RFC
Feb 2011          Submit Localized Routing Solution to IESG for 
publication as a Proposed Standard RFC

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 28 Jan 2010 17:52:33 -0800

Hi Rajeev,

No disagreement. I understand that Juan Carlos had a concern about excluding addressing single radio inter-tech handover by using the term "simultaneously" to carachterize the interface capabilities as in Jari's charter latest text. An easy way to resolve his concern would be to add "and/or sequentially" in the offending sentence.

OLD: It is assumed that that an IP layer interface can simultaneously attach to multiple MAGs (possibly over multiple media).

NEW: It is assumed that that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media).

Thanks.

--julien

> Sent: Thursday, January 28, 2010 4:41 PM
> To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; [email-masked]

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 28 Jan 2010 21:03:00 -0500

Okay, but I thought he is fine with Jari's proposed text. Juan-Carlos?

-Rajeev

> Sent: Thursday, January 28, 2010 5:53 PM
> No disagreement. I understand that Juan Carlos had a concern 
> about excluding addressing single radio inter-tech handover 
> by using the term "simultaneously" to carachterize the 
> interface capabilities as in Jari's charter latest text. An 
> easy way to resolve his concern would be to add "and/or 
> sequentially" in the offending sentence.
> 
> OLD: It is assumed that that an IP layer interface can 
> simultaneously attach to multiple MAGs (possibly over multiple media).
> 
> NEW: It is assumed that that an IP layer interface can 
> simultaneously and/or sequentially attach to multiple MAGs 
> (possibly over multiple media).
> 
> Thanks.
> 
> --julien
> 
> > > There has been no consensus for host changes to support network 
> > > based mobility management extensions for inter-access 
> handover and 
> > > flow mobility.
> > >
> > > So there's been a compromise in which we maintain the assumption 
> > > that the host is not changed and the interface between IP and the 
> > > network remains unchanged, and under this assumption, the 
> WG would 
> > > be allowed to develop inter-access handover and flow mobility 
> > > extensions.
> > >
> assumption 
> > > under which the WG has to work to solve the problem.
> > >
> > > --julien
> > >
> > >
>

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 29 Jan 2010 10:08:21 +0800

Sorry for jumping into the discussion,

I am think such a question, is it possible that single radio can handover through different technology or media?
In my mind, a single radio means single technology, for example, an 802.11 ONLY radio can not access UMTS network, is that right?
If that is true, single radio and sequent accessing handover seems belong to MIPSHOP WG, while NETEXT focus on inter-tech handover?

Thanks and regards

Xiangsong

----- Original Message ----- 
From: "Laganier, Julien" <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>; "Zuniga, Juan Carlos" <[email-masked]>; "Jari Arkko" 
<[email-masked]>; <[email-masked]>
Sent: Friday, January 29, 2010 9:52 AM
Subject: Re: [netext] yet another charter version

> Hi Rajeev,
>
> No disagreement. I understand that Juan Carlos had a concern about excluding addressing single radio inter-tech handover by using 
> the term "simultaneously" to carachterize the interface capabilities as in Jari's charter latest text. An easy way to resolve his 
> concern would be to add "and/or sequentially" in the offending sentence.
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 29 Jan 2010 11:33:59 -0500

I'm fine with adding the latest text as proposed by Julien. It is not
too wordy and it solves my main concern.

Just to make sure we are on the same page, it would then read as
follows:

" 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 "logical interface" at the
IP layer may enable packet transmission and reception over different
physical media.  Such techniques 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 and/or sequentially 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:"

Rajeev: Would this resolve your previous point about clearly stating the
problem at hand:

"The problem we are trying to solve is how does the target MAG determine
it is an inter-access handover, and the associated protocol extensions.
"

?

Juan-Carlos

> Sent: Thursday, 28 January, 2010 9:03 PM

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 29 Jan 2010 11:46:05 -0500

Hi Xiangsong,

> From: Xiangsong Cui [mailto:[email-masked]]
> Sent: Thursday, 28 January, 2010 9:08 PM
> To: Laganier, Julien; Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko;
> [email-masked]
> I am think such a question, is it possible that single radio can
> handover through different technology or media?
> In my mind, a single radio means single technology, for example, an
> 802.11 ONLY radio can not access UMTS network, is that right?
> If that is true, single radio and sequent accessing handover seems
> belong to MIPSHOP WG, while NETEXT focus on inter-tech handover?
> 
> Thanks and regards
> 
> Xiangsong
> 

Single-radio refers to only one radio transmitting at any time during
the entire handover process (to avoid interference, save battery, etc).
There could be multiple radios in the device, but only one will be
active at a time.

Regards,

Juan Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 29 Jan 2010 09:21:29 -0800 (PST)

Hi,
  I found these definitions online:

Interworking solution using the MS having a dual transmitter is referred to as Dual Radio (DR) solution, which assumes 2 active transmit and 2 active receive chains. It assumes that the terminal can communicate simultaneously with both WiMAX and 3GPP Pre-Rel8 Packet Core points of attachment

Interworking solution using the MS having a single transmitter is referred to as Single Radio (SR) solution, which assumes 1 active transmit and either 1 or 2 active receive chains. It assumes that the terminal can receive from either one or both technology points of attachment, but can transmit to only one of them, either to the WiMAX, or to the 3GPP Pre-Rel8 Packet Core points of attachment. 

Regards,

Behcet

----- Original Message ----
> From: "Zuniga, Juan Carlos" <[email-masked]>
> To: Xiangsong Cui <[email-masked]>; [email-masked]
> Sent: Fri, January 29, 2010 10:46:05 AM

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 29 Jan 2010 12:20:57 -0500

Hi Juan-Carlos,
 
we agree that the problem we are trying to solve is the inter-access handovers.
 
How the interface attaches to MAGs of different access should be open and not restrictive; we would end up going into details of lower-layer handovers o/w.
 
Adding "It is assumed that that an IP layer
interface can simultaneously and/or sequentially attach to multiple MAGs
(possibly over multiple media)", while I understand the intention, has the side effect of confusing interpretation.
For instance, I don't understand what "..simultaneously and sequentially attach.." mean..
 
Does the current charter text without the above sentence exclude anything?
 
I am for keeping it as proposed by Jari, unless it is insufficient.
 
Thanks,
 
-Rajeev

________________________________

From: Zuniga, Juan Carlos [mailto:[email-masked]]
Sent: Fri 1/29/2010 8:33 AM
To: Koodli, Rajeev; Laganier, Julien; Jari Arkko; [email-masked]
Subject: RE: [netext] yet another charter version

?

Juan-Carlos

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 20:06:38 +0100

I think we are trying to wordsmith the charter far too much here. What Jari
has proposed at the present time allows us to get started and move forward.
So I would recommend that we close the discussion here and request Jari to
have the charter approved by the IESG.

-Raj

On 1/29/10 11:20 AM, "Rajeev Koodli" <[email-masked]> wrote:

> How the interface attaches to MAGs of different access should be open and not
> restrictive; we would end up going into details of lower-layer handovers o/w.
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 29 Jan 2010 14:15:34 -0500

Hi Rajeev,

> Sent: Friday, 29 January, 2010 12:21 PM
> How the interface attaches to MAGs of different access should be open
> and not restrictive; we would end up going into details of lower-layer
> handovers o/w.

Yes, we agree.

> (possibly over multiple media)", while I understand the intention, has
> the side effect of confusing interpretation.

Jari had proposed a text only assuming simultaneous attachment, and
hence my issue about the single-radio implementations. I had suggested
removing it but Julien wanted to keep it and he proposed changing
"simultaneously" by "simultaneously and/or sequentially".

I'm perfectly fine either removing the sentence or leaving it as Julien
last suggested. 
I just don't want to leave the original assumption to only allow
simultaneous MAG attachment for the solution.

Cheers,

Juan-Carlos
 
> -Rajeev
undesirable.
> > > > > There has been no consensus for host changes to support
network

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 29 Jan 2010 11:51:10 -0800

Hi folks,

Zuniga, Juan Carlos wrote:
> > interface can simultaneously and/or sequentially attach to multiple
> > MAGs (possibly over multiple media)", while I understand the intention,
> > has the side effect of confusing interpretation.

It means the interface can simultaneously attach to multiple MAGs (possibly over multiple media). And it can sequentially attach to multiple MAGs (possibly over multiple media).

I don't find myself that confused =)

> last suggested. I just don't want to leave the original assumption to only 
> allow simultaneous MAG attachment for the solution.

I have to insist that we do keep the sentence in.

Thanks.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 29 Jan 2010 11:54:40 -0800

Hello Raj,

IMHO it's a bit exaggerated to characterize as "far too much" the addition of "and/or sequentially" amid a sentence.

--julien
 
Basavaraj Patil wrote: 
> 
> I think we are trying to wordsmith the charter far too much here. What
> Jari has proposed at the present time allows us to get started and move
> forward. So I would recommend that we close the discussion here and 
> request Jari to have the charter approved by the IESG.
> 
> -Raj
> 
> and not
> MAGs
> > (possibly over multiple media)", while I understand the intention,
> has the
> > For instance, I don't understand what "..simultaneously and
> sequentially
> > attach.." mean..
> >

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 20:59:49 +0100

Alright. Lets make that change then and move on :)

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 29 Jan 2010 18:45:51 -0500

> Sent: Friday, January 29, 2010 11:51 AM
> To: Zuniga, Juan Carlos; Koodli, Rajeev; Jari Arkko; [email-masked]

> > > sequentially attach.." mean..
> 
> It means the interface can simultaneously attach to multiple 
> MAGs (possibly over multiple media). And it can sequentially 
> attach to multiple MAGs (possibly over multiple media).

Hmm.. If something attaches to multiple MAGs simultaneously, why would
it attach sequentially with an "AND"?

> I don't find myself that confused =)

Well, that leaves me all right, but not in any better shape.

I don't understand what this sentence is bringing here which cannot be
accomplished by not having it!

> > I'm perfectly fine either removing the sentence or leaving it as 
> > Julien last suggested. I just don't want to leave the original 
> > assumption to only allow simultaneous MAG attachment for 
> the solution.
> 

I am perfectly fine with Jari's current text. 

-Rajeev

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 29 Jan 2010 18:47:13 -0500

Actually, I don't see what we get by inserting an "and/or"
(mis)interpretation which we can live without!

-Rajeev

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, January 29, 2010 12:00 PM
> To: [email-masked]; Koodli, Rajeev; 
> [email-masked]; [email-masked]; 
> [email-masked]
> > IMHO it's a bit exaggerated to characterize as "far too much" the 
> > addition of "and/or sequentially" amid a sentence.
> > 
> > --julien
> > 
> > Basavaraj Patil wrote:
> >> 
> >> I think we are trying to wordsmith the charter far too much here. 
> >> What Jari has proposed at the present time allows us to 
> get started 
> >> and move forward. So I would recommend that we close the 
> discussion 
> >> here and request Jari to have the charter approved by the IESG.
> >> 
> >> -Raj
> >> 
> >>> we agree that the problem we are trying to solve is the 
> inter-access 
> >>> handovers.
> >>> 
> >>> Adding "It is assumed that that an IP layer interface can

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 29 Jan 2010 15:55:59 -0800

Hi Rajeev,

> it attach sequentially with an "AND"?

The modal verb "can" does play a role in the sentence above. The sentence doesn't say it attaches simultaneously and sequentially. It says it *can* attach simultaneously and/or sequentially. This is referring to capabilities.

> I am perfectly fine with Jari's current text.

This I've understood, but I've been trying to address Juan Carlos' concern about the current charter text excluding single radio inter-access handovers for interfaces that can't TX/RX simultaneously on two different radios (e.g., some chips are doing both cdma2000 and GSM/WCDMA, but one at a time.)

--julien

---

From: Xiangsong Cui <[email-masked]>
Date: Sat, 30 Jan 2010 08:42:17 +0800

Thanks Carlos and Behcet,

I understand it now.

Regards
Xiangsong

----- Original Message ----- 
From: "Zuniga, Juan Carlos" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; <[email-masked]>
Sent: Saturday, January 30, 2010 12:46 AM
Subject: RE: [netext] yet another charter version

Hi Xiangsong,

Regards,

Juan Carlos

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 29 Jan 2010 19:57:05 -0500

Hi,
 
> The modal verb "can" does play a role in the sentence above. 

So, we need to state it as *can* then :-)

This is my point. It is not your intent that's in question here. If
what's needed is captured with the existing text, we don't need to spend
time like this..

> This I've understood, but I've been trying to address Juan 
> Carlos' concern about the current charter text excluding 
> single radio inter-access handovers for interfaces that can't 
> TX/RX simultaneously on two different radios (e.g., some 
> chips are doing both cdma2000 and GSM/WCDMA, but one at a time.)

I just added a phrase to inter-access handovers below in the charter
text (in << >>):

"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 "logical interface" at the
IP layer may enable packet transmission and reception over different
physical media.  Such techniques can be used to achieve inter-access
handovers <<(from one physical interface to another)>> or flow mobility,
i.e., the movement of selected flows from one access technology to
another <<(when there is simultaneous attachment to more than one
interface)>>. 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:"

Is this okay?

Thanks,

-Rajeev

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 29 Jan 2010 17:06:48 -0800

> So, we need to state it as *can* then :-)

Rajeev, the single change I've proposed in an earlier note was to operate the following insertion in Jari's last charter text:

 
Unless I'm having hallucinations, the verb "can" is indeed present in the sentence above...

> what's needed is captured with the existing text, we don't need to
> spend time like this..

Right. So I understand me outlining the "can" in Jari's text and my insertion of "and/or sequentially" not modifying that is resolving your concern.

> but the group works on the following:"

This is NOT okay.

You haven't just added a phrase, you removed a sentence that was present in Jari's last charter text sent in his email dated Mon 1/25/2010 2:41 PM (this is PST timezone.)

    "It is assumed that that an IP layer interface can simultaneously attach
     to multiple MAGs (possibly over multiple media)" 

I'm insisting that the sentence above is not removed. We can insert "and/or sequentially"to address Juan Carlos' concern.

--julien

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 29 Jan 2010 20:20:57 -0500

Julien,
 
> present in the sentence above...

Whatever it is, I do not follow the above logic without interposing
subjective interpretations.

> > 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 "logical 
> > interface" at the IP layer may enable packet transmission and 
> > to achieve inter-access handovers <<(from one physical interface to 
> > another)>> or flow mobility, i.e., the movement of selected 
> flows from 
> > one access technology to another <<(when there is simultaneous 
> > attachment to more than one interface)>>. The hiding 
> mechanisms also 
> outside the 

I just took whatever was there in 

\begin

> Sent: Friday, January 29, 2010 8:34 AM
> I'm fine with adding the latest text as proposed by Julien. 
> It is not too wordy and it solves my main concern.
> 
> " Hiding access technology changes from host IP layer: Proxy 
> used physical interfaces from the IP stack. For instance, a 
> transmission and reception over different physical media.  
> Such techniques 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 and/or sequentially 
> 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:"
> 

\end

and modified it. This was the latest from Juan-carlos containing the
"and/or" fuzzy logic! 

-Rajeev

> 
> You haven't just added a phrase, you removed a sentence that 
> was present in Jari's last charter text sent in his email 
> dated Mon 1/25/2010 2:41 PM (this is PST timezone.)
> 
> I'm insisting that the sentence above is not removed. We can 
> insert "and/or sequentially"to address Juan Carlos' concern.
> 
> --julien
>