Subject: [mobile-ip] Problems with header compression in IPv6

From: James Kempf <[email-masked]>
Date: Wed, 28 Mar 2001 08:20:36 -0800 (PST)

Claude,

>I think what James is saying is that header compression
>will be difficult for MIPv6...i.e. no packets will be compressed
>... it is better not using tunnels...
>Am I right James?
>

Exactly!

>I am not completly convinced about this arguments and I am sure that
>the RoHc will eventually find a solution...
>

Me either, but it is a heavily algorithmic area which I have not
spent time understanding, so I am willing to seek advice from those
who have.

>However if we assume that this problem will not be solved, I think that I would
>make more sense to have the wireless access routers decapsulate the packets 
coming
>from the MAP and forward them on the air link... these packets could then be 
compressed
>because the destination address does not change (the destination is the RCoA) 
as long as the MN
>is supported by the same MAP (i.e. the RCoA does not change).
>
>This requires to modify the wireless access routers but you gain even more than 
the proposed 3rd mode
>in term of bandwidth comsumption because header compression is then possible on 
the air link....

My feelings as well. This is similar to the old IPv4 FA, so the access
router would have to control the care of address, so it would be the
target of the tunnel.

Another possibility would be to simply strip the header and set up
an MPLS label switched path between the access router and the mobile
node. The label would be a small tag to identify the header, so
the mobile node could reassemble it. If the IPv6 flow label is used
as the MPLS label, it would not depend on the address of either the mobile
node or the corresponding node, so the label would not change even
if the corresponding node was a mobile node (and thus was periodically
changing its care of address). Another advantage of this scheme is that
there would only need to be a single, unidirectional packet sent from
one side to the other with full header. After that, the mobile node
and access router record the flow label to header mapping and use that
to reconstruct the packet. Using an arbitrarily assigned label would
work as well, but then there are problems if the corresponding node moves
because the mapping between the corresponding node care of address and the
label would become undone. There would naturally need to be some scheme for 
setting up the flow label end to end, a possible downside. I've got some ideas 
about how that could be done.

As Hesham has stated, this is not a problem only for HMIPv6, but adding
the extra 40 bytes of tunnel overhead will compound the problem if
header compression requires an extensive restart.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Mar 2001 21:57:41 +0200

> >... it is better not using tunnels...
	=> Ok this is a bit different from what we've been discussing 
	and the proposal you mentioned in this mail. So if I can 
	summarise your concerns I would say you mentioned two
	issues:

	1. Tunnelling adds one more header and there is a question
	    whether HC will handle this or not at no extra cost.

	2. Resync of the compressor after handover. 

	I was told several times that issue 1 is not an issue
	and that current HC does handle this and ROHC 
	definitely will. The same goes for Extension headers. 

	 As for 2, this is independant from tunnelling and 
	we need to have some concrete answers on :

	- Whether the impacts are significant (20 packets
	 or 3)

	- Whether seamoby CT can handle this and minimise
	that time. That is if there are significant impacts. 

	If the answer is no to both questions (ie impacts are
	significant and CT will not help), then we need 
	to seriously consider the impacts on MIP in general
	including HMIP of course. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Mar 2001 22:50:30 +0200

James, 

Sorry for the fragmented emails, but it just hit me 
that issue 2 below (if it is an issue) can be solved 
for the uplink by the use of basic mode and forcing the MN to 
use RCoA as a source address in the packets. 
This is specified in rev 3 of the draft. 
Of course this doesn't solve it for MIPv6 (the base draft)
or the rare case of a colocated address in MIPv4. 

My limited knowledge of ROHC tells me that the 
uplink is the hard one to sync so this should do 
the trick since the packets won't change.

Comments ?

Hesham

> -----Original Message-----
> From:	Hesham Soliman  (ERA) [SMTP:[email-masked]]
> Sent:	Thursday, 29 March 2001 5:58
> To:	'James Kempf'
> Cc:	[email-masked]
> Subject:	[mobile-ip] RE: Problems with header compression in IPv6
>

---

From: James Kempf <[email-masked]>
Date: Wed, 28 Mar 2001 12:59:05 -0800 (PST)

Hesham,

You've about summarized it. Until we get an answer from the ROHC group,
we won't know for sure.

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 28 Mar 2001 13:09:24 -0800 (PST)

Hesham,

>Sorry for the fragmented emails, but it just hit me 

No problem.

>or the rare case of a colocated address in MIPv4. 

Right, but it does limit the deployment to basic mode and it doesn't
solve the downlink problem. I think we need a solution that works
for all cases and lets the network operator choose the deployment
they need.

>the trick since the packets won't change.

I'm hoping that the ROHC algorithms are sufficiently parameterized that
restarting the compressor after context transfer will
be possible without going back to the base state. 

Barring that, I think we are going to need a solution like the
old FA or like the MPLS solution I described in the email to Claude.
You could would still need header compression for options and for
UDP/RTP headers in any event.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Mar 2001 23:41:24 +0200

James, 

> > > 	=> Nothing against your framework of course, but I really 
> > > 	hope we don't resort to either option (especially MPLS). 
> > > 	This will only delay deployment. 
> > > 	Let's wait and see what the ROHC and CT experts say.
> >
> >   I don't think that MPLS helps. The label stack
> >   is inserted in between the headers, it doesn't
> >   replace them. After all, labels just reify the
> >   forwarding equivalence class; once you're done
> >   label switching, you still need to know how to
> >   route it to the destination. Also: label
> >   switching doesn't currently support
> >   to-the-endpoint as far as I've heard.
> >
> >
> 
> My understanding from reading the MPLS framework RFC is that label stripping
> was supported as well, just as long as the LDP communicated the header
> to the other end somehow.
> 
	=> MPLS deals with flows. ROHC deals with connections. 
	A connection != a flow. There are several (major) issues
	to consider here, but this discussion is way beyond the
	scopes of these mailing lists so let's wait. 

	Hesham

---

From: James Kempf <[email-masked]>
Date: Wed, 28 Mar 2001 13:48:11 -0800 (PST)

Mike,

>   That's just the labels, not the inner headers.
>   MPLS is just a way of encoding the the forwarding
>   decision back upstream so that the FIB lookup can
>   be done with a single lookup for the FEC rather
>   than the more conventional MTRIE based lookup.
>   Once you're done label switching, you still
>   need those IP headers to sort everything else
>   out (including TTL processing, etc, etc). I'm
>   pretty sure that this is why it doesn't make
>   much sense to create LSP's to the host.
>

Even if the LSP were one hop, from the last hop router to the mobile
node? No TTL considerations there...

		jak