[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] TCP compression profile (described pictorially)
Hi,
Here is the current set of TCP/IP packet formats that we use in our implementation.
At present we only have limited support for TCP options (and no support for IPv6 or
extension headers), but it should be easy enough to add these later on.
The pictures themselves only describe the compressed versions of each field, so the
rules for how to interpret these compressed bits must be provided separately. If
you need these rules, you can find them in the ROHC-FN version of the packet formats.
The indicator flags are currently designed by hand in a very simplistic manner, so
there's plenty of scope for making them more efficient in future (e.g. by using
EPIC-lite to generate them automatically).
Comments welcome!
Regards,
Richard
----------------------------------------------------------------------------------------
1. Overall Compressed TCP/IP Header
+-------------------------------+ denotes a variable number of bits
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ denotes an exact number of bits (in this case 16)
The overall compressed TCP/IP packet format is divided into the following headers:
+-------------------------------+
| Control Fields | (see 2)
+-------------------------------+
| TCP Header | (see 3)
+-------------------------------+
| IP Header | (see 4)
+-------------------------------+
| Padding |
+-------------------------------+
N.B. The "Padding" field adds enough zero bits onto the compressed header to
ensure byte-alignment.
To Do: Pad with something more sensible, e.g. sequence number.
2. Control Fields
+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| MSN | or |1| MSN |
+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N.B. "MSN" is the Master Sequence Number, used for inferring the IP-ID.
The MSN will also be needed for feedback packets.
To Do: At some stage we should add support for a CRC.
3. TCP Header
+-------------------------------+
| TCP Data Offset | (3.1)
+-------------------------------+
| TCP Options | (3.2)
+-------------------------------+
| TCP Urgent Fields | (3.3)
+-------------------------------+
| TCP Checksum | (3.4)
+-------------------------------+
| TCP Window | (3.5)
+-------------------------------+
| TCP Flags | (3.6)
+-------------------------------+
| TCP Sequence and Ack Numbers | (3.7)
+-------------------------------+
| TCP Destination Port | (3.8)
+-------------------------------+
| TCP Source Port | (3.9)
+-------------------------------+
3.1. TCP Data Offset
+-+ +-+-+-+-+-+
|0| or |1| D.O. |
+-+ +-+-+-+-+-+
N.B. "D.O." is the TCP Data Offset.
3.2. TCP Options
+-+ +-+-------------------------------+
|0| or |1| TCP Options | variable length
+-+ +-+-------------------------------+
N.B. If the TCP Options change then we currently just send them in full.
The length of the TCP Options can be derived from the TCP Data Offset.
To Do: Add better support for options, including specific compressed
header formats for well-known options such as SACK and Timestamp.
3.3. TCP Urgent Fields
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1| TCP Urgent Pointer |U|
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N.B. "U" is the URG flag.
3.4. TCP Checksum
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N.B. Always send this in full to avoid breaking end-to-end error protection.
3.5. TCP Window
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1|0| TCP Window |
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or |1|1| TCP Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.6. TCP Flags
+-------------------------------+
| RST, SYN and FIN Flags | (3.6.1)
+-------------------------------+
| PSH and ACK Flags | (3.6.2)
+-------------------------------+
| ECN Flags | (3.6.3)
+-------------------------------+
| Reserved Bits | (3.6.4)
+-------------------------------+
N.B. The URG flag is compressed together with the Urgent Pointer.
3.6.1. RST, SYN and FIN Flags
+-+ +-+-+ +-+-+-+ +-+-+-+-+-+-+
|0| or |1|0| or |1|1|0| or |1|1|1|R|S|F|
+-+ +-+-+ +-+-+-+ +-+-+-+-+-+-+
N.B. "R" is the RST flag, "S" is the SYN flag and "F" is the FIN flag.
3.6.2. PSH and ACK Flags
+-+-+ +-+-+-+
|P|0| or |P|1|A|
+-+-+ +-+-+-+
N.B. "P" is the PSH flag and "A" is the ACK flag.
3.6.3. ECN Flags
+-+ +-+-+-+-+-+
|0| or |1|ECN|C|E|
+-+ +-+-+-+-+-+
N.B. "C" is the CWR flag and "E" is the ECE flag.
The ECN bits are from the IP header.
3.6.4. Reserved Bits
+-+ +-+-+-+-+-+
|0| or |1| Res |
+-+ +-+-+-+-+-+
N.B. We allow the TCP reserved bits to be sent in full for future-proofing.
3.7. TCP Sequence and Ack Numbers
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1|0| Ack Number | or |1|1|0| Sequence Number |
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or |1|1|1|0| Ack Number | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or |1|1|1|1|0| Ack Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or |1|1|1|1|1|0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or |1|1|1|1|1|1|0| Ack Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or |1|1|1|1|1|1|1|0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or |1|1|1|1|1|1|1|1|0| Ack Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack Number (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. TCP Destination Port
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1| TCP Destination Port |
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.9. TCP Source Port
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1| TCP Source Port |
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. IP Header
+-------------------------------+
| IP Destination Address | (4.1)
+-------------------------------+
| IP Source Address | (4.2)
+-------------------------------+
| IP Time To Live | (4.3)
+-------------------------------+
| IP Don't Fragment | (4.4)
+-------------------------------+
| IP-ID | (4.5)
+-------------------------------+
| IP TOS | (4.6)
+-------------------------------+
4.1. IP Destination Address
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1| IP Destination Address |
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. IP Source Address
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| or |1| IP Source Address |
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. IP Time To Live
+-+ +-+-+-+-+-+-+-+-+-+
|0| or |1| Time To Live |
+-+ +-+-+-+-+-+-+-+-+-+
4.4. IP Don't Fragment
+-+ +-+-+
|0| or |1|D|
+-+ +-+-+
N.B. "D" is the Don't Fragment flag.
4.5. IP-ID
+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
|0| IP-ID | or |1|0| IP-ID |
+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or |1|1| IP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N.B. The IP-ID is compressed as an offset from the MSN.
4.6. IP TOS
+-+ +-+-+-+-+-+-+-+
|0| or |1| IP TOS |
+-+ +-+-+-+-+-+-+-+
N.B. The ECN flags are compressed separately.
> -----Original Message-----
> From: Lars-Erik Jonsson (EAB)
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: Tuesday, March 11, 2003 10:16 PM
> To: Price, Richard; 'rohc@ietf.org'
> Subject: RE: [rohc] TCP compression profile
>
>
> > > Can you send the TCP packet formats you used to the mailing list?
> >
> > No problem. Would you like them in notated or pictorial form (or
> > both, for comparison)?
> >
> > If you'd like the packet formats in pictorial form, are the pictures
> > themselves sufficient or should all of the ancillary information
> > needed to get "bits on the wire" also be included (e.g. field
> > dependencies, interpretation intervals for LSB encoding, context
> > updating properties etc.)?
>
> I think the pictorial form would be ok also without the "rules" for how
> to interpret the bits. Together with the notation form, it would be a
> good example.
>
> Thanks!
> /L-E
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc