Subject: RE: [rohc] Do we need a special profile for Mobile IPv6 packets?

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 9 Dec 2002 16:58:48 +0100

>    What I would like to see is a better motivation for defining
>    new profiles to address something that should already be
>    covered by existing profiles, i.e. to see examples of what
>    problems there are with the current profiles in this regard.
> 
> If you agree we need some new profiles to handle mobile IPv6
> (when the standard will be finished, cf RFC 3095 Abstract and
> section 3.4) then why not try to provide the best solution we
> can?

I do not agree new profiles are needed. I can not do so before
someone has shown that the current mechanisms are not sufficient.
When we wrote 3095, we were not sure whether what we had would
be good enough. However, based on the input that you and Wang
have provided about the MIPv6 headers, it seems like the current
mechanisms already have what is needed. 

/L-E
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Francis Dupont <[email-masked]>
Date: Tue, 10 Dec 2002 11:36:54 +0100

In your previous mail you wrote:

   I do not agree new profiles are needed.

=> I still can't see how current mechanisms can handle the real address
chasing. When the source or destination address fields in the IPv6
header are "static-def", you create a new context at each handoff... 

   However, based on the input that you and Wang
   have provided about the MIPv6 headers, it seems like the current
   mechanisms already have what is needed. 
   
=> it seems you are alone with this opinion (:-).

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

---

From: [email-masked]
Date: Tue, 10 Dec 2002 22:57:13 +0100

Bonjour Francis,

I am somewhat of a late-comer in this discussion and I am not so familiar 
with MIPv6, but I am certainly interested into understanding more.

So, I might be misunderstanding something, but my current understanding is that 
if the mobile node is in a foreign network (FN) - eg away from the home network 
- then it uses some of the MIPv6 extensions to bypass the egress filtering from 
the FN's router when corresponding directly to the CN. In addition, these 
extensions are static for the duration of the stay in this FN.
 
During a MIPv6 handoff (if such thing has been defined?), then the COA changes 
because it enters another network. However, wouldn't the node performing header 
compression in the network side change as well, thus a new header compression 
would be initialized anyway?

In this respect, my undestanding is that header compression may consider the 
MIPv6 extensions to be static for the lifetime of the compression context, and 
therefore I would think that list compression from RFC3095 be sufficient. 

However, I am also open to receive a better explanation if the above is not 
correct. So if possible, please provide a more detailed description of the 
scenario that would make list compression from RFC3095 not sufficient - to make 
sure that I am not misunderstanding something.

Thanks.

/Ghyslain

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Dec 2002 20:56:32 -0800 (PST)

--- Francis Dupont <[email-masked]>
> header are "static-def", you create a new context at
This is a good point. After handoff, MN can not
continue to compress 0-bit these two extension headers
because the new AR would not have the state!
Is ROHC profile a solution to this problem?
Or a context transfer protocol sending the list
compression state?

BR,

--behcet

---

From: Ghyslain Pelletier <[email-masked]>
Date: Wed, 11 Dec 2002 23:00:44 +0100

> Or a context transfer protocol sending the list

I am trying to get some answers regarding my previous comment about
this. Again, my understanding:

If a field is static-def, then it defines the packet stream. Changing
this value then requires the re-initialization of the context. During
handoff, if the prefix of the address changes, this thus requires
re-initialization. I believe this was the point made by Francis.

During a MIPv6 handoff, my previous question is if this handoff will not
imply also a change of anchor point for the header compression, thus
requiring anyway the creation of a new context in another ROHC instance
within the new HC anchor point. If this is the case, then other than at
handoff the address fields in the IPv6 header do not change, and unless
I am missing something the current list compression is sufficient to
efficiently compress MIPv6.

/Ghyslain

PS: For example, in a cdma2000 system, header compression is located in
the PDSN, where the PPP link from the MS also terminates. For an IPv6
MS, the PDSN is also the link local router and a prefix is associated to
each PPP session. The prefix can only change when moving to another
PDSN, and then the PPP link (and header compression) would be terminated
to be re-established to the new PDSN, with a new prefix associated. A
new context in the new ROHC instance would then be needed anyway.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Dec 2002 15:09:10 -0800 (PST)

So are you saying that RFC 3095 defines a way of
transferring the context thereby creating another ROHC
instance after the value is changed, e.g. due to
handoff? How? 

--- Ghyslain Pelletier
<[email-masked]> wrote:
> > > header are "static-def", you create a new
> context at
> > > each handoff...
> > >

--behcet

---

From: Ghyslain Pelletier <[email-masked]>
Date: Thu, 12 Dec 2002 03:16:50 +0100

No, of course RFC3095 does not support context transfer and that's not
what I was saying either. Maybe my previous mail was not clear, but I am
only addressing the compression of MIPv6.

My point is simply that I do not think that MIPv6 handoff has an impact
to this discussion and is not an argument for either new profiles or
updates to current profiles. Such impact was implied in:

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01134.html

and later recovered in your mail. Secondly, I think that list
compression is sufficient to compress MIPv6 headers, as Lars-Erik was
pointing out previously in:

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01127.html

Context transfer is a totally different question, and I did not address
it. 

/Ghyslain

---

From: Francis Dupont <[email-masked]>
Date: Sun, 15 Dec 2002 19:56:08 +0100

So, I might be misunderstanding something, but my current
  understanding is that if the mobile node is in a foreign network (FN)
  - eg away from the home network - then it uses some of the MIPv6
  extensions to bypass the egress filtering from the FN's router when

=> s/egress/ingress/ ?

  corresponding directly to the CN. In addition, these extensions are
  static for the duration of the stay in this FN.
    
   During a MIPv6 handoff (if such thing has been defined?),

=> draft-ietf-mobileip-ipv6-19.txt section 11.5

   then the COA changes because it enters another network. However,
   wouldn't the node performing header compression in the network side
   change as well, thus a new header compression would be initialized
   anyway?
   
=> you make a strong assumption about where is the header compressor node
in the network side. A new initialization is expensive so the compressor
node can be shared between several links or its context can be transfered
to the new node.

   In this respect, my undestanding is that header compression may
   consider the MIPv6 extensions to be static for the lifetime of the
   compression context, and therefore I would think that list compression
   from RFC3095 be sufficient.
   
=> my main concern is not about list compression: the appendix A
classification of fields in the IPv6 header is clearly wrong for MIPv6.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 15 Dec 2002 20:03:54 +0100

=> but can be the new AR the same than the old AR?
In hierarchical mobility this case can become common.

=> the other way to keep the context is to transfer it...

Regards