Subject: Re: [rohc] ROHC packet traces/CRC calculation example.

From: Diego Melpignano <[email-masked]>
Date: Mon, 22 Sep 2003 11:49:36 +0200

Dear all,
my two cents in the discussion.
There is a nice Linux tool named "vtun" (http://vtun.sourceforge.net/) that
can be used to build IP tunnels over the Internet and which enables writing
packet handler modules in the user space. One of these modules may be, guess
what?, ROHC.
Of course, ROHC is not included at the moment but someone could easily hook
its own ROHC user space implementation in the VTUN framework, if this
solution makes sense at all.
Let me know if this helps.

    Bye.

    Diego.

[email-masked] wrote:

> Alan,
>
> That is an excellent suggestion, if someone takes the
> initiative to formulate the "test rules" and provide
> "necessary tools"
>
> /L-E
>
> > -----Original Message-----
> > From: Alan Kennington [mailto:[email-masked]]
> > Sent: den 20 september 2003 17:37
> > To: ROHC mailing list
> > Subject: Re: [rohc] ROHC packet traces/CRC calculation example.
> >
> >
> > On Fri, Sep 19, 2003 at 06:06:42PM -0400, Remi Pelland wrote:
> > >
> > > Does anyone know if there are any records of packet traces taken
> > > during the interoperability tests?  I'm mostly interrested
> > in the CRC
> > > calculation of compressed header since I would like to compare my
> > > algorithm against something that is known to work.
> > >
> >
> > Rémi,
> >
> > I can't help directly with that question. But for the distant
> > future, I
> > have a suggestion. If an RFC was defined for "ROHC over UDP" then we
> > could all test our implementations over the Internet.  Of course, this
> > would not be a 100% test of all aspects, but it would
> > certainly test 99%
> > of the protocol syntax and semantics.
> >
> > This could be implemented quite simply on unix systems by modifying an
> > ROHC/PPP implementation so that the packets are fed to a user-space
> > process via a character-device, and each packet could then be
> > sent to a
> > remote host in a UDP packet.
> >
> > Maybe then someone could make available a standard reference ROHC over
> > UDP implementation for everyone to test their implementations against.
> > This would be much less costly than interop meetings - and
> > even us poor
> > people could participate.
> >
> > Cheers,
> > Alan Kennington.
> >
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> >
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc

--
Diego Melpignano
Advanced System Technologies - ST Microelectronics
Centro direzionale Colleoni, building "la Dialettica"
20041 Agrate Brianza ITALY
t. +39 039 603 7409 -  f. +39 039 603 6129
mailto:[email-masked]

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

---

From: Alan Kennington <[email-masked]>
Date: Mon, 22 Sep 2003 19:45:20 +0930

> Let me know if this helps.

Diego,

I think the vtun must work like this:

application -> TCP|UDP -> IP -> vtun -> TCP|UDP -> IP -> IP-network.

That is, vtun "higher layer" is the local IP layer of the IP stack.
But ROHC for handling normal IP traffic must look like this:

RTP application -> UDP -> IP -> ROHC -> link-layer.

Now what we need for ROHC over UDP is this:

RTP application -> UDP -> IP -> ROHC -> vtun -> UDP -> IP -> IP-network

The difficult thing is to get vtun "under" ROHC. If ROHC is implemented in
userspace, this should not be difficult, but then you don't need vtun because
UDP sockets are easy to write in software. vtun provides many added services
(compression etc.) which maybe we don't need.

If ROHC is implemented in kernel, then it is simplest to just open a character
device like /etc/rohc0 to exchange ROHC packets with userspace, and then again
it is easy to use bare-bones UDP/IP.  However, it would be interesting to see
if vtun offers any facilities which would be really useful. It might not be
portable enough for everybody's implementations. Some people don't use unix!!

CHeers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
    city: Adelaide, South Australia
  coords: 138.59 E, 34.88 S
 website: http://www.topology.org/
timezone: UTC+0930 http://www.topology.org/site/timezone.html
 pgp-key: http://www.topology.org/ak/key_ak2.asc
   email: http://www.topology.org/extra/email.php