Re: [STDS-802-16] 802.16e sponsor ballot recirculation
Jeff ,
I don't disagree with the ROHC over raw .16. My issue is with 16
defining in a rather vague fashion how to suppress headers in a packet
the fomat of which in my opinion is not clearly defined by anyone. In my
opinion we would be much better of sticking with the Ethernet CS and
work with standard ROHCoE. Also I agree that the ROHC over protocol X
could be defined by the appropriate link layer standards body. In this
case it seems to me to be 802.3 in the case of Ethernet. Alternatively
IETF would be the body to work in.
I would like to point out that had the text been a) introduced at an
earlier stage in the process b) had been drafted more clearly e.g. give
references to relevant definitions of CS SDU formats to expect ,
tightly constrain the classifier parameters in the the this situation
would never had arisen.
BR Carl
ps. My other comments are just minor issues that I managed to find in
cursory read of the standard and piggy-backed
________________________________
From: ext Jeff Mandin [mailto:jmandin@STREETWAVES-NETWORKS.COM]
Sent: 23 August, 2005 20:27
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] 802.16e sponsor ballot recirculation
Carl,
Your comment #1 states that 5.2.4.2 "is problematic as it
assumes that
a well defined way of carrying e.g. ROHC over Ethernet is
widely
known. This is however not the case and leaves the CS SDU format
undefined.
IETF is investigating the issue of ROHCoE but no RFCs are
available.
Also the 802.16 draft does not define this."
Please note the following:
1. 802.16e/D10 clearly specifies the encapsulation for "ROHC-ed
IP
packets over raw .16" as well as "ROHC-ed IP packets over
ethernet
CS": there are 2 new Convergence Sublayer types, and there are
classifiers to recognize the embedded ROHC context Ids.
So classifiers at the transmitting CS can identify the
compressed
packets (via the CS type) and map the SDUs to the appropriate
service
flows.
The receiving CS then forwards the SDU up to the ROHC
decompressor.
2. You seem to have in mind an internet draft for ROHC over 802
networks (
http://www.ietf.org/internet-drafts/draft-bormann-rohc-over-802-01.txt
<http://www.ietf.org/internet-drafts/draft-bormann-rohc-over-802-01.txt>
)
This internet-draft suggests a different encapsulation using
LLC/SNAP,
which is actually quite similar to the 802.16e solution but is
suitable for a link layer such as 802.11 that does not have the
equivalent of a CS.
The internet-draft also discusses ROHC parameter negotiation.
802.16e
sets its ROHC parameters (ie. ROHC profile, Context Id length
etc.)
via either profiles or out-of-band mechanisms. Negotiation is
nice,
but not fundamental.
Other issues discussed in the draft include bridging and
frame-padding
- which do not apply to 802.16.
Note also that this issue more naturally belongs to the link
layer
standardization (see section 2.3 of the draft "Who should
standardize?").
3. So the 802.16 text as it stands appears adequate, and I would
suggest withdrawing this comment.
Best Regards,
- Jeff
On 8/23/05, Roger B. Marks <r.b.marks@ieee.org> wrote:
> I have received Carl's comments and uploaded them:
> http://ballot16e.wirelessman.org
<http://ballot16e.wirelessman.org>
>
> Roger
>
> At 17:17 +0300 2005-08-23, carl.eklund@NOKIA.COM wrote:
> >
> >Dear fellow 802.16e sponsor ballot resolution members and SB
voters,
> >
> >again at the last meeting stuff got added into 16e that
wasn't quite
> >ready for primetime in my opinion. I deemed the problems with
the added
> >text serious enough to change my vote to a no and to submit
technical
> >binding comments. I thought I'll let the group know not to
cause any
> >additional time being wasted.
> >Since we most likely are going to resolve 16e sponsor ballot
comments in
> >Taipei, I urge everyone to carefully go over D10 and submit
comments on
> >the problems and inconsistencies you find before the recirc
ends.
> >
> >Keep your new material that doesn't specifically provide
fixes to real
> >problems to yourself!
> >
> >BR Carl
> >
>