Re: [Mipshop] Proposed new charter

[Frank Xia <[e-mail]>]

Hi Vijay

First of all, I am supporting this rechartering item in general.

IMO, mechanism that is applicable to MIP is also possible feasible
to PMIP  after some adaptations.
I don't  think it is necessary to exclude the possibility of  PMIPv6 application.

BR
Frank

----- Original Message ----- 
From: "Vijay Devarapalli" <[e-mail]>
To: "Frank Xia" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Mipshop" <[e-mail]>
Sent: Wednesday, March 12, 2008 1:52 PM
Subject: Re: [Mipshop] Proposed new charter


> Frank Xia wrote:
> > Hi Vijay
> > 
> > I would like to suggest that PMIPv6 is in the scope.
> 
> The PMIPv6 tunnel is not over the air. In addition, the PMIPv6
> tunnel between the MAG and the LMA is used carry traffic for a
> number of mobile nodes. There is no tunnel per mobile node.
> 
> What kind of optimization do we need for PMIPv6?
> 
> Vijay
> 
> > 
> > BR
> > Frank
> > 
> > ----- Original Message ----- 
> > From: "Vijay Devarapalli" <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>; "Mipshop" <[e-mail]>
> > Sent: Wednesday, March 12, 2008 1:40 PM
> > Subject: Re: [Mipshop] Proposed new charter
> > 
> > 
> >> Hello Zarrar,
> >>
> >> I believe the current scope of work is about reducing the tunneling
> >> overhead over the air due to protocols like MIPv6 and HMIPv6. This
> >> work had a lot of consensus in the MEXT WG and then transferred here.
> >>
> >> My personal opinion is that I think we should stick to that scope
> >> for now. Expanding the scope of the work would require more
> >> discussions and consensus in the MIPSHOP WG. Until then we should
> >> not expand the scope.
> >>
> >> Vijay
> >>
> >> [e-mail] wrote:
> >>> Hello Stefano,
> >>>  
> >>> Thanks for your comments and your feedback. I agree with your argument 
> >>> but on the other hand, IMHO, the duration of the tunnel existence is 
> >>> also a resource consuming phenomena in which resources are reserved on 
> >>> both ends of the tunnel and the tunneling/de-tunneling of packets 
> >>> (in both directions) will not only add extra overhead but also incur 
> >>> processing delay and this will impact real time communication sessions 
> >>> and fast moving users (with smaller dwell times) in terms of jitter and 
> >>> delays.
> >>> I very much agree that a holistic and across-the-board approach towards 
> >>> optimizing the tunneling function is required (so that MIPv6 can also be 
> >>> optimised) but I would also suggest that this aspect (of finding ways to 
> >>> reduce tunneling duration) should also be made part of the new charter, 
> >>> as I see FMIPv6 a good candidate for providing near-seamless handovers 
> >>> for "fast moving users".
> >>>  
> >>> take care
> >>>  
> >>> Zarrar Yousaf
> >>> Communication Networks Institute,
> >>> Dortmund University of Technology (TU Dortmund)
> >>> Germany
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>>
> >>>     ------------------------------------------------------------------------
> >>>     Subject: RE: [Mipshop] Proposed new charter
> >>>     Date: Wed, 12 Mar 2008 08:01:17 -0700
> >>>     From: [e-mail]
> >>>     To: [e-mail]; [e-mail]
> >>>     CC: [e-mail]
> >>>
> >>>     Dear Zarraf,
> >>>     thanks for the email. Interesting draft. My understanding of the
> >>>     tunnel optimization in the charter is however slightly different. In
> >>>     fact the charter refers to "negative impact on the protocol
> >>>     efficiency which is translated in the data packet size, bandwidth
> >>>     usage and battery power consumption. Therefore, a mechanism which
> >>>     enables reducing the tunneling overhead would benefit the mobile
> >>>     node and optimize the bandwidth usage. The MIPSHOP WG will
> >>>     standardize such a mechanism." Therefore the charter refers to
> >>>     optimizations to the way tunneling is performed to e.g. reduce the
> >>>     size of the packets. IMO it does not refer to the temporary tunnel
> >>>     created in FMIPv6 between the PAR and the NAR, but to the tunneling
> >>>     present through the whole connection.
> >>>     Cheers,
> >>>     Stefano
> >>>
> >>>     ------------------------------------------------------------------------
> >>>     *From:* [e-mail] on behalf of [e-mail]
> >>>     *Sent:* Wed 3/12/2008 1:32 AM
> >>>     *To:* Frank Xia; Vijay Devarapalli
> >>>     *Cc:* 'Mipshop'
> >>>     *Subject:* Re: [Mipshop] Proposed new charter
> >>>
> >>>     Hello,
> >>>      
> >>>     Regarding Tunnel optimization in FMIPv6, a draft has already been
> >>>     submitted called "Proactive Bindings in FMIPv6"
> >>>     (https://datatracker.ietf.org/drafts/draft-yousaf-ietf-mipshop-pbfmipv6/)
> >>>     in which a proposal regarding the reduction of the tunnel
> >>>     duration has already been proposed.
> >>>      
> >>>     At the moment we are performing simulation and measurement tests and
> >>>     the initial results are  very encouraging, however i will be able to
> >>>     share more details after about one month.
> >>>      
> >>>     BR
> >>>      
> >>>     Zarrar Yousaf
> >>>
> >>>
> >>>
> >>>
> >>>     ------------------------------------------------------------------------
> >>>      > Date: Tue, 11 Mar 2008 18:38:52 -0500
> >>>      > From: [e-mail]
> >>>      > To: [e-mail]
> >>>      > CC: [e-mail]
> >>>      > Subject: Re: [Mipshop] Proposed new charter
> >>>      >
> >>>      > Hi Vijay
> >>>      >
> >>>      > Please see my reply..
> >>>      >
> >>>      > BR
> >>>      > Frank
> >>>      > ----- Original Message -----
> >>>      > From: "Vijay Devarapalli" <[e-mail]>
> >>>      > To: "Frank Xia" <[e-mail]>
> >>>      > Cc: "'Mipshop'" <[e-mail]>
> >>>      > Sent: Tuesday, March 11, 2008 5:29 PM
> >>>      > Subject: Re: [Mipshop] Proposed new charter
> >>>      >
> >>>      >
> >>>      > > Frank Xia wrote:
> >>>      > > > Hi Vijay
> >>>      > > >
> >>>      > > > For Tunnel Optimization, why should we limit in Mobile IPv6
> >>>     and HMIP6?
> >>>      > >
> >>>      > > It wasn't meant to be an exhaustive list of protocols that
> >>>      > > tunnel.
> >>>      > Frank=>IMO, it is a little bit ambiguous. For example,
> >>>      > why is HMIP6 is highlighted? why isn't FMIP6 highlighted?
> >>>      > It will be helpful if you make it clearer.
> >>>      >
> >>>      > >
> >>>      > > > I think it is also possible for PMIPv6 and Mobile IPv4.
> >>>      > >
> >>>      > > We have not taken on any work related to Mobile IPv4 so far.
> >>>      > >
> >>>      > > Vijay
> >>>      > >
> >>>      > > >
> >>>      > > > BR
> >>>      > > > Frank
> >>>      > > >
> >>>      > > >
> >>>      > > > ----- Original Message -----
> >>>      > > > From: "Vijay Devarapalli" <[e-mail]>
> >>>      > > > To: "'Mipshop'" <[e-mail]>
> >>>      > > > Sent: Tuesday, March 11, 2008 5:12 PM
> >>>      > > > Subject: Re: [Mipshop] Proposed new charter
> >>>      > > >
> >>>      > > >
> >>>      > > >> Hello,
> >>>      > > >>
> >>>      > > >> The MEXT working group has asked to take on some additional
> >>>     work.
> >>>      > > >> This is about a mechanism to reduce the tunneling overhead
> >>>     due to
> >>>      > > >> MIPv6 and HMIPv6. So we modified the charter to include this
> >>>     work
> >>>      > > >> too. Here is the revised charter. Please review.
> >>>      > > >>
> >>>      > > >>
> >>>     ------------------------------------------------------------------------
> >>>      > > >>
> >>>      > > >> Mobility for IP: Performance, Signaling and Handoff
> >>>     Optimization (MIPSHOP)
> >>>      > > >>
> >>>      > > >> Description of Working Group:
> >>>      > > >>
> >>>      > > >> Mobile IPv6 enables IPv6 mobile nodes to continue using a given
> >>>      > > >> "home address" in spite of changes in its point of attachment to
> >>>      > > >> the network. These changes may cause delay, packet loss, and
> >>>     also
> >>>      > > >> represent overhead traffic on the network. The MIPSHOP WG has so
> >>>      > > >> far worked on two technologies to address these issues.
> >>>      > > >> Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency
> >>>      > > >> of signaling between a MN, its Home Agent and one or more
> >>>      > > >> correspondent nodes. Fast Handovers for Mobile IPv6 (FMIPv6)
> >>>      > > >> reduces packet loss by providing fast IP connectivity as soon as
> >>>      > > >> the mobile node establishes a new point of attachment at a new
> >>>      > > >> link.
> >>>      > > >>
> >>>      > > >> The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and
> >>>      > > >> the necessary extensions to improve these protocols. The MIPSHOP
> >>>      > > >> WG will also identify missing components that are required for
> >>>      > > >> deploying these protocols and standardize the necessary
> >>>     extensions.
> >>>      > > >> The WG will also address interworking of these protocols
> >>>     with other
> >>>      > > >> mobility management protocols in the IETF, including
> >>>     network-based
> >>>      > > >> mobility management protocols.
> >>>      > > >>
> >>>      > > >> The IEEE 802.21 Media Independent Handoff (MIH) working
> >>>     group aims
> >>>      > > >> at providing services to assist with handoffs between
> >>>     heterogeneous
> >>>      > > >> link-layer technologies, and across IP subnet boundaries. MIH
> >>>      > > >> services can be delivered through link-layer specific solutions
> >>>      > > >> and/or through a "layer 3 or above" protocol. MIPSHOP will
> >>>     define
> >>>      > > >> the delivery of information for MIH services for this latter
> >>>     case.
> >>>      > > >> A L3 based mechanism to identify a valid information server
> >>>     is also
> >>>      > > >> required. The MIPSHOP will work on developing a protocol for
> >>>      > > >> transport of MIH services information and mechanisms for
> >>>     discovering
> >>>      > > >> the MIH server. Security for the transport of MIH
> >>>     information will
> >>>      > > >> also be addressed.
> >>>      > > >>
> >>>      > > >> The widespread use of different forms of IP tunneling mechanisms
> >>>      > > >> in mobile environment, e.g., MIPv6, HMIPv6, has a negative
> >>>     impact
> >>>      > > >> on the protocol efficiency which is translated in the data
> >>>     packet
> >>>      > > >> size, bandwidth usage and battery power consumption.
> >>>     Therefore, a
> >>>      > > >> mechanism which enables reducing the tunneling overhead would
> >>>      > > >> benefit the mobile node and optimize the bandwidth usage. The
> >>>      > > >> MIPSHOP WG will standardize such a mechanism.
> >>>      > > >>
> >>>      > > >> The MOBOPTS Research Group in the IRTF is chartered to work on
> >>>      > > >> optimizations related to Mobile IPv6 and IP handoffs among other
> >>>      > > >> things. The MIPSHOP WG will take mature proposals from the
> >>>     MOBOPTS
> >>>      > > >> group and standardize them in the IETF on a case-by-case basis.
> >>>      > > >>
> >>>      > > >> The MIPSHOP WG will also consider and standardize
> >>>     optimizations for
> >>>      > > >> the Mobile IPv6 protocol and IP mobility in general.
> >>>      > > >>
> >>>      > > >> Scope of MIPSHOP:
> >>>      > > >>
> >>>      > > >> The working group will:
> >>>      > > >>
> >>>      > > >> 1. Complete the current set of documents with the IESG
> >>>      > > >> - HMIPv6 (draft-ietf-mipshop-4140bis)
> >>>      > > >> - FMIPv6 (draft-ietf-mipshop-fmipv6-rfc4068bis)
> >>>      > > >> - FMIPv6 over IEEE 802.16e (draft-ietf-mipshop-fh80216e)
> >>>      > > >> - FMIPv6 over 3G CDMA 2000 (draft-ietf-mipshop-3gfh)
> >>>      > > >> - MIH problem statement (draft-ietf-mipshop-mis-ps)
> >>>      > > >>
> >>>      > > >> 2. FMIPv6 Mobile Node - Access Router security using the AAA
> >>>      > > >> infrastructure
> >>>      > > >>
> >>>      > > >> Currently MIPSHOP has produced a standards track protocol for
> >>>      > > >> setting up security between the mobile node and access router
> >>>      > > >> for security FMIPv6 signaling messages. However, the protocol
> >>>      > > >> depends on SeND (Secure Neighbor Discovery) to be available on
> >>>      > > >> the mobile node and the access router. An alternate mechanism
> >>>      > > >> that leverages the AAA infrastructure is required. Many target
> >>>      > > >> systems where FMIPv6 is likely to be used use a AAA
> >>>      > > >> infrastructure to authenticate and authorize network access.
> >>>      > > >>
> >>>      > > >> 3. Prefix Management for point-to-point links
> >>>      > > >>
> >>>      > > >> Using FMIPv6 over point-to-points like requires some additional
> >>>      > > >> considerations with respect to managing and allocating prefixes
> >>>      > > >> for the mobile node on these point-to-point links. Therefore
> >>>      > > >> the WG will work on a BCP to document these considerations.
> >>>      > > >>
> >>>      > > >> 4. Use of FMIPv6 with Proxy Mobile IPv6
> >>>      > > >>
> >>>      > > >> Proxy Mobile IPv6 (PMIPv6) is a network-based mobility
> >>>      > > >> management protocol where a node in the access network, called
> >>>      > > >> the Mobile Access Gateway (MAG) handles mobility on behalf of
> >>>      > > >> the mobile node. It has been proposed to use FMIPv6 to
> >>>      > > >> optimize the handover in terms of reducing the packet loss and
> >>>      > > >> transferring relevant context from the old MAG to the new MAG.
> >>>      > > >> The working group will work on specifying FMIPv6 extensions to
> >>>      > > >> enable fast handovers for PMIPv6.
> >>>      > > >>
> >>>      > > >> 5. Work on protocols and extensions for transporting information
> >>>      > > >> related to IEEE 802.21:
> >>>      > > >>
> >>>      > > >> The work includes the layer 3 protocol for transporting MIH
> >>>      > > >> related information and DHCP and DNS extensions for discovery
> >>>      > > >> the information servers.
> >>>      > > >>
> >>>      > > >> 6. IP Tunneling Optimization
> >>>      > > >>
> >>>      > > >> Work on a mechanism to reduce the tunneling overhead associated
> >>>      > > >> with protocols like Mobile IPv6 and HMIPv6.
> >>>      > > >>
> >>>      > > >> 7. Standardize mature proposals from the MOBOPTS IRTF Group
> >>>      > > >>
> >>>      > > >>
> >>>      > > >> Goals and Milestones:
> >>>      > > >>
> >>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-hmip-xx.txt
> >>>      > > >> Done Working Group Last Call on
> >>>      > > >> draft-ietf-mipshop-lmm-requirements-XX.txt
> >>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-fmipv6-xx.txt
> >>>      > > >> Done Discuss Last Call comments and security analyses at IETF 58
> >>>      > > >> Done Submit draft draft-ietf-mipshop-lmm-requirements-XX.txt
> >>>     to IESG
> >>>      > > >> for publication as Informational
> >>>      > > >> Done Submit draft-ietf-mipshop-fmipv6-xx.txt to IESG for
> >>>     publication
> >>>      > > >> as Experimental
> >>>      > > >> Done Submit draft-ietf-mipshop-hmip-xx.txt to IESG for
> >>>     publication
> >>>      > > >> as Experimental
> >>>      > > >> Done Working Group Last Call on
> >>>     draft-ietf-mipshop-80211fh-xx.txt
> >>>      > > >> for Informational
> >>>      > > >> Done Submit draft-ietf-mipshop-80211fh-xx.txt to IESG for
> >>>      > > >> publication as Informational
> >>>      > > >> Done Working Group Last Call on
> >>>     draft-ietf-mipshop-cga-cba-XX.txt
> >>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-mis-ps
> >>>      > > >> Done Submit draft-ietf-mipshop-cga-cba to the IESG for
> >>>     publication
> >>>      > > >> as Proposed Standard
> >>>      > > >> Done Working Group Last Call on
> >>>     draft-ietf-mipshop-fmipv6-rfc4068bis
> >>>      > > >> Done Working Group Last Call on
> >>>     draft-ietf-mipshop-handover-key-send
> >>>      > > >> Done Submit draft-ietf-mipshop-mis-ps to the IESG for
> >>>     publication as
> >>>      > > >> Informational RFC
> >>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-rfc4041bis
> >>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-3gfh
> >>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-fh80216e
> >>>      > > >> Done Submit draft-ietf-mipshop-fmipv6-rfc4068bis to the IESG
> >>>     for
> >>>      > > >> publication as Proposed Standard
> >>>      > > >> Done Submit draft-ietf-mipshop-handover-key-send to the IESG
> >>>     for
> >>>      > > >> publication as Proposed Standard
> >>>      > > >> Done Submit draft-ietf-mipshop-3gfh to IESG for publication as
> >>>      > > >> Informational RFC
> >>>      > > >> Done Submit draft-ietf-mipshop-fh80216e to IESG for
> >>>     publication as
> >>>      > > >> Informational RFC
> >>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-mih-support
> >>>      > > >> Apr 2008 Submit draft-ietf-mipshop-4140bis to the IESG for
> >>>      > > >> publication as Proposed Standard
> >>>      > > >> Apr 2008 Submit draft-ietf-mipshop-mih-support to the IESG for
> >>>      > > >> publication as Proposed Standard
> >>>      > > >> May 2008 Working Group Last Call on
> >>>     draft-ietf-mipshop-mos-dns-discovery
> >>>      > > >> May 2008 Working Group Last Call on
> >>>     draft-ietf-mipshop-mos-dhcp-options
> >>>      > > >> Jun 2008 Working group last call on
> >>>     draft-ietf-mipshop-fmipv6-ptp
> >>>      > > >> Jun 2008 Submit draft-ietf-mipshop-mos-dns-discovery to the
> >>>     IESG for
> >>>      > > >> publication as Proposed Standard
> >>>      > > >> Jun 2008 Submit draft-ietf-mipshop-mos-dhcp-options to the
> >>>     IESG for
> >>>      > > >> publication as Proposed Standard
> >>>      > > >> Jul 2008 Working Group Last Call on draft-ietf-mipshop-pfmipv6
> >>>      > > >> Jul 2008 Submit draft-ietf-mipshop-fmipv6-ptp to the IESG for
> >>>      > > >> publication as Best Current Practice
> >>>      > > >> Aug 2008 Submit draft-ietf-mipshop-pfmipv6 to the IESG for
> >>>      > > >> publication as Proposed Standard
> >>>      > > >> Aug 2008 Working Group Last Call on
> >>>     draft-ietf-mipshop-fmipv6-aaa-key
> >>>      > > >> Oct 2008 Submit draft-ietf-mipshop-fmipv6-aaa-key to the
> >>>     IESG for
> >>>      > > >> publication as Proposed Standard
> >>>      > > >> Nov 2008 Working Group Last call on
> >>>      > > >> draft-ietf-mipshop-tunneling-optimization
> >>>      > > >> Jan 2009 Submit draft-ietf-mipshop-tunneling-optimization to
> >>>     the the
> >>>      > > >> IESG
> >>>      > > >>
> >>>      > > >>
> >>>     ---------------------------------------------------------------------------
> >>>      > > >>
> >>>      > > >> Vijay
> >>>      > > >> _______________________________________________
> >>>      > > >> Mipshop mailing list
> >>>      > > >> [e-mail]
> >>>      > > >> https://www.ietf.org/mailman/listinfo/mipshop
> >>>      > > >>
> >>>      > >
> >>>      > >
> >>>      > _______________________________________________
> >>>      > Mipshop mailing list
> >>>      > [e-mail]
> >>>      > https://www.ietf.org/mailman/listinfo/mipshop
> >>>
> >>>     ------------------------------------------------------------------------
> >>>     Climb to the top of the charts! Play the word scramble challenge
> >>>     with star power. Play now!
> >>>     <http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan>
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------
> >>> Shed those extra pounds with MSN and The Biggest Loser! Learn more. 
> >>> <http://biggestloser.msn.com/>
> >> _______________________________________________
> >> Mipshop mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mipshop
> >>
> 
> 
_______________________________________________
Mipshop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mipshop