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

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 22 Sep 2003 11:22:45 +0200

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

---

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

> initiative to formulate the "test rules" and provide

Lars-Erik,

I'm glad you like the idea. The open Internet would have an added
advantage of prividing some "interesting" channel characteristics to
test robustness too, such as packet loss and delay variation.

It seems that this would be easy to implement by putting ROHC packets into UDP
packets one by one. The only problem I see here is packet re-ordering on the
Internet. I think it would be fair to ROHC to prepend 1 or 2 octets to each
ROHC packet header to indicate a sequence number so that out-of-sequence
packets can be either discarded or correctly re-sequenced before ROHC decoding.
All CID encoding should be large-CID. All channel parameters can be set by
e-mail negotiation, I think. We shouldn't need any embedded signalling.

Maybe the biggest problem would be firewalls. Most corporate firewalls
are hostile to UDP.

According to this web page:
http://www.iana.org/assignments/port-numbers
the UDP port 3095 is already assigned, but the numbers 30950 + N are
not assigned yet for 0 <= N <= 9. We could use those.

Concerning vtun:
The "vtun" software seems to be able to run over UDP. That could be
useful. But I am not sure if this would save much development work.
It depends on how your implementation is written. An ROHC/PPP implementation,
for example, would need the "vtun" software to divert data which is sent
to the serial driver, which is already in octet-string form, not delineated
packets. I think that the "vtun" software would be of limited use for
carrying ROHC since it is trivial to open a UDP socket in user-space,
and in kernel-space, entry to the vtun software might not be possible.
But I have not used vtun yet. So I am only guessing.

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