Subject: RE: [rohc] TCP packet formats

From: "Finking, Robert" <[email-masked]>
Date: Thu, 7 Oct 2004 09:34:10 +0100

]"Finking, Robert" wrote:
]> ]Well, you created what we call "gratuitous generality".
]> ]In your second solution, you lost the property that flag can be either 
]> ]0 or 1.
]> ]So, for a flag value of 4, you now have a 128 bit field.
]>
]> Ooops! Good catch.
]>
]>    let(flag >= 0 || flag <= 1)
]
]I would suggest
]
]     let(flag >= 0 && flag <= 1)
]
]or
]
]     let(flag == 0 || flag == 1)
]
]instead ;-)

LOL. My maths teacher always used to say "Engage brain before opening
mouth", perhaps I should go write it out a few hundred times =)

Thanks!

Raffles

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 07 Oct 2004 11:15:08 +0200

Hi again. I'm working on another update of the TCP profile packet 
formats, and there are some things that I don't know how to resolve with 
ROHC-FN. Since it's the first time I'm actually trying to write 
something in FN instead of just dumping on what others have done, I 
really need some help from the experts (hint: if you're CC:ed to this 
mail....)

Issue 1:
*********************
In Mark's latest version of the formats, there is

tcpip_co === {

         uncompressed_format = src_port,     %[ 16 ]
                               dst_port,     %[ 16 ]
                               rsf_flags,    %[ 3 ]
                               psh_flag,     %[ 1 ]
                               urg_flag,     %[ 1 ]
                               ack_flag,     %[ 1 ]
                               offset,       %[ 4 ]
                               ecn_flags,    %[ 2 ]
                               res_flags,    %[ 4 ]
                               urg_ptr,      %[ 16 ]
                               window,       %[ 16 ]
                               checksum,     %[ 16 ]
                               seq_number,   %[ 32 ]
                               ack_number,   %[ 32 ]
                               options;      %  n bits
....

Since the CO packet formats are "base headers" and are a compressed 
preresentation for both the TCP header AND the innermost IP header, the 
uncompressed format should really be one (IPv4 or IPv6) and one TCP header.
Therefore, I've added something like:

ip_hdr === {
        uncompressed_format = inner_ip;

        format_inner_v4 = ipv4,
        {
		inner_ip ::= ipv4;
        }

        format_inner_v6 = ipv6,
        {
		inner_ip ::= ipv6;
        }

};

tcpip_co === {

    uncompressed format =  ip_hdr, % 160 or 320 bits
         		  tcp;    % 160 + n bits

....

Is this possible with FN? If not, any suggestions how to solve this? 
(yes, laughing is allowed here)

Issue 2:
*************************
default_methods for the tcpip_co. Mark just listed all fields from IPv4 
and TCP here, but in line with issue 1, this is not really correct.
It is clearly "enough" information, but how do I express that IPv4 TOS 
equals IPv6 TC and the same for TTL/HOPLIMIT?
Also, do I need to make some provisions for fields that only appear in 
one of the IP headers such as DF, MF?

Issue 3:
**********************
List encoding. (once again, this mammoth rises up and bites us all in 
the ass).
I must admit that I thought the latest FN (Robert's text) had cleared 
this up, but now I don't really see how to use it.
For TCP options, I will define a structure tcp_options, but HOW should I 
write this (Robert, this is aimed at you)?. I read the examples in FN, 
but hit a brick wall. What I would have liked would be to have a 
structure that creates both "list header", "xi_list" and "item_list" 
instead of having to do each of these separately in each profile using 
list encoding.

Please provide me with sample FN for this, 'cause I got about this far:
tcp_options ===
{
	list_header;
	xi_list;
	item_list;
};
Which of course is just BS.

I'll probably get back with more things as soon as I try to fix NBO for 
the IPIDs but that's a whole new story.

BR,
	Kristofer Sandlund, Effnet AB