Subject: Re: [MEXT] New items for the mext charter discussion

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 5 Dec 2007 10:42:08 -0800

Hi Marcelo,

Here is my opinion on this future work. Thanks

On Nov 29, 2007 3:55 AM, marcelo bagnulo braun <[email-masked]> wrote:
> Hi,
>
> After the call for new work to be considered for mext, we have
> received a set of items to be considered, that we need to discuss.
>
> MEXT is likely to recharter and add new items to the charter, but our
> energy is limited so we need to prioritize and decide what items are
> the most relevant to be included in the charter, since it seems hard
> to have energy to deal with all of them
>
> So we would like to ask the WG to comment on the proposed items (or
> other items) and explain if they think that we should be investing
> effort on them. In order to evaluate these items, we should
> understand how important is to work on these items to foster the
> adoption and the deployment of MIPv6 and NEMO protocols.
>
> So at this point, the discussion is two-folded: on one hand we would
> like to foster high level discussion on what is needed to foster
> mobility protocols deployment and in particular to relate this
> discussion with the items that have been proposed so far, and if
> needed propose new items for the charter.
>
> It should be noted that at this point silence does not means
> acceptance of the proposed items and that a strong case for adopting
> new work is needed, since we need to focus our energy in critical
> items needed for protocol deployment.
>
> ------------------------------------------------------------------------
> -------
>
> New items proposed so far:
>
>
> - Binding Revocation Mechanism for IPv6 Mobility
>
> Define a generic binding revocation mechanism for Mobile IPv6
> and its extensions (e.g. NEMO, Monami6, NETLMM). The
> mechanism can be used by any mobility entity that provides
> Mobile IP services to a MN (e.g. a
> MIPv6 HA, a NETLMM LMA) to inform the MN itself or another
> mobility entity that is involved in providing Mobile IP
> services to the MN (e.g. a NETLMM MAG) of the termination of
> either one, multiple or all bindings for a mobile node. The
> mechanism should also allow any mobility entity (e.g. NETLMM
> MAG or LMA) to signal the termination of bindings for
> multiple mobile nodes via use of a single revocation message.
>

GT> I think this makes sense and it is well understood issue. The
work, however, should be done for MIPv6. Then how PMIPv6 can use it
should be done in NETLMM. In other words I would suggest that the
PMIPv6 specific sections in the draft should be removed and worked on
in NETLMM, if NETLMM has a use for this.

> - MIPv6 home link operation in various SDOs
>
> Many SDOs are considering the use of point-to-point links
> between the mobile node and the home agent as a home link for
> Mobile IPv6 to avoid the tunneling overhead. Some of these
> point-to-point links do not support running neighbor discovery.
> Attaching to the home link and returning to the home procedures
> need to be analyzed for these point-to-point links, possible
> with the use of binding update and binding acknowledgment
> messages.
>

GT> I think there maybe something to do here but the problem space is
not clear enough yet. This maybe clearer after the IETF meeting. I
would prefer in any case to abstract away from specific SDO issue and
try to figure out what is actually missing from our IETF RFCs

>
> - IP Tunneling Optimization in a Mobile Environment
>
> The widespread use of different forms of IP tunneling mechanisms in
> mobile environment, e.g., MIPv6,
> HMIPv6, PMIPv6, 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 removing
> the extra header would benefit the mobile node and optimize the
> bandwidth usage.
>

GT>It is not clear to me what this is yet. I will wait for the draft :-)

> - Generic Notification Message for Mobile IPv6
>
> A proposal for defining generic notification framework that can be
> used by the mobility
> entities for sending and receiving asynchronous notification messages
> was proposed and
> the same was adopted by the WG.
>

GT> What are the use cases for this? The obvious one is Binding
Revocation, which could be defined as a Generic Notification with a
mobility option indicating a revocation. The Binding Revocation draft
at the moment, however, defines its own MH. Is there a plan to change
that? If not, what else are these notification supposed to be used
for?

> - GRE requirements for IPv6 mobility
>
>    A proposal has been made for the use of GRE tunneling mechanism in
> Mobile IPv6. The GRE
>    tunneling support exists in Mobile IPv4 and the proposal is for
> extending that functional
>    capability to Mobile IPv6. Noted uses cases include the ability to
> carry any type of
>    protocol payload in a generic header, the rich GRE header
> semantics allowing the exposure
>    of a service identifier, such as a key that can be used by the
> tunnel endpoints for differential
>    treatment of the carried payload and additionally supported by
> other use cases.
>

GT> Is there a use case for GRE encapsulation for MIPv6? or is this
purely for PMIPv6? If the latter, then maybe this should be defined in
NETLMM??

>
> - 4283bis
>
> Revised RFC 4283 to extend the subtype field in the Mobile Node
> identifier option to include other identifiers like IEEE 802 MAC
> address. The only subtype currently reserved is NAI. This may
> not be sufficient for all scenarios.
>

GT>I think this makes sense and should be easy enough.

>
> - Bootstrapping mechanisms for using RFC 4285 with Mobile IPv6
>
> Existing bootstrapping mechanisms for Mobile IPv6 only address
> the use of IKEv2/IPsec for protecting Mobile IPv6 signaling
> messages. Bootstrapping a home address and security associations
> when RFC 4285 is used are not addressed. This draft describes
> bootstrapping mechanisms for using RFC 4285 with Mobile IPv6.
>

GT> I would prefer not to waste time on this. We already have all this
for IKEv2/IPSEC. If someone really needs to document this for 4285
then it could be done as an AD sponsored document.

> - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions
>
> Work on the solution of interface, by which IKEv2 could get the
> information from MIPv6 and negotiate or update right IPsec security
> associations for MIPv6 when MN bootstrap in foreign network or
> handover to new foreign network.
>
> - RFC 3775 update
>
> Revise RFC 3775 to fix minor issues and add clarifying test for
> issues identified since it was published. The update would be
> limited to minor changes and not include any major modifications
> to the protocol.
>

GT> Sure, that should be done

> - Additional NEMO global deployment tools
>
>

GT> Marcelo, what is this??

>
>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mext
>

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Dec 2007 20:06:29 +0100

Hi George,

On Wednesday 05 December 2007, George Tsirtsis wrote:
> [...]

This would include new mechanisms for large scale deployments of NEMO. 
It is unclear what needs be done in that space, hence the discussion. 
One _example_ mechanism I can think of is, e.g., an inter Home Agents 
protocol.

--julien

---

From: Brian Haley <[email-masked]>
Date: Wed, 05 Dec 2007 16:42:19 -0500

Hi George,

> that? If not, what else are these notification supposed to be used

Binding Revocation was one of the intended users, there was a discussion 
  to this effect months ago on the mip6 list that I won't re-hash.  Sri 
has a time slot on Friday to talk about this work.

-Brian

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 5 Dec 2007 13:45:32 -0800

OK, will wait for that. Thanks.
George

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Dec 2007 14:38:42 -0800

George Tsirtsis wrote:
[...]
> GT> Sure, that should be done

It's most important to me, and looking forward for Vijay's presentation 
on this topic and its width.

> GT> Marcelo, what is this??

Marcelo?

It could be a container for bakeoff reports?

Judging by Thierry upcoming presentation slides it could be: RO is 
needed. (http://www3.ietf.org/proceedings/07dec/slides/mext-5.pdf)

It could be the need to dynamically allocate prefixes for use in moving 
networks.

It could be a report of new MIP6/NEMO tools such as HAiku.

What is this?

My impression is it looks as a container for reports at meetings like 
results of bakeoff, or similar.  I think we'll see probably such a 
presentation from Thierry Ernst now.  I think there may be some new 
tools.  I haven't seen Thierry's slides but curious.

Tools for deploying NEMO may also mean this necessity to dynamically 
allocate a prefix for use in the moving network.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 5 Dec 2007 16:53:47 -0800

Hi Marcelo,
Some thoughts inline.  

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Thursday, November 29, 2007 3:56 AM
> To: [email-masked]
> Cc: Julien Laganier
> Subject: [MEXT] New items for the mext charter discussion
> 
> Hi,
> 
> After the call for new work to be considered for mext, we 
> have received a set of items to be considered, that we need 
> to discuss.
> 
> MEXT is likely to recharter and add new items to the charter, 
> but our energy is limited so we need to prioritize and decide 
> what items are the most relevant to be included in the 
> charter, since it seems hard to have energy to deal with all of them
> 
> So we would like to ask the WG to comment on the proposed 
> items (or other items) and explain if they think that we 
> should be investing effort on them. In order to evaluate 
> these items, we should understand how important is to work on 
> these items to foster the adoption and the deployment of 
> MIPv6 and NEMO protocols.
> 
> So at this point, the discussion is two-folded: on one hand 
> we would like to foster high level discussion on what is 
> needed to foster mobility protocols deployment and in 
> particular to relate this discussion with the items that have 
> been proposed so far, and if needed propose new items for the charter.
> 
> acceptance of the proposed items and that a strong case for 
> adopting new work is needed, since we need to focus our 
> energy in critical items needed for protocol deployment.
> 

I can see the use case for binding revocation in NETLMM, but, I'm not
seeing it for MIP6.  I think this came up as part of the WG discussions
on this topic earlier and I didn't see a practical reason why binding
revocation is needed for MIP6.  For non-administrative reasons due to
which bindings need to be moved out of an HA, the HA switch draft does
the work.  If the reasons are administrative, it then implies managed
networks and in all those cases, network access will (and should) be
blocked for the MN even before the binding revocation message can get to
it.  

> Attaching to the home link and returning to the home 
> procedures need to be analyzed for these point-to-point 
> links, possible with the use of binding update and binding 
> acknowledgment messages.
> 

Not sure about this yet.  

> The widespread use of different forms of IP tunneling 
> mechanisms in mobile environment, e.g., MIPv6, HMIPv6, 
> PMIPv6, 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 removing the extra header would benefit the mobile 
> node and optimize the bandwidth usage.
> 

Seems useful, although, typically, it is the last hop that is the most
sensitive to this and ROHC can address this on the last hop.  Is there a
reason we think this problem needs to be solved e2e between the MN and
HA? 

> A proposal for defining generic notification framework that 
> can be used by the mobility entities for sending and 
> receiving asynchronous notification messages was proposed and 

Neutral on this, but, can see the use for it. 

>    A proposal has been made for the use of GRE tunneling 
> mechanism in Mobile IPv6. The GRE
>    tunneling support exists in Mobile IPv4 and the proposal 
> is for extending that functional
>    capability to Mobile IPv6. Noted uses cases include the 
> ability to carry any type of
>    of a service identifier, such as a key that can be used by 
> the tunnel endpoints for differential
>    treatment of the carried payload and additionally 
> supported by other use cases.
> 

Don't see any use for this.  I don't know why we need to replicate all
MIP4 functionalities in MIP6 - in MIP4, GRE helps dealing with
overlapping IP spaces.  In the IPv6 world, I don't see why that is
needed.  

> 
> - 4283bis
> 
> Revised RFC 4283 to extend the subtype field in the Mobile 
> Node identifier option to include other identifiers like IEEE 
> 802 MAC address. The only subtype currently reserved is NAI. 
> This may not be sufficient for all scenarios.
> 

I think this is useful.  I also think that we should open up assignment
of new values totally or by IETF consensus and remove the restriction of
standards action. 

> Existing bootstrapping mechanisms for Mobile IPv6 only 
> address the use of IKEv2/IPsec for protecting Mobile IPv6 
> signaling messages. Bootstrapping a home address and security 
> associations when RFC 4285 is used are not addressed. This 
> draft describes bootstrapping mechanisms for using RFC 4285 
> with Mobile IPv6.
> 

I don't think the WG should work on this.  

> Work on the solution of interface, by which IKEv2 could get 
> the information from MIPv6 and negotiate or update right 
> IPsec security associations for MIPv6 when MN bootstrap in 
> foreign network or handover to new foreign network.
> 

Neutral.  If this work is done, I don't think it should be mandatory to
implement.  Having an optionally standardized mechanism doesn't seem to
hurt. 

> - RFC 3775 update
> 
> Revise RFC 3775 to fix minor issues and add clarifying test 
> for issues identified since it was published. The update 
> would be limited to minor changes and not include any major 
> modifications to the protocol.
> 

Obviously important, but, I tend to agree with Hesham that we should
wait on this. 

> - Additional NEMO global deployment tools

Neutral. 

Thanks,
Vidya

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 6 Dec 2007 12:03:40 +1000

Hi Vidya, 

I agree with almost all of your comments, with one exception below.
 
 > sensitive to this 

=> Agreed. Although some people might argue for backhauls from the BS.

  and ROHC can address this on the last hop. 
 >  Is there a

=> ROHC has several limitations. One of them is that it works on p2p links.
Another is it's complexity of course. This solution is independent of the
link layer, which is good. Even when combined with ROHC it can easily
address the triple header scenarios. 

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 5 Dec 2007 17:09:19 -0800

Hi Hesham,
 
> Another is it's complexity of course. This solution is 
> independent of the link layer, which is good. Even when 
> combined with ROHC it can easily address the triple header scenarios. 
> 

Okay, I'm speaking prematurely, since I haven't looked at the draft yet
:)  I was trying to understand where we see the use.  Even from the p2p
perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP
tunnel is a virtual p2p link.  That is philosophy behind the ongoing
work on ROHC for IPsec.  But, I'll take a look at the draft first (I
assume there is one :)). 

Vidya

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 6 Dec 2007 12:13:42 +1000

> tunnel is a virtual p2p link.  

=> Yes you can, but it's very very complex compared to Wassim's draft IMO. 

Hesham

That is philosophy behind the ongoing

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 6 Dec 2007 03:55:53 +0200 (EET)

Hi Vidya,

Just to add one thing:

ROHC is deployed *only* in particular networks and in these networks when 
you switch between BS, ROHC has to "reboot". So for mobility protocols in
general (including the RO mode), this proposal is much more efficient.

Regards,

Wassim H.

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 06 Dec 2007 03:13:25 +0100

A paper about ROHC with NEMO was published at WONEMO 2007 and another 
one about ROHC in nested NEMO this year at ICLAN 2007. Also 
draft-minaburo-rohc-nemo.txt (expired)

See http://www.rennes.enst-bretagne.fr/~prawat/

Thierry

Wassim Haddad wrote:
> Hi Vidya,
> 
> Just to add one thing:
> 
> ROHC is deployed *only* in particular networks and in these networks 
> when you switch between BS, ROHC has to "reboot". So for mobility 
> protocols in

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Dec 2007 22:26:21 -0800

> implement.  Having an optionally standardized mechanism doesn't seem to

PF_KEY in general is optional. IETF has typically produced
Informational documents in this space. It can always be implemented
in an implementation specific manner.

> Obviously important, but, I tend to agree with Hesham that we should

There are some bugs (leading to interop issues) that need to
be fixed ASAP. See http://www3.ietf.org/proceedings/07dec/slides/mext-6.ppt.
These slides haven't been presented yet. They will be presented
on Friday.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Dec 2007 22:28:00 -0800

Wassim Haddad wrote:
> when you switch between BS, ROHC has to "reboot". 

hmm... this is not entirely accurate. There are networks where the
context is transferred and you could continue in the same state as
the old link. No need for a "reboot".

Vijay

So for mobility

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 6 Dec 2007 02:10:31 -0600

> > Define a generic binding revocation mechanism for Mobile 
> IPv6 and its 
> > extensions (e.g. NEMO, Monami6, NETLMM). The mechanism can 
> be used by 
> > any mobility entity that provides Mobile IP services to a MN (e.g. a
> > MIPv6 HA, a NETLMM LMA) to inform the MN itself or another mobility 
> > entity that is involved in providing Mobile IP services to the MN 
> > (e.g. a NETLMM MAG) of the termination of either one, 
> multiple or all 
> > bindings for a mobile node. The mechanism should also allow any 
> > mobility entity (e.g. NETLMM MAG or LMA) to signal the 
> termination of 
> > bindings for multiple mobile nodes via use of a single revocation 
> > message.
> >
> 
> work, however, should be done for MIPv6. Then how PMIPv6 can 
> use it should be done in NETLMM. In other words I would 
> suggest that the
> PMIPv6 specific sections in the draft should be removed and 
> worked on in NETLMM, if NETLMM has a use for this.
> 
[Ahmad]
Hi George,

This topic has been discussed thoroughly on the MIP6 mailing list and
concluded.
For more information, please take a look at the following threads.

http://www1.ietf.org/mail-archive/web/mip6/current/msg06741.html

http://www1.ietf.org/mail-archive/web/mip6/current/msg06767.html

http://www1.ietf.org/mail-archive/web/mip6/current/msg06788.html

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 6 Dec 2007 02:18:51 -0600

> I can see the use case for binding revocation in NETLMM, but, 
> I'm not seeing it for MIP6.  I think this came up as part of 
> the WG discussions on this topic earlier and I didn't see a 
> practical reason why binding revocation is needed for MIP6.  
> For non-administrative reasons due to which bindings need to 
> be moved out of an HA, the HA switch draft does the work.  If 
> the reasons are administrative, it then implies managed 
> networks and in all those cases, network access will (and 
> should) be blocked for the MN even before the binding 
> revocation message can get to it. 

[Ahmad]
Hi Vidya,

This topic has gone through all the steps of IETF wg decision making and
a consensus has been reached and the issue has been concluded and
closed.

Just in case, here are the steps which has been completed:

1. There has been consensus at MIP6 @ IETF69 to adopt Binding revocation
for IPv6 Mobility as a MIP6 work item.
2. The meeting consensus above has been confirmed with a consensus call
on the MIP6 mailing list.
3. When you (as Netlmm wg chair) raised concern that this functionality
should be addressed in Netlmm wg, the AD discussed this with you and
MIP6 chairs and a decision has been made and communicated to the mailing
list.

For more information, please take a look at the following threads:

Best Regards,
Ahmad

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 6 Dec 2007 17:59:01 +0200 (EET)

On Wed, 5 Dec 2007, Vijay Devarapalli wrote:

>> you switch between BS, ROHC has to "reboot". 
>

=> In fact, it is *very* accurate and you are (as always) wrong! 
Transferring context between base stations is NOT supported in the E-UTRAN
(main reason is that it is even more complex than ROHC itself). This means 
that it has to be restarted at each handoff.

Wassim H.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Dec 2007 09:31:29 -0800

> => In fact, it is *very* accurate and you are (as always) wrong! 

Wow! I am going to ignore that, perhaps you sent it before you had
completely woken up. :)

> (main reason is that it is even more complex than ROHC itself). This 
> means that it has to be restarted at each handoff.

Lets look at the details. ROHC re-start is actually straight forward.
It only takes a few data packets to go from the full header to first
order and then to second order. I had implemented a ROHC context
transfer mechanism back in 2001. The idea was to transfer UDP/RTP
header compression state from the one access router to another using
the Seamboy context transfer mechanism. The performance was
surprisingly good. When the context didn't get transferred (lost CT
messages) or the RTP sequence numbers were way out of sync, the
mobile node had to setup ROHC state again. The RTP numbers could go
out of sync if the L2 handoff takes too long and the mobile node
lost some packets during the handover. The biggest issue I have seen
in transferring ROHC context is that the context could be stale (out
of sync) forcing the mobile to re-start anyway.

I don't believe transferring ROHC context is very complicated. The
reason it is not being used in E-UTRAN could be because they have a
mechanism to install the context pretty fast at the new base station.
You might want to check on that.

BTW, there have been numerous proposals to transfer ROHC context.
Just google for it.

Vijay

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 6 Dec 2007 20:35:20 +0200 (EET)

On Thu, 6 Dec 2007, Vijay Devarapalli wrote:

The following applies only in case you're assuming that ROHC is everywhere
which is already a wrong assumption. But please keep reading.

> Lets look at the details. ROHC re-start is actually straight forward.

=> ROHC restart means that some packet will not be compressed. Moreover, in
case of any minor error, then it has to restart again...

> order and then to second order.

=> First, few data packets and zero data packets are different. This is 
called efficiency. Second, as you are also implicitely getting privacy, 
then you cannot afford showing your identity in few packets after each 
handoff.

> I don't believe transferring ROHC context is very complicated.

=> What kind of statement is this? Are you "guessing" here?!!!!

Anyway, I think you should _strengthen your belief_!
As am not an expert in ROHC, I had to ask our experts in this area (this 
is to explain to you why I only answered you this morning).
In summary: it is *extremely* complicated to transfer context and thus it 
is NOT supported and ROHC will reboot at each handoff.

> You might want to check on that.

=> Really? Which one? How this explains that ROHC will reboot at each 
time? :)

> BTW, there have been numerous proposals to transfer ROHC context.

=> I'll keep this one for you! :) I don't have time for that! 
I think we have already a proposal on that which solves elegantly the 
problem.

Wassim H.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Dec 2007 13:26:36 -0800

Wassim Haddad wrote:
> which is already a wrong assumption. 

I don't think I said ROHC is used everywhere. I was commenting
on ROHC context transfer.

But please keep reading.
> 
>>>>> ROHC is deployed *only* in particular networks and in these 
>>>>> networks when you switch between BS, ROHC has to "reboot". 
>>>>

Based on my implementation experience (transferring ROHC context
using the Seamoby CT protocol), it was not difficult. It was not
at all complicated. Sometime the transferred context is just not
usable and in that case ROHC is re-started.

> In summary: it is *extremely* complicated to transfer context and thus 
> it is NOT supported and ROHC will reboot at each handoff.

I don't buy the argument that it is complicated. But its ok to
disagree. Lets move on.

> => I'll keep this one for you! :) I don't have time for that! I think we 
> have already a proposal on that which solves elegantly the problem.

I was not comparing using ROHC with your draft. I was commenting
on your statement on the mailing list that you have to re-start
ROHC every time there is a handover. That is simply not true.
3GPP have may taken this decision on E-UTRAN handovers, but that
does not make it a universal fact.

Vijay

---

From: [email-masked]
Date: Thu, 13 Dec 2007 03:39:23 +0100

Hello All

I noticed that there are some discussions going on on MEXT list on
ROHC compression in NEMO.
As Thierry has mentioned already, we are working on the same subject.
Infact, we are working on a general solution to reduce tunnel overhead  
in various tunneling scenarios including NEMO tunnel. We use ROHC in  
conjunction with TuCP, a new tunneling compression protocol to  
compress the tunnel headers <draft-minaburo-hc-tunneling-00.txt>.
This is an old draft but we will soon update it with implementation updates.

We suggested the use of ROHC in NEMO in draft-minaburo-rohc-nemo-01.txt
One of the problems with ROHC is, it is defined for point to point
ordered links.
Another point is rohc context transfer, although there are some  
studies on header compression context transfer, as far as I know there  
are none specifically on rohc context transfer and we are looking at  
this (rohc context transfer between MR and HA).

If you are interested, I will provide you the links to the articles  
published on this study.
It would be good to have a feedback from MEXT on this work.

Regards
Priyanka

Quoting Thierry Ernst <[email-masked]>:

>> networks when you switch between BS, ROHC has to "reboot". So for   
>> mobility protocols in