[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rohc] FW: ESP and header compression (ROHC)
What will be needed for "ROHC over tunnels" is allocation
of an IP type identifier for ROHC. A "ROHC over tunnels"
document would then be exactly the fodder we'd need to
feed to the IANA/IESG in order to allocate such an identifier.
The indentifier would mean "the payload is a ROHC packet".
The profiles used over such a tunnel should be able to deal
with the kind of reordering and loss one would see in the tunnel.
There may be a need for a negotiation procedure to negotiate
ROHC parameters over the tunnel, but I'm not entirely sure
this will be needed in all cases. If we decide that it IS needed,
that negotiation might be defined the "ROHC over tunnels"
document as well.
Mikael Degermark
----- Original Message -----
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'Yaron Sheffer'" <yaronf@gmx.net>; "IPSec List"
<ipsec@lists.tislabs.com>; <rohc@ietf.org>
Sent: Tuesday, April 15, 2003 1:22 AM
Subject: RE: [rohc] FW: ESP and header compression (ROHC)
> > Taking the 'ROHC over re-ordering channels' question more
> > generally; RFC 3095 does not work in such an environment.
> > However, we are (I believe) trying to address this issue as
> > part of ROHC for TCP...
>
> This was a design decision we made for 3095, but personally
> I think the modifications needed to make it work also in case
> of mis-ordering are small. If someone wants to look at this
> and write some input on it, I would be more than happy.
>
>
> > Anyway, tunnels (and especially IPsec) can simply be treated
> > as a link. In which case, rohc can be applied on that link.
>
> Yes, a "ROHC over tunnels" document could potentially be
> justifiable.
>
>
> > In the case of IPsec/ESP it may make a great deal of sense to
> > compress the headers inside of the tunnel encapsulation. The
> > VPN endpoints are probably disjoint from any particular
> > physical link that benefits from compression and so, to me,
> > it makes sense to do the compression in the two different places.
>
> Yes, that is what you would have to do if encryption is applied
> over the tunnel.
>
> /L-E
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc