RE: [16ng] RE: 802.16g GPCS?

"Riegel, Maximilian" <maximilian.riegel@siemens.com> Wed, 06 December 2006 01:04 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrlDH-00014Y-8x for 16ng-archive@lists.ietf.org; Tue, 05 Dec 2006 20:04:43 -0500
Received: from eeca16.sogang.ac.kr ([163.239.23.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrlD9-0004oR-71 for 16ng-archive@lists.ietf.org; Tue, 05 Dec 2006 20:04:43 -0500
Received: from eeca16.sogang.ac.kr (eeca16.sogang.ac.kr [127.0.0.1]) by eeca16.sogang.ac.kr (8.12.8/8.12.8) with ESMTP id kB61kIk1026390; Wed, 6 Dec 2006 10:46:21 +0900
Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by eeca16.sogang.ac.kr (8.12.8/8.12.8) with ESMTP id kB61kDk0026387 for <16ng@eeca16.sogang.ac.kr>; Wed, 6 Dec 2006 10:46:14 +0900
Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kB613hSK005762; Wed, 6 Dec 2006 02:03:43 +0100
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id kB613g0H001030; Wed, 6 Dec 2006 02:03:43 +0100
Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 02:03:42 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [16ng] RE: 802.16g GPCS?
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 06 Dec 2006 02:03:41 +0100
Message-ID: <4BB931F00625F54DA8B8563E5A5CA25A017B6515@MCHP7I6A.ww002.siemens.net>
In-Reply-To: <CB0EA6EB697D9F40A30F7E5C930D3CFB0148C20A@CA2-MSX-C01.nw.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [16ng] RE: 802.16g GPCS?
Thread-Index: AccYg5ssQlm2L5coR++PxK+0IqEJ5gAFlPcAAArshIA=
From: "Riegel, Maximilian" <maximilian.riegel@siemens.com>
To: David Johnston <Djohnston@nextwave.com>, Alexandru Petrescu <alexandru.petrescu@motorola.com>
X-OriginalArrivalTime: 06 Dec 2006 01:03:42.0355 (UTC) FILETIME=[5F3F9630:01C718D2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by eeca16.sogang.ac.kr id kB61kDk0026387
cc: 16ng@eeca16.sogang.ac.kr
X-BeenThere: 16ng@eeca16.sogang.ac.kr
X-Mailman-Version: 2.1
Precedence: list
List-Id: IP over IEEE 802.16 Networks <16ng.eeca16.sogang.ac.kr>
List-Unsubscribe: <http://eeca16.sogang.ac.kr/mailman/listinfo/16ng>, <mailto:16ng-request@eeca16.sogang.ac.kr?subject=unsubscribe>
List-Archive: <http://eeca16.sogang.ac.kr/pipermail/16ng>
List-Post: <mailto:16ng@eeca16.sogang.ac.kr>
List-Help: <mailto:16ng-request@eeca16.sogang.ac.kr?subject=help>
List-Subscribe: <http://eeca16.sogang.ac.kr/mailman/listinfo/16ng>, <mailto:16ng-request@eeca16.sogang.ac.kr?subject=subscribe>
Sender: 16ng-bounces@eeca16.sogang.ac.kr
Errors-To: 16ng-bounces@eeca16.sogang.ac.kr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1

DJ, it may be worth to have a look into draft-iab-link-encaps-05 before
proposing protocol multiplexing capabilities inside a GPCS service flow.
The current definition to assign semi-static a particular protocol type
to a service flow may be less flexible than putting a protocol type
field into the header of each packet, but such a flexibility may not be
appreciated.

Bye
Max
BTW: It is quite common that a lower layer protocol provides indications
which protocol (encapsulation) is used in the layer above. The design of
the GPCS follows this convention by providing in the link identification
the type of payload.



-----Original Message-----
From: 16ng-bounces@eeca16.sogang.ac.kr
[mailto:16ng-bounces@eeca16.sogang.ac.kr] On Behalf Of David Johnston
Sent: Tuesday, December 05, 2006 7:39 PM
To: Alexandru Petrescu
Cc: 16ng@eeca16.sogang.ac.kr
Subject: [16ng] RE: 802.16g GPCS?

That TLV is a [145/146].x TLV used in the connection establishment
management messages. It is not a per packet value. It is a semi-static
description of a unicast flow.

I am far from sure that the use of ethertype in GPCS is correct.
Ethertypes are carried in every packet to enable protocol multiplexing
as per 802.2. If GPCS is carrying 802 traffic, the ethertype must be
carried per packet. The two alternatives in common use are:

* Ethernet approach - set aside a fixed two byte field in the packet
header
* Generic 802 approach , including 802.11 - Start the packet with a SNAP
header.

There will be comments by me on the initial sponsor ballot on this
matter.

The title of 802.16 is perhaps a little misleading. It could better be
called "Sorting out the interfaces". This is my fault. I chaired the
study group that set the PAR (~= charter) for 802.16g.

This probably isn't the place to discuss this, but I'll go ahead anyway
since it affects ipv6 encoding. I think the GPCS_PROTOCOL_TYPE TLV in
802.16g should not be an ethertype. It should be one level up and
describe if the payload is one that is 802 (hence carrying an ethertype
by some means specified in the GPCS text) or something else (ATM, RS232,
damp string etc.). It is unwise to have a connection descriptor
mandating what protocol is above, unless it includes an entry for "I
don't care".

802.16g is a work in progress, so there are plenty of issues to iron out
yet.

DJ



-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] 
Sent: Tuesday, December 05, 2006 7:38 AM
To: Alexandru Petrescu
Cc: David Johnston; 16ng@eeca16.sogang.ac.kr
Subject: Re: 802.16g GPCS?

Sorry I've found the 802.16g D6 via other url.

Reading GPCS goals is very encouraging to my expectations of a MAC 
working ok with an IPv6 stack.

There are however unknowns, either due to my lack of understanding 
802.16, or other.

For example, its section 5.3 "GPCS" bullet 3 mentions
"With GPCS, the upper layer protocol that is immediatedly above the
  802.16 GPCS is identified by a TLV parameter, GPCS protocol type, as
  defined in 11.13.19.3.3.20."

An IPv6 Type field in a MAC header is precisely 0x86DD, it is not 
encoded as TLV (type-length value) but as a fixed two-byte field (there 
is no field type and no field length).

The section 11.13.19.3.3.20 is absent in the document, so one may think 
that is a nit to correct.  The closest section to it is 11.13.19.5 GPCS 
CS encodings, which correctly states a fixed 2-byte field, EtherType 
(implicitely 0x86DD).

Alex

Alexandru Petrescu wrote:
> David Johnston wrote:
> [snip]
>> The IEEE 802.16 WG is working on a CS called the GPCS (Generic Packet
>> Convergence Sublayer) as part of 802.16g.
> 
> On this particular topic...
> 
> I'm trying to look at the 802.16g document but server says "Sorry, but

> the page you have requested
>     http://www.ieee802.org/16/private/drafts/netman/80216g-06_002.pdf
> does not exist on this site."
> 
> Its title is "Management Plane Procedures and Services".  Is it this 
> document that describes what GPCS should look like?
> 
> Alex
> 
> _______________________________________________
> 16ng mailing list
> 16ng@eeca16.sogang.ac.kr
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
> 



_______________________________________________
16ng mailing list
16ng@eeca16.sogang.ac.kr
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

_______________________________________________
16ng mailing list
16ng@eeca16.sogang.ac.kr
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng