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

["David Johnston" <[e-mail]>]

If the GPCS_PROTOCOL_TYPE flow descriptor actually described what layer
was attached above the GPCS sublayer, then it could include an entry for
802.2. This would lead to the latter part of the payload format when
GPCS_PROTOCOL_TYPE=802.2_LLC being defined in section 10.5 of 802-2001.
Figure 18 of 802-2001, page 30, see the LLC PDU header field and SNAP
PDU sections that would be placed there. 802.16g would have to write the
rules for the mapping of the DA and SA field.

These would map fairly closely to the IP and Ethernet CSs that are
currently used in the 16ng documents. The permitted values for
GPCS_PROTOCOL_TYPE would be chosen to allow the desired range of
restriction or flexibility to protocol multiplexing, from one format
(e.g. IPv4) to anything (e.g. 802.2).

I would propose what I think is a fairly obvious list..

GPCS_PROTOCOL_TYPE =
	IP	- Any IP. 802.16g defines the encapsulation.
	IPv4	- IPv4 only. 802.16g defined the encapsulation.
	IPv6  - IPv6 only. 802.16g defines the encapsulation.
	802.2 - Any traffic that can pass through the LCC. This means
              SNAP encoding as per 10.3 of 802-2001, but 802.16g must
define
              the encapsulation to include the DA and SA field..
              MSDU:[DA, SA || LLC PDU header || SNAP
PDU],CID=f(sfid,msid)
	802.3 - Ethernet frames I.E.
              MSDU:[DA, SA || ethertype || Ethernet
data],CID=f(sfid,msid)

	And if we want to use bridgeable traffic but restrict the
protocols
      then add in the following options:
	IP over 802.2
	IPv4 over 802.2
	IPv6 over 802.2
	IP over 802.3
	IPv4 over 802.3
	IPv6 over 802.3
	
	Etc..

In the context of heterogeneous media bridged 802 networks (E.G. campus
networks mixing .3, .11, .16 and maybe .17), the flexibility of the
802.2 LCC or 802.3 formats would be greatly appreciated, due to the
trivial port-port format conversion and the lack of configuration
required. In the context of a service provider network, the restricted
types may be appreciated, due to the ability to manage the classes of
traffic that customers may access.

WiMax may have a service provider viewpoint, but the IETF and IEEE
should have a more general one and so support both flexible and
restricted classes of traffic.

I think this all fits in with the philosophy of having the lower layer
providing an indication of what is going on in the upper layer, I am
just calling for that to include the more flexible encapsulations that
are consistent with the 802 model and address the recommendations in
draft-iab-link-encaps-05.

I suspect that draft-iab-link-encaps-05 would not have had to reference
802.16 at all if the only option in 802.16 had been 802.2, since the
issues described would not arise.

DJ


-----Original Message-----
From: Riegel, Maximilian [mailto:[e-mail]] 
Sent: Tuesday, December 05, 2006 5:04 PM
To: David Johnston; Alexandru Petrescu
Cc: [e-mail]
Subject: RE: [16ng] RE: 802.16g GPCS?

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: [e-mail]
[mailto:[e-mail]] On Behalf Of David Johnston
Sent: Tuesday, December 05, 2006 7:39 PM
To: Alexandru Petrescu
Cc: [e-mail]
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:[e-mail]] 
Sent: Tuesday, December 05, 2006 7:38 AM
To: Alexandru Petrescu
Cc: David Johnston; [e-mail]
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
> [e-mail]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
> 



_______________________________________________
16ng mailing list
[e-mail]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng


_______________________________________________
16ng mailing list
[e-mail]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng