Subject: [Mipshop] Proposed new charter

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Mar 2008 16:18:44 -0800

Hello folks,

Here is the first draft of the text for a new charter for the
MIPSHOP WG. Please review and comment.

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

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 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. 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 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 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 IESG for 
publication as Proposed Standard
Done     Submit draft-ietf-mipshop-handover-key-send to 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 IESG for publication 
as Proposed Standard
Apr 2008     Submit draft-ietf-mipshop-mih-support to 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 IESG for 
publication as Proposed Standard
Jun 2008     Submit draft-ietf-mipshop-mos-dhcp-options to 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 IESG for 
publication as Best Current Practice
Aug 2008     Submit draft-ietf-mipshop-pfmipv6 to 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 IESG for 
publication as Proposed Standard

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

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 11 Mar 2008 15:12:18 -0700

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)

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.

Scope of MIPSHOP:

The working group will:

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

---

From: Frank Xia <[email-masked]>
Date: Tue, 11 Mar 2008 18:30:58 -0500

Hi Vijay

For Tunnel Optimization, why should we limit in Mobile IPv6 and HMIP6?

I think it is also possible for PMIPv6 and Mobile IPv4.
 
BR
Frank

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 11 Mar 2008 15:29:46 -0700

> 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.

> 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

---

From: Frank Xia <[email-masked]>
Date: Tue, 11 Mar 2008 18:38:52 -0500

Hi Vijay

Please see my reply..

BR
Frank
----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "'Mipshop'" <[email-masked]>
Sent: Tuesday, March 11, 2008 5:29 PM
Subject: Re: [Mipshop] Proposed new charter

> It wasn't meant to be an exhaustive list of protocols that
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.

---

From: <[email-masked]>
Date: Wed, 12 Mar 2008 08:32:38 +0000

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: [email-masked]> To: [email-masked]> CC: [email-masked]> Subject: Re: [Mipshop] Proposed new charter> > Hi Vijay> > Please see my reply..> > BR> Frank> ----- Original Message ----- > From: "Vijay Devarapalli" <[email-masked]>> To: "Frank Xia" <[email-masked]>> Cc: "'Mipshop'" <[email-masked]>> 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" <[email-masked]>> > > To: "'Mipshop'" <[email-masked]>> > > 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> > >> [email-masked]> > >> https://www.ietf.org/mailman/listinfo/mipshop> > >>> > > > > _______________________________________________> Mipshop mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/mipshop
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 12 Mar 2008 08:01:17 -0700

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: [email-masked] on behalf of [email-masked]
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: [email-masked]
> To: [email-masked]
> CC: [email-masked]

________________________________

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>  
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: <[email-masked]>
Date: Wed, 12 Mar 2008 15:54:30 +0000

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 charterDate: Wed, 12 Mar 2008 08:01:17 -0700From: [email-masked]: [email-masked]; [email-masked]: [email-masked]

Dear Zarraf,

From: [email-masked] on behalf of [email-masked]: Wed 3/12/2008 1:32 AMTo: Frank Xia; Vijay DevarapalliCc: '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: [email-masked]> To: [email-masked]> CC: [email-masked]> Subject: Re: [Mipshop] Proposed new charter> > Hi Vijay> > Please see my reply..> > BR> Frank> -…

Climb to the top of the charts! Play the word scramble challenge with star power. Play now! 
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Mar 2008 11:40:26 -0700

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

[email-masked] 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
>     Subject: RE: [Mipshop] Proposed new charter
>     Date: Wed, 12 Mar 2008 08:01:17 -0700
>     From: [email-masked]
>     To: [email-masked]; [email-masked]
>     CC: [email-masked]
> 
>     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:* [email-masked] on behalf of [email-masked]
>     *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
> 
> 
> 
> 
>     draft-ietf-mipshop-80211fh-xx.txt
>      > > >> for Informational
>     draft-ietf-mipshop-cga-cba-XX.txt
>     draft-ietf-mipshop-fmipv6-rfc4068bis
>     draft-ietf-mipshop-handover-key-send
>     <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/>

---

From: Frank Xia <[email-masked]>
Date: Wed, 12 Mar 2008 14:53:32 -0500

Hi Vijay

I would like to suggest that PMIPv6 is in the scope.

BR
Frank

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Mar 2008 11:52:59 -0700

> 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

---

From: Frank Xia <[email-masked]>
Date: Wed, 12 Mar 2008 17:02:08 -0500

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Mar 2008 14:11:12 -0700

> I don't  think it is necessary to exclude the possibility of  PMIPv6 application.

If it is possible to re-use the solution we develop for
PMIPv6 also, great. But we are not going to focus on
PMIPv6 or FMIPv6 for now.

Vijay

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 12 Mar 2008 14:23:56 -0700

Frank,
I definitely agree with Vijay. In a wireless communication, the bottleneck is mostly on the radio leg, therefore it is important to optimize the tunnel over the radio. As Vijay correctly says below, PMIP does not tunnel over the radio, so we should not focus on it for the time being. I would suggest we solve one problem at a time.
Cheers,
Stefano

From: [email-masked] on behalf of Vijay Devarapalli
Sent: Wed 3/12/2008 2:11 PM
To: Frank Xia
Cc: Mipshop; [email-masked]
Subject: Re: [Mipshop] Proposed new charter

Vijay

---

From: Frank Xia <[email-masked]>
Date: Wed, 12 Mar 2008 21:13:54 -0500

Re: [Mipshop] Proposed new charterHi Stefano and Vijay

If you say tunnel optimization is only for radio,
I don't agree.

Header compression is popular practice in the industry.
IMO, if we only focus on this, I think we can benefit little for our effort.

BR
Frank
  ----- Original Message ----- 
  From: Stefano Faccin 
  To: Vijay Devarapalli ; Frank Xia 
  Cc: Mipshop ; [email-masked] 
  Sent: Wednesday, March 12, 2008 4:23 PM
  Subject: RE: [Mipshop] Proposed new charter

  Frank,

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

  Vijay

---

From: <[email-masked]>
Date: Thu, 13 Mar 2008 13:28:55 +0000

Hello Stefano and Vijay,
 
I would support Frank in his argument regarding expanding the scope and focus of the charter. I would like to stress again that we need to have a holistic look at the tunneling optimization issue. IMO when we talk about the tunneling overhead, it should also encompass all other exchange of protocol messages that is exchanged "while" the tunnel is established and not confine the specifics of the charter for messages that go "through" the tunnel only.....
 
The charter should allow tackling the issue at two parallel and synchronous tiers:
 
1. To reduce the tunneling overhead over the air link (as per the original charter suggestion)
2. To optimize the tunnel itself in terms of the processing delay and resource consumption.
 
I think that managing the two issues together is very important as they depend on each other and MAY have affects on each other. 
 
In view of the fact that we already have ideas and/or drafts to support the above two issues, taking upon the two issues together would quicken the pace of standardization and optimization.
 
I hope to get some performance results in a little more than a month regarding the second aspect and will share the result with the members.
 
BR
 
Zarrar Yousaf

Date: Wed, 12 Mar 2008 21:13:54 -0500From: [email-masked]: [email-masked]; [email-masked]: [email-masked]; [email-masked]: Re: [Mipshop] Proposed new charter

Hi Stefano and Vijay

BR
Frank

----- Original Message ----- 
From: Stefano Faccin 
To: Vijay Devarapalli ; Frank Xia 
Cc: Mipshop ; [email-masked] 
Sent: Wednesday, March 12, 2008 4:23 PM
Subject: RE: [Mipshop] Proposed new charter

Frank,

From: [email-masked] on behalf of Vijay DevarapalliSent: Wed 3/12/2008 2:11 PMTo: Frank XiaCc: Mipshop; [email-masked]: Re: [Mipshop] Proposed new charter

Frank Xia wrote:> 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.If it is possible to re-use the solution we develop forPMIPv6 also, great. But we are not going to focus onPMIPv6 or FMIPv6 for now.Vijay>> BR> Frank>> ----- Original Message -----> From: "Vijay Devarapalli" <[email-masked]>> To: "Frank Xia" <[email-masked]>> Cc: <[email-masked]>; <[email-masked]>; "Mipshop" <[email-masked]>> 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" <[email-masked]>>>> To: <[email-masked]>>>> Cc: <[email-masked]>; "Mipshop" <[email-masked]>>>> 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>>>>>>>> [email-masked] 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: [email-masked]>>>>>     To: [email-masked]; [email-masked]>>>>>     CC: [email-masked]>>>>>>>>>>     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:* [email-masked] on behalf of [email-masked]>>>>>     *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: [email-masked]>>>>>      > To: [email-masked]>>>>>      > CC: [email-masked]>>>>>      > Subject: Re: [Mipshop] Proposed new charter>>>>>      >>>>>>      > Hi Vijay>>>>>      >>>>>>      > Please see my reply..>>>>>      >>>>>>      > BR>>>>>      > Frank>>>>>      > ----- Original Message ----->>>>>      > From: "Vijay Devarapalli" <[email-masked]>>>>>>      > To: "Frank Xia" <[email-masked]>>>>>>      > Cc: "'Mipshop'" <[email-masked]>>>>>>      > 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" <[email-masked]>>>>>>      > > > To: "'Mipshop'" <[email-masked]>>>>>>      > > > 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>>>>>      > > >> [email-masked]>>>>>      > > >> https://www.ietf.org/mailman/listinfo/mipshop>>>>>      > > >>>>>>>      > >>>>>>      > >>>>>>      > _______________________________________________>>>>>      > Mipshop mailing list>>>>>      > [email-masked]>>>>>      > 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>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/mipshop>>>>>>_______________________________________________Mipshop mailing [email-masked]://www.ietf.org/mailman/listinfo/mipshop
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join

---

From: "Stefano Faccin" <[email-masked]>
Date: Thu, 13 Mar 2008 08:50:17 -0700

Zarrar,
I am not disagreeing with you that optimizing the various tunnels and related procedure is an interesting and potentially useful work.
 
However, the tunnel optimization work is coming to us from MEXT, where there was extensive discussion and a good consensus built. If we want to extend the work beyond what already has consensus, we need to go through a wide discussion that may delay considerably our ability to adopt the new charter and definitely delay the rest of the work. I am not sure this is the best way forward for the working group. We could proceed in stages, i.e. optimizing first the tunnels over the air, then in a later phase (rechartering) focus on other tunnel optimizations.
 
Cheers,
Stefano

From: [email-masked] [mailto:[email-masked]]
Sent: Thu 3/13/2008 6:28 AM
To: Frank Xia; Stefano Faccin; Vijay Devarapalli
Cc: Mipshop; [email-masked]
Subject: RE: [Mipshop] Proposed new charter

Hello Stefano and Vijay,

 

 
 
BR
 
Zarrar Yousaf

	Date: Wed, 12 Mar 2008 21:13:54 -0500
	From: [email-masked]
	To: [email-masked]; [email-masked]
	CC: [email-masked]; [email-masked]
	Subject: Re: [Mipshop] Proposed new charter

	Hi Stefano and Vijay

	BR
	Frank

		----- Original Message ----- 
		From: Stefano Faccin <mailto:[email-masked]>  
		To: Vijay Devarapalli <mailto:[email-masked]>  ; Frank Xia <mailto:[email-masked]>  
		Cc: Mipshop <mailto:[email-masked]>  ; [email-masked] 
		Sent: Wednesday, March 12, 2008 4:23 PM
		Subject: RE: [Mipshop] Proposed new charter

		Frank,

		
		
		Vijay

Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. <http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join>  
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 18 Mar 2008 10:56:37 +0200

>     enable fast handovers for PMIPv6.

I'm guessing that we are not talking about the host using FMIPv6, as we have
been saying host is neither aware nor capable of L3 mobility management. If
all we are interested in is "context transfer for PMIPv6", then let's say
so. Whether the solution may be simply reusing some parts of FMIPv6 protocol
is a discussion to have later.

Alper

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 18 Mar 2008 22:17:34 +0900

Hi Alper,

> is a discussion to have later.

One thing I would like to point out is that when you try to apply the 
FMIPv6 concept to PMIPv6, information exchange between ARs (MAGs) is 
inevitable since the mobile node is not involved in either its mobility 
or fast handover. FMIPv6 supports packet forwarding from the PAR to NAR 
and the NAR (New MAG) needs to know beforehand about, for example, the 
MN-HoA to distinguish the forwarded packets. Such information needs to 
be transferred from the PAR to NAR. The goal is fast handover and the 
information exchange between ARs is a means for that and not separable. 
Just highlighting the context transfer feature is not our intention and 
could be misleading.

I would appreciate your understanding.

Regards,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 18 Mar 2008 09:43:15 -0500

> > I'm guessing that we are not talking about the host using 
> FMIPv6, as 
> > we have been saying host is neither aware nor capable of L3 
> mobility 
> > management. If all we are interested in is "context transfer for 
> > PMIPv6", then let's say so. Whether the solution may be 
> simply reusing 
> > some parts of FMIPv6 protocol is a discussion to have later.
> 
> FMIPv6 concept to PMIPv6, information exchange between ARs 
> (MAGs) is inevitable since the mobile node is not involved in 
> either its mobility or fast handover. FMIPv6 supports packet 
> forwarding from the PAR to NAR and the NAR (New MAG) needs to 
> know beforehand about, for example, the MN-HoA to distinguish 
> the forwarded packets. Such information needs to be 
> transferred from the PAR to NAR. The goal is fast handover 
> and the information exchange between ARs is a means for that 
> and not separable. 
> Just highlighting the context transfer feature is not our 
> intention and could be misleading.
> 

[Ahmad]
Hi Hidetoshi,

I understand your point, but unfortunately that is the problem.
You are proposing a solution that requires a heavy weight additional
packaging and trying to enforce this as the best possible solution for
PMIPv6 handover while it has nothing to do with PMIPv6 protocol.
Unfortunately, many people think that is not a good idea!

Despite the fact that the proposed solution does not have any impact
what so ever on PMIPv6 and it could be used regardless of the network
local mobility management protocol between the MAG and the LMA, e.g.
PMIPv4, this solution also couples the proposed handover mechanism with
a very specific Context Transfer solution. IMO, handover optimization
mechanism MUST work independently of the CT.

Best Regards,
Ahmad

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 18 Mar 2008 16:55:37 +0200

Hi Hidetoshi,

Right, I missed the tunneling aspect in my e-mail. I guess you are
implicitly referring to an I-D in your message. I'd appreciate if you can
send me the pointer.

Thanks.

Alper

> -----Original Message-----
> From: Hidetoshi Yokota [mailto:[email-masked]]
> Sent: Tuesday, March 18, 2008 3:18 PM
> To: Alper Yegin
> Cc: 'Vijay Devarapalli'; 'Mipshop'

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Mar 2008 11:37:17 -0700

Hi Alper,

<chair hat on>

The work we are considering to add to the MIPSHOP charter currently
is rather very specific in scope. It is about using the FMIPv6
signaling messages to setup forwarding for packets between the MAGs
during a  PMIPv6 handover. The context is transferred as part of
signaling between the MAGs. The following draft was assumed.
http://www.ietf.org/internet-drafts/draft-yokota-mipshop-pfmipv6-02.txt
I also came to know that this document is now on the 3GPP2-IETF
dependency list. So 3GPP2 wants the IETF to standardize this draft.

Now I see that there is some interest in generic PMIPv6 handover
optimizations. Not necessarily just on avoiding packet loss during
the handover or transferring the context between the MAGs. Some of
the optimizations involve changes at the LMA. It is also not clear
whether some of the optimizations fit in MIPSHOP or NETLMM.

So, now we need to discuss whether we should expand the scope for
the work in MIPSHOP (something like PMIPv6 handover optimizations).
Or stick to the current narrow scope. I would like to see this
discussion happen ASAP, since I don't want MIPSHOP re-chartering
delay too much.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Mar 2008 11:41:07 -0700

Ahmad Muhanna wrote:

> packaging 

I wouldn't call the exchange of HI and HAck messages between
the MAGs heavy weight.

Vijay

> and trying to enforce this as the best possible solution for

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 18 Mar 2008 15:23:07 -0500

> I wouldn't call the exchange of HI and HAck messages between 

[Ahmad]
:-)

I was not necessarily referring to the messages exchange per say. I
actually was referring to the whole mechanism where the exchange of
these messages is part of. Furthermore, In order to have these two
messages exchanged securely, we need to have The followings:

1. A MAG-to-MAG SA, which is not necessarily needed if other approaches
are used.

2. The use of these messages are coupled with CT which means that it is
very restrictive in nature. 

3. These messages are ICMP messages and many operators do not like to
exchange sensitive information using ICMP messages, i.e. some operators
disable ICMP signaling all together.

4. The solution has no impact on PMIPv6 and it could very well be used
when PMIPv4 is used.

I personally have no problem if this is considered as a generic
mechanism for a lateral bi-directional tunnel setup between AR.
 
> > PMIPv4, this solution also couples the proposed handover mechanism 
> > with a very specific Context Transfer solution. IMO, handover 
> > optimization mechanism MUST work independently of the CT.
> > 
> > Best Regards,
> > Ahmad
> > 
> >> Regards,
> >> --
> >> Hidetoshi
> >>
> >>> Alper
> >>>
> >>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 18 Mar 2008 15:39:13 -0500

> Now I see that there is some interest in generic PMIPv6 
> handover optimizations. Not necessarily just on avoiding 
> packet loss during the handover or transferring the context 
> between the MAGs. Some of the optimizations involve changes 
> at the LMA. It is also not clear whether some of the 
> optimizations fit in MIPSHOP or NETLMM.

[Ahmad]
I believe all the proposed solution on Netlmm requires a change to the
PMIP BCE. I believe that they naturally belong to Netlmm and I would
support that these approaches be addressed at Netlmm wg.

> 
> So, now we need to discuss whether we should expand the scope 
> for the work in MIPSHOP (something like PMIPv6 handover 
> optimizations).
> Or stick to the current narrow scope. I would like to see 
> this discussion happen ASAP, since I don't want MIPSHOP 
> re-chartering delay too much.
> 
> Vijay
> 
> Alper Yegin wrote:
> > Hi Hidetoshi,
> > 
> > implicitly referring to an I-D in your message. I'd 
> appreciate if you 
> > can send me the pointer.
> > 
> > Thanks.
> > 
> > Alper
> > 
> >>> we
> >> have
> >>> been saying host is neither aware nor capable of L3 
> mobility management.
> >> If
> >>> all we are interested in is "context transfer for PMIPv6", then 
> >>> let's
> >> say
> >>> so. Whether the solution may be simply reusing some parts 
> of FMIPv6
> >> protocol
> (MAGs) is 
> >> inevitable since the mobile node is not involved in either its 
> >> mobility or fast handover. FMIPv6 supports packet 
> forwarding from the 
> >> PAR to NAR and the NAR (New MAG) needs to know beforehand 
> about, for 
> >> example, the MN-HoA to distinguish the forwarded packets. Such 
> >> information needs to be transferred from the PAR to NAR. 
> The goal is 
> >> fast handover and the information exchange between ARs is 
> a means for that and not separable.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Mar 2008 14:34:57 -0700

Hi Ahmad,

Let me see if I understand what you are saying. You are ok with
MIPSHOP taking on a work item on setting up "a lateral
bi-directional tunnel" between the MAGs, but want to do the
other PMIPv6 handover optimizations in the NETLMM WG. Right?

> support that these approaches be addressed at Netlmm wg.

This isn't really a strong reason for arguing against doing
the handover optimizations in the MIPSHOP WG. But we will come
to that later, once we figure out what exactly we would be
optimizing.

Vijay

---

From: "Rajeev Koodli" <[email-masked]>
Date: Tue, 18 Mar 2008 16:37:51 -0700

Hi,

> dependency list. So 3GPP2 wants the IETF to standardize this draft.

This is about using FMIP when PMIP is used. (Folks may recall 4068/4068bis
assume MIP).
This means bidirectional tunnel set up. The (HI/Hack) messages carry
information necessary for handover just as they do in 4068 (where the
MN-CoA, MN-LLA etc are supplied).

I would like to see this specified here.

If there is interest in broader work, that should be discussed on its own,
separately, IMO.

-Rajeev

> >>> I'm guessing that we are not talking about the host using FMIPv6, as
> we
> >> have
> >>> been saying host is neither aware nor capable of L3 mobility
> management.
> >> If

---

From: <[email-masked]>
Date: Tue, 18 Mar 2008 23:19:02 -0500

Hi All,

Is there a SWAG on  the effect on schedule for the MSTP work if
additional scop is included here? How about a SWAG for the schedule
effect towards all outstanding PMIP work not yet completed in netlmm?

Best Regards,
Michael

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Ahmad Muhanna
>Sent: 18 March, 2008 16:39
>To: Vijay Devarapalli; Alper Yegin
>Cc: Mipshop
>> optimizations. Not necessarily just on avoiding packet loss 
>during the 
>> handover or transferring the context between the MAGs. Some of the 
>> optimizations involve changes at the LMA. It is also not 
>clear whether 
>> some of the optimizations fit in MIPSHOP or NETLMM.
>
>[Ahmad]
>I believe all the proposed solution on Netlmm requires a 
>change to the PMIP BCE. I believe that they naturally belong 
>to Netlmm and I would support that these approaches be 
>addressed at Netlmm wg.
>
>> 
>> So, now we need to discuss whether we should expand the 
>scope for the 
>> work in MIPSHOP (something like PMIPv6 handover optimizations).
>> discussion happen ASAP, since I don't want MIPSHOP 
>re-chartering delay 
>> too much.
>> 
>> Vijay
>> 
>> Alper Yegin wrote:
>> > Hi Hidetoshi,
>> >

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 19 Mar 2008 11:35:41 +0100

I think the need for optimizations as being proposed to NetLMM is
obvious and the topic addresses a broader scope compared to FMIP
for PMIP. My major interest is in getting extensions to PMIPv6 such
as proposed in our and other drafts standardized. *Where* this work
is actually done is not too relevant, whether it's MIPSHOP or
NetLMM.

However, currently available mechanisms
(draft-liebsch-netlmm-intertech-proxymip6ho,
draft-muhanna-netlmm-pmipv6-support-transient and
draft-blume-netlmm-secondary-bce-proxymip6ho) propose advanced
binding management, which is also needed for a further work item, that
has been proposed to NetLMM. This is about
"PMIPv6 multihoming and Multiple Interfaces related hand-off issues".
Even though this work may comprise rather an analysis of issues being
associated with multi-mode device operation, it might be preferable to
specify solutions for these issues in the same WG where the issues are
discussed.

marco

Vijay Devarapalli schrieb:
>>>>>>>     management protocol where a node in the access 
>>>>>>>               
>>> network, called
>>>       
>>>>>>>     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
>>>       
>>>>> One thing I would like to point out is that when you try 
>>>>>           
>>> to apply the
>>>       
>>> intention 
>>>>> and could be misleading.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 19 Mar 2008 06:08:15 -0500

Hi Vijay,

I am not against addressing PMIPv6 handover optimization per say in
MIPSHOP, however, I do not like the proposed solution using FMIPv6. IMO,
that is too restrictive, limited to a very specific deployment, and
couples CT with Handover optimization solution which IMO, not a good
idea. Again, I believe that handover optimization SHOULD be independent
of CT mechanism.

Having said this, I believe that, although the other proposals,
transient registration, etc.  are categorized under handover
optimization but they still considered as an enhancement to PMIPv6
registration, introduces new options, and update the PMIPv6 BCE. I
strongly believe that a mechanism like transient registration belongs to
Netlmm wg. Additionally, this work item needs to be considered as part
of the current Netlmm priorities. 

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, March 18, 2008 4:35 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Alper Yegin; Mipshop
> Let me see if I understand what you are saying. You are ok 
> with MIPSHOP taking on a work item on setting up "a lateral 
> change to the 
> the handover optimizations in the MIPSHOP WG. But we will 
> come to that later, once we figure out what exactly we would 
> be optimizing.
> 
> Vijay
> 
> >

---

From: <[email-masked]>
Date: Wed, 19 Mar 2008 12:23:50 +0000

I think we should also focus on the optimisation of the base FMIPv6 protocol itself alongside its integrated operation with PMIP.
IMO there are issues related to tunneling overhead, which i have brought up previously, and there are solutions proposed (such as https://datatracker.ietf.org/drafts/draft-yousaf-ietf-mipshop-pbfmipv6/) and i think we should also attend to such proposals and bring it under the scope of the FMIPv6 standardization.
 
Zarrar Yousaf

> Date: Wed, 19 Mar 2008 11:35:41 +0100> From: [email-masked]> To: [email-masked]> CC: [email-masked]> Subject: Re: [Mipshop] Proposed new charter> > I think the need for optimizations as being proposed to NetLMM is> obvious and the topic addresses a broader scope compared to FMIP> for PMIP. My major interest is in getting extensions to PMIPv6 such> as proposed in our and other drafts standardized. *Where* this work> is actually done is not too relevant, whether it's MIPSHOP or> NetLMM.> > However, currently available mechanisms> (draft-liebsch-netlmm-intertech-proxymip6ho,> draft-muhanna-netlmm-pmipv6-support-transient and> draft-blume-netlmm-secondary-bce-proxymip6ho) propose advanced> binding management, which is also needed for a further work item, that> has been proposed to NetLMM. This is about> "PMIPv6 multihoming and Multiple Interfaces related hand-off issues".> Even though this work may comprise rather an analysis of issues being> associated with multi-mode device operation, it might be preferable to> specify solutions for these issues in the same WG where the issues are> discussed.> > marco> > > > Vijay Devarapalli schrieb:> > Hi Ahmad,> >> > Let me see if I understand what you are saying. You are ok with> > MIPSHOP taking on a work item on setting up "a lateral> > bi-directional tunnel" between the MAGs, but want to do the> > other PMIPv6 handover optimizations in the NETLMM WG. Right?> >> > Ahmad Muhanna wrote:> > > >>> Subject: Re: [Mipshop] Proposed new charter> >>>> >>> Hi Alper,> >>>> >>> <chair hat on>> >>>> >>> Now I see that there is some interest in generic PMIPv6 > >>> handover optimizations. Not necessarily just on avoiding > >>> packet loss during the handover or transferring the context > >>> between the MAGs. Some of the optimizations involve changes > >>> at the LMA. It is also not clear whether some of the > >>> optimizations fit in MIPSHOP or NETLMM.> >>> > >> [Ahmad]> >> I believe all the proposed solution on Netlmm requires a change to the> >> PMIP BCE. I believe that they naturally belong to Netlmm and I would> >> support that these approaches be addressed at Netlmm wg.> >> > >> > This isn't really a strong reason for arguing against doing> > the handover optimizations in the MIPSHOP WG. But we will come> > to that later, once we figure out what exactly we would be> > optimizing.> >> > Vijay> >> > > >>> So, now we need to discuss whether we should expand the scope > >>> for the work in MIPSHOP (something like PMIPv6 handover > >>> optimizations).> >>> Or stick to the current narrow scope. I would like to see > >>> this discussion happen ASAP, since I don't want MIPSHOP > >>> re-chartering delay too much.> >>>> >>> Vijay> >>>> >>> Alper Yegin wrote:> >>> > >>>> Hi Hidetoshi,> >>>>> >>>> Right, I missed the tunneling aspect in my e-mail. I guess you are > >>>> implicitly referring to an I-D in your message. I'd > >>>> > >>> appreciate if you > >>> > >>>> can send me the pointer.> >>>>> >>>> Thanks.> >>>>> >>>> Alper> >>>>> >>>> > >>>>> -----Original Message-----> >>>>> From: Hidetoshi Yokota [mailto:[email-masked]]> >>>>> Sent: Tuesday, March 18, 2008 3:18 PM> >>>>> To: Alper Yegin> >>>>> Cc: 'Vijay Devarapalli'; 'Mipshop'> >>>>> Subject: Re: [Mipshop] Proposed new charter> >>>>>> >>>>> Hi Alper,> >>>>>> >>>>> Alper Yegin wrote:> >>>>> > >>>>>>> 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.> >>>>>>> > >>>>>> I'm guessing that we are not talking about the host using > >>>>>> > >>> FMIPv6, as > >>> > >>>>>> we> >>>>>> > >>>>> have> >>>>> > >>>>>> been saying host is neither aware nor capable of L3 > >>>>>> > >>> mobility management.> >>> > >>>>> If> >>>>> > >>>>>> all we are interested in is "context transfer for PMIPv6", then > >>>>>> let's> >>>>>> > >>>>> say> >>>>> > >>>>>> so. Whether the solution may be simply reusing some parts > >>>>>> > >>> of FMIPv6> >>> > >>>>> protocol> >>>>> > >>>>>> is a discussion to have later.> >>>>>> > >>>>> One thing I would like to point out is that when you try > >>>>> > >>> to apply the> >>> > >>>>> FMIPv6 concept to PMIPv6, information exchange between ARs > >>>>> > >>> (MAGs) is > >>> > >>>>> inevitable since the mobile node is not involved in either its > >>>>> mobility or fast handover. FMIPv6 supports packet > >>>>> > >>> forwarding from the > >>> > >>>>> PAR to NAR and the NAR (New MAG) needs to know beforehand > >>>>> > >>> about, for > >>> > >>>>> example, the MN-HoA to distinguish the forwarded packets. Such > >>>>> information needs to be transferred from the PAR to NAR. > >>>>> > >>> The goal is > >>> > >>>>> fast handover and the information exchange between ARs is > >>>>> > >>> a means for that and not separable.> >>> > >>>>> Just highlighting the context transfer feature is not our > >>>>> > >>> intention > >>> > >>>>> and could be misleading.> >>>>>> >>>>> I would appreciate your understanding.> >>>>>> >>>>> Regards,> >>>>> --> >>>>> Hidetoshi> >>>>>> >>>>> > >>>>>> Alper> >>>>>>> >>>>>>> >>>>>> _______________________________________________> >>>>>> Mipshop mailing list> >>>>>> [email-masked]> >>>>>> https://www.ietf.org/mailman/listinfo/mipshop> >>>>>>> >>>>>>> >>>>>> > >>> _______________________________________________> >>> Mipshop mailing list> >>> [email-masked]> >>> https://www.ietf.org/mailman/listinfo/mipshop> >>>> >>> > >> > _______________________________________________> > Mipshop mailing list> > [email-masked]> > https://www.ietf.org/mailman/listinfo/mipshop> > > > > _______________________________________________> Mipshop mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Rajeev Koodli" <[email-masked]>
Date: Wed, 19 Mar 2008 09:47:11 -0700

Hi Ahmad,

> idea. Again, I believe that handover optimization SHOULD be independent

As I mentioned in my previous e-mail, base FMIP specifies parameters to be
exchanged in HI/HAck. Whether you call that CT or something else is not
relevant. We are using a similar set of parameters for PMIP purposes.

And, we defined options for HI/HAck in FMIP. They are meant to be used by
folks. Would you forbid using those options if folks want to exchange
parameters during handover? I would not; it does not make sense. So, it is
not quite accurate to characterize it as coupled with CT! The whole point of
defining options in HI/HAck was to allow extensibility.

In sum, I would like to have FMIP working with PMIP. With the request from
3GPP2, looks like there is a clear need for it.

Regards,

-Rajeev

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 20 Mar 2008 03:08:31 +0900

Hi Ahmad,

Please see inline:

> 1. A MAG-to-MAG SA, which is not necessarily needed if other approaches

The SA between ARs (MAGs) is already addressed in 4068bis, which is the 
base spec for FMIPv6. I haven’t seen or heard any issue with this. In 
the real world also, it is not a hard assumption that ARs have a trust 
relationship. Actually, the secure connection between the ARs doesn’t 
have to be IPSec, but it could employ other mechanisms such as a lower 
layer security protocol or physical protection. I think any mobile 
operator wants to secure its whole network whether FMIP is used or not. 
In the roaming case also, a secure connection is bi-laterally 
established whether FMIP is used or not since customer and 
authentication information is often exchanged. Besides, neither 3GPP nor 
3GPP2 sees that it is an issue. You can see data forwarding between ARs 
(e.g. SGWs or AGWs) during handover in several places.

> very restrictive in nature. 

As I mentioned earlier, since information exchange between ARs is 
necessary for FMIP, I don’t exactly see what restricts what in nature…

> disable ICMP signaling all together.

I don’t think that ICMP is particularly insecure and UDP or TCP is more 
secure. As I mentioned above, the mobile network including the core and 
RAN should be secure in the first place. I think you mean disabling ICMP 
is between the operator’s internal network and the outside network. I 
also think FMIP signaling should not go to the public Internet.

> 4. The solution has no impact on PMIPv6 and it could very well be used

I think it is one advantage of FMIPv6 that it doesn’t have a big impact 
on MIPv6 and I think it is a good idea to maintain this advantage with 
FMIPv6 for PMIPv6. I agree that PMIPv4 and PMIPv6 have the same concept, 
but you can see quite a few differences between them at their protocol 
level, so when you try to apply the fast handover function to PMIPv4, 
you need to consider these differences one by one. We are talking about 
the fast handover not just the context transfer mechanism here.

> mechanism for a lateral bi-directional tunnel setup between AR.

FMIPv6 defines the bi-directional tunnel setup mechanism between ARs, 
and this is for data forwarding. I don’t exactly understand what you 
mean by a generic mechanism and why you have no problem if this is 
assumed...

Regards,
-- 
Hidetoshi

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 19 Mar 2008 20:56:07 +0100

Hi,

2008/3/19, Hidetoshi Yokota <[email-masked]>:
>  base spec for FMIPv6. I haven't seen or heard any issue with this. In
>  relationship. Actually, the secure connection between the ARs doesn't

Just a quick comment regarding trust relationships:
- Having a trust relationship, on one side, between the LMA from an
administrative domain A and a MAG from an administrative domain B, and
having a trust relationship, OTOH, between the LMA from a
administrative domain A and a MAG from an administrative domain C,
doesn't mean that there is a trust relationship between the MAG from B
and the MAG from C.
- I don't remember whether there was a discussion during the FMIPv6
specification, but that was the case during the Context Transfer
Protocol specification in seamoby WG and the conclusion was that CXTP
should only be used for intra-domain mobility.

[snip]

Best regards.

JMC.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 19 Mar 2008 15:58:19 -0500

Hi Rajeev,
Sorry I probably missed your earlier email. Please see one comment
inline.

Regards, 
Ahmad 

	From: Rajeev Koodli [mailto:[email-masked]] 
	Sent: Wednesday, March 19, 2008 11:47 AM
	To: Muhanna, Ahmad (RICH1:2H10)
	Cc: Vijay Devarapalli; Mipshop
	Subject: Re: [Mipshop] Proposed new charter

	Hi Ahmad, 

	On Wed, Mar 19, 2008 at 4:08 AM, Ahmad Muhanna
<[email-masked]> wrote:

		I am not against addressing PMIPv6 handover optimization
per say in
		MIPSHOP, however, I do not like the proposed solution
using FMIPv6. IMO,
		that is too restrictive, limited to a very specific
deployment, and
		couples CT with Handover optimization solution which
IMO, not a good
		idea. Again, I believe that handover optimization SHOULD
be independent
		of CT mechanism.

	As I mentioned in my previous e-mail, base FMIP specifies
parameters to be exchanged in HI/HAck. Whether you call that CT or
something else is not relevant. We are using a similar set of parameters
for PMIP purposes.

	And, we defined options for HI/HAck in FMIP. They are meant to
be used by folks. Would you forbid using those options if folks want to
exchange parameters during handover? I would not; it does not make
sense. So, it is not quite accurate to characterize it as coupled with
CT!  

	[Ahmad]
	Well, then is the use of CT within HI and Hack optional?
	 
	Best Regards,
	Ahmad 
	 
	 The whole point of defining options in HI/HAck was to allow
extensibility. 
	 
	In sum, I would like to have FMIP working with PMIP. With the
request from 3GPP2, looks like there is a clear need for it.

	Regards,

	-Rajeev

		Having said this, I believe that, although the other
proposals,
		transient registration, etc.  are categorized under
handover
		optimization but they still considered as an enhancement
to PMIPv6
		registration, introduces new options, and update the
PMIPv6 BCE. I
		strongly believe that a mechanism like transient
registration belongs to
		Netlmm wg. Additionally, this work item needs to be
considered as part
		of the current Netlmm priorities.
		
		Regards,
		Ahmad

		> > PMIP BCE. I believe that they naturally belong to
Netlmm
		> and I would
re-chartering
		> >> delay too much.
		> >>
		> >> Vijay
		> >>
		> >> Alper Yegin wrote:
		> >>> Hi Hidetoshi,
		> >>>
		> >>> Right, I missed the tunneling aspect in my e-mail.
I
		> guess you are
		> >>>>>>     the Mobile Access Gateway (MAG) handles
mobility
		> on behalf of

---

From: "Rajeev Koodli" <[email-masked]>
Date: Wed, 19 Mar 2008 17:13:24 -0700

On Wed, Mar 19, 2008 at 1:58 PM, Ahmad Muhanna <[email-masked]> wrote:

>  As I mentioned in my previous e-mail, base FMIP specifies parameters to
> be exchanged in HI/HAck. Whether you call that CT or something else is not
> not quite accurate to characterize it as coupled with CT!
>
>  [Ahmad]
There are some parameters in HI/HAck which are required, just as in FMIP. We
don't consider that as CT - just as you don't for a routing protocol that
exchanges link state information.

Then there are options which a protocol can define. The language
(MUST/SHOULD/MAY) for using these options are dependent on the particular
protocol. For instance, in PFMIPv6, the context request option is used only
for the reactive handover case.

Regards,

-Rajeev

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 20 Mar 2008 17:50:52 +0900

Hi Jean-Michel,

Thanks for your comment. Please see inline:

> doesn't mean that there is a trust relationship between the MAG from B

I agree, but what I was trying to say is it is not a hard assumption 
that two MAGs have a trust relationship. If domain A and domain B can 
have a trust relationship and domain A and domain C can have a trust 
relationship, then why not domain B and domain C? If LMA and MAG in 
different domains can have a trust relationship, then why can't two MAGs 
in different domains have a trust relationship?

> should only be used for intra-domain mobility.

I would like to emphasize that user data to be forwarded is as important 
as the context information; therefore the tunnel between ARs (MAGs) must 
be secured. If those two ARs (MAGs) are trusted and the tunnel between 
them are secured, then it may not be that important whether it is 
intra-domain or inter-domain. I'm just wondering if PMIPv6 should be 
used only for intra-domain HO in the same sense... Having said that, I 
also think it is a typical use case that FMIPv6 is used for intra-domain 
handover.

Regards,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 23 Mar 2008 00:06:51 -0500

Hi Rajeev,
sorry for the late reply. please see one comment inline.

Regards, 
Ahmad 

	Sent: Wednesday, March 19, 2008 7:13 PM

	On Wed, Mar 19, 2008 at 1:58 PM, Ahmad Muhanna
<[email-masked]> wrote:

			As I mentioned in my previous e-mail, base FMIP
specifies parameters to be exchanged in HI/HAck. Whether you call that
CT or something else is not relevant. We are using a similar set of
parameters for PMIP purposes.

			And, we defined options for HI/HAck in FMIP.
They are meant to be used by folks. Would you forbid using those options
if folks want to exchange parameters during handover? I would not; it
does not make sense. So, it is not quite accurate to characterize it as
coupled with CT!  

			[Ahmad]
			Well, then is the use of CT within HI and Hack
optional?

	There are some parameters in HI/HAck which are required, just as
in FMIP. We don't consider that as CT - just as you don't for a routing
protocol that exchanges link state information.

	Then there are options which a protocol can define. The language
(MUST/SHOULD/MAY) for using these options are dependent on the
particular protocol. For instance, in PFMIPv6, the context request
option is used only for the reactive handover case. 
	 
	[Ahmad]
	Does this mean that the proposed solution could stand alone and
be deployed with the Predictive fast Handover alone? 

	Regards,

	-Rajeev

			 
			Best Regards,
			Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 23 Mar 2008 00:11:59 -0500

Hi Hidetoshi,
Please see one comment inline.

Regards,
Ahmad

> >> The SA between ARs (MAGs) is already addressed in 4068bis, which is

> >> the  base spec for FMIPv6. I haven't seen or heard any issue with 
> >> this. In  the real world also, it is not a hard assumption that ARs

> >> have a trust  relationship. Actually, the secure connection between

> >> the ARs doesn't  have to be IPSec, but it could employ other 
> >> mechanisms such as a lower  layer security protocol or physical 
> >> protection. I think any mobile  operator wants to secure its whole
network whether FMIP is used or not.
> >> authentication information is often exchanged. Besides, neither
3GPP 
> >> nor 3GPP2 sees that it is an issue. You can see data forwarding
between 
> >> ARs  (e.g. SGWs or AGWs) during handover in several places.
> > 
> I agree, but what I was trying to say is it is not a hard 
> assumption that two MAGs have a trust relationship. If domain 
> A and domain B can have a trust relationship and domain A and 
> domain C can have a trust relationship, then why not domain B 
> and domain C?

[Ahmad]

Probably you can tell us why YES?
Thanks.

 If LMA and MAG in different domains can have a 
> trust relationship, then why can't two MAGs in different 
> domains have a trust relationship?
> 
> I would like to emphasize that user data to be forwarded is 
> as important as the context information; therefore the tunnel 
> between ARs (MAGs) must be secured. If those two ARs (MAGs) 
> are trusted and the tunnel between them are secured, then it 
> may not be that important whether it is intra-domain or 
> inter-domain. I'm just wondering if PMIPv6 should be used 
> only for intra-domain HO in the same sense... Having said 
> that, I also think it is a typical use case that FMIPv6 is 
> used for intra-domain handover.
> 
> Regards,
> --
> Hidetoshi
> 
> > [snip]
> > 
> > Best regards.
> > 
> > JMC.
> > 
> > 
>

---

From: "Rajeev Koodli" <[email-masked]>
Date: Sun, 23 Mar 2008 10:16:30 -0700

Hello Ahmad,
A handover solution must include both predictive and reactive modes. While
you design for the best performance, there will be times when you have to
fall back to reactive case.

I think you should not be concerned about CT. As I said, both the handover
modes involve signaling and you exchange some parameters.

Regards,

-Rajeev

On Sat, Mar 22, 2008 at 10:06 PM, Ahmad Muhanna <[email-masked]> wrote:

>  ------------------------------
> *From:* Rajeev Koodli [mailto:[email-masked]]
> *Sent:* Wednesday, March 19, 2008 7:13 PM
> *To:* Muhanna, Ahmad (RICH1:2H10)
> *Cc:* Vijay Devarapalli; Mipshop
> >    As I mentioned in my previous e-mail, base FMIP specifies parameters
> > to be exchanged in HI/HAck. Whether you call that CT or something else is
> > not relevant. We are using a similar set of parameters for PMIP purposes.
> >
> > And, we defined options for HI/HAck in FMIP. They are meant to be used
> > by folks. Would you forbid using those options if folks want to exchange
> There are some parameters in HI/HAck which are required, just as in FMIP.
> We don't consider that as CT - just as you don't for a routing protocol that
> Does this mean that the proposed solution could stand alone and be
> deployed with the Predictive fast Handover alone?
>
> Regards,
>
> -Rajeev
>
>
>
> > Best Regards,
> > Ahmad
> >
> >
> >

---

From: Hidetoshi Yokota <[email-masked]>
Date: Mon, 24 Mar 2008 17:08:32 +0900

Hi Ahmad,

Please see inline:

> Probably you can tell us why YES?

My general answer would be I can't find a reason for absolutely NOT in 
all cases. Eventually, a trust relationship will be determined by 
bi-lateral agreements.

Regards,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 24 Mar 2008 08:46:28 -0500

Hi Hidetoshi,
Thanks, a minor comment inline.

Regards,
Ahmad
 
> >>> doesn't mean that there is a trust relationship between 
> the MAG from
> > B
> >>> and the MAG from C.
> assumption 
> >> relationship, then why not domain B and domain C?
> > 
> > [Ahmad]
> > 
> My general answer would be I can't find a reason for 
> absolutely NOT in all cases. Eventually, a trust relationship 
> will be determined by bi-lateral agreements.

[Ahmad]
Good enough. 
For me this means that domain B need to have a direct trust relationship
with domain C and can not rely on its trust relationship with A which
happens to have a totally but probably different trust relationship with
C.

My 2 cents.

> >> I would like to emphasize that user data to be forwarded is as 
> >> important as the context information; therefore the tunnel between 
> >> ARs (MAGs) must be secured. If those two ARs (MAGs) are 
> trusted and 
> >> the tunnel between them are secured, then it may not be that 
> >> important whether it is intra-domain or inter-domain. I'm just 
> >> wondering if PMIPv6 should be used only for intra-domain HO in the 
> >> same sense... Having said that, I also think it is a 
> typical use case 
> >> that FMIPv6 is used for intra-domain handover.
> >>
> >> Regards,
> >> --
> >> Hidetoshi
> >>
> >>> [snip]
> >>>
> >>> Best regards.
> >>>
> >>> JMC.
> >>>
> >>>
> > 
> > 
>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Mon, 24 Mar 2008 23:08:40 +0900

Hi Ahmad,

Yes, you are right. That's what I meant.

Regards,
--
Hidetoshi