Re: [netext] yet another charter version

["Koodli, Rajeev" <[e-mail]>]

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
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Laganier, Julien
> > Sent: Tuesday, 26 January, 2010 11:57 AM
> > To: Zuniga, Juan Carlos; Jari Arkko; [e-mail]
> > Subject: Re: [netext] yet another charter version
> > 
> > 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
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On 
> > > Behalf Of Zuniga, Juan Carlos
> > > Sent: Tuesday, January 26, 2010 7:38 AM
> > > To: Jari Arkko; [e-mail]
> > > Subject: Re: [netext] yet another charter version
> > >
> > > 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: [e-mail] 
> [mailto:[e-mail]] On 
> > > > Behalf Of Jari Arkko
> > > > Sent: Tuesday, 26 January, 2010 4:06 AM
> > > > To: [e-mail]
> > > > Subject: [netext] yet another charter version
> > > >
> > > > Mobility Extensions (netext)
> > > >
> > > > Last Modified: 2010-01-26
> > > >
> > > > Additional information is available at tools.ietf.org/wg/netext
> > > >
> > > > Chair(s):
> > > >
> > > >     * Rajeev Koodli <[e-mail]>
> > > >     * Basavaraj Patil <[e-mail]>
> > > >
> > > > Internet Area Director(s):
> > > >
> > > >     * Ralph Droms <[e-mail]>
> > > >     * Jari Arkko <[e-mail]>
> > > >
> > > > Internet Area Advisor:
> > > >
> > > >     * Jari Arkko <[e-mail]>
> > > >
> > > > Mailing Lists:
> > > > General Discussion: [e-mail] 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
> > > >
> > > > _______________________________________________
> > > > netext mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netext
> > > _______________________________________________
> > > netext mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netext
> > _______________________________________________
> > netext mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netext
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>