Subject: Re: [16ng] Re: Common set of the 16ng terminologies (IPv4CS/IPv6CS or Packet CS)

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Dec 2006 15:32:37 +0100

Thanks for clarifications...

David Johnston wrote:
> Inline..
> 
> Alexandru Petrescu wrote:
> 
>> An IEEE CS seems to me to be a filtering mechanism such as to do IP
>>  header compression (remove header before sending, memorize header,
>>  send; receive, match in table, rebuild header).  Since IP headers 
>> vary between IPv4 and IPv6, and since 802.3 MAC header is different
>> again, I believe the speaking became IPv4 CS, IPv6 CS, ETH CS.  I
>> think CS's goal is only this header compression, nothing else.  I
>> may be wrong though.
>> 
> You are almost right, but not quite. The CS performs PHS (if enabled)
>  but more importantly its other jobs are to emulate the MAC service 
> it is presenting (E.G. 802.3), to perform packet classification and 
> to create use and destroy MAC connections as necessary to perform its
>  function.
> 
> In this context, packet classification is the process of classifying 
> the contents of the packets to make a decision about which connection
> to carry them on. E.G. A CS might set up a BE connection and a
> low-latency rtPS connection then identify VoIP traffic, place it on
> the rtPS connection and place all other traffic on the BE connection.
> Packet classification in the CS is how QoS gets applied to traffic in
> 802.16.

Thanks for explaining, it makes sense to me.  Do all CSs perform this
application-oriented classification?  Is there one which doesn't?

I think I'm interested in a CS that will classify the packets received
from the IP stack only by looking at the Type field of the MAC header
(which should contain 0x86dd to mean "IPv6") and at the dst and src
address fields (48bit, 24 of which are OUI, and that must understand
multicast 33:33:00 too),  I would not (presonally) be interested in CSs
that look at other fields in the IP headers.

>> I think I would be interested in an intermediary layer, between 
>> 802.16e connection-oriented and 802.3 MAC.  This layer's goals 
>> would be to make the connection-oriented layer look like a 802.3 
>> MAC, when
> looked
>> at from the IP stack.  For example, it would map the DL CID to 
>> sender's MAC address, and UL CID to receiver's MAC address; it 
>> would duplicate a packet sent to 33:33:0:0:0:1 (all-nodes MAC) to 
>> all connections up at that interface.  It would transform a MLD 
>> JOIN into starting some connections.  It would assign eg 0x86de as 
>> IPv6 Type within the MAC
> header.
> 
> The goal of the 802.3 CS is explicitly to make the connection 
> oriented MAC CPS look like an 802.3 MAC. Be careful not to adopt 
> functions of 802.1D into the MAC. 802.3 (at least, modern switched 
> Ethernet) does not do what you describe, it is mostly agnostic to the
>  address fields. The switch (802.1D) takes on the role of deciding 
> where traffic goes based on MAC address. This separation is critical
>  to the function of bridged 802 networks. If the MAC assigns packets
>  to CIDs based on MAC address, it will in the general case break the
>  functioning of the bridge and so the network.

Right, I agree mapping these CIDs to MAC addreses may break other bridging.

> The implementor has the choice to implement a system that can 
> determine if the SS is a leaf node (I.E. it terminates L2 traffic to 
> L3) and then it can filter out other MAC addresses, but in the 
> presence of 802.1D switches, the switches can achieve the same effect
>  in a standardized way.

Ok, so since mapping CIDs to MAC addresses is not feasible, then it's
necessary for the IP stack to use the real MAC addresses.

> In the absence of switches you're fine since there is no bridging to
>  break. In the BS lacks knowledge as to whether the SS has a switch 
> behind it (a scenario that is common in access networks like the 
> fiber to my home) then the behavior you describe would break the 
> functioning of the bridge at the SS and lead to unhappy customers.

I agree.  I'm not knowledgeable in this area, and mapping UL/DL CIDs to
src/dst MAC may not work, and it may not be necessary.

>> I am not sure I know whether such intermediary layer exists within
>>  IEEE, or whether it is about to be designed.  Or whether it will
>> be called CS or something else.  Or whether an IEEE CS already does
>>  that.
>> 
> 
> The IEEE 802.16 WG is working on a CS called the GPCS (Generic Packet
>  Convergence Sublayer) as part of 802.16g. This will be a CS that is 
> as its name suggests more generic. It will not care about the type of
> packets carried but will have some specific support for QoS flows.
> 
Does GPCS look at IP headers too trying to classify them?

Does GPCS use 0x86dd as type in MAC header?  Does GPCS use normal 802.3
MAC headers?  Does GPCS support 33:33:00 MAC multicast addresses?

Does GPCS use DOT3 CS PDUs?  DOT1QCS PDUs?  Or IP CS PDUs?

I'm interested in a CS that does not look at IP headers, just at MAC
headers (a DOT3 CS PDU header), and that does not (at least initially)
offer QoS features.  For this CS I think an IPv6 stack knows what the
semantics of the fields in MAC header should be.

> It is intended to be preferred to the traffic specific CSs that 
> currently are in 802.16.
> 
>> If not, then it will probably be designed, but most certainly not 
>> within the IETF.  This is not core IP work, it is link-layer 
>> design. Probably within this group it is possible to come up with 
>> 'goals' for such an intermediary layer.  List what an IPv6 stack 
>> would like to have as behaviour beneath it.  One such behaviour 
>> would be to require all nodes under same BS receive a NA sent by 
>> one node to all-nodes MAC address.
> 
> 
> I think the thing you describe will not be standardized as a layer. 
> It may exist in proprietary implementations that either have no 
> 802.1D bridge, or coordinate the proprietary behavior between both 
> the MAC and the bridge, so as not to break bridging. Some of the 
> behavior you describe is addressed in 802.1D already. Some of it is 
> probably the domain of 16ng, like what to do with an MLD JOIN.

I think there are two ways an IP stack on mobile station is concerned
about the underlying layer: use MAC headers? or use point-to-point links?

I think running IP over a QoS-enhanced MAC layer is something that
should come after the above basic functionality.

Alex
>From [email-masked] Wed Dec  6 00:57:34 2006
Date: Tue, 05 Dec 2006 16:12:14 +0100
From: Alexandru Petrescu <[email-masked]>
To: David Johnston <[email-masked]>
Subject: Re: 802.16g GPCS? (was: [16ng] Re: Common set of the 16ng
	terminologies (IPv4CS/IPv6CS or Packet CS))
cc: [email-masked]

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Dec 2006 16:38:08 +0100

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:
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>

---

From: "Mark Thomas" <[email-masked]>
Date: Tue, 5 Dec 2006 17:00:52 -0000

Hi Alex,

The Ethertype is only useful if you know (by some external means) that
the payload consists of an Ethernet frame. The GPCS makes no such
assumptions, and so we must use 802.16 signalling to identify the basic
protocol.

Mark 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alexandru
Petrescu
Sent: 05 December 2006 15:38
To: Alexandru Petrescu
Cc: [email-masked]; David Johnston
Subject: [16ng] Re: 802.16g GPCS?

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."

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Dec 2006 18:22:22 +0100

Mark Thomas wrote:
> Hi Alex,
> 
> The Ethertype is only useful if you know (by some external means) 
> that the payload consists of an Ethernet frame. The GPCS makes no 
> such assumptions, and so we must use 802.16 signalling to identify 
> the basic protocol.

Mark, thanks for clarification.

I don't understand 802.16 using "signalling" in this case?  Is "802.16
signalling" actually exchanging link-layer (non-IP) frames between two
hosts?  Or you mean sending signals between GPCS and IP stack on same
host (unix signal, sigio, func call, etc).

An interface driver knows whether the driver is MAC-capable or not.

I'm talking about a host whose IP stack wants to put an IP datagram on
the 802.16 interface.  The IP stack would add a MAC header and put
Ethertype into it and then deliver this datagram to the 802.16 of same
host.  Not sure what signalling is needed here, between whom and whom?

I am not thinking at all about how the GPCS on one host should exchange
non-IP link-layer frames with another host; not my intention specify
non-IP inner workings of GPCS.

All I would like GPCS on a host to do is to accept IP datagrams
preceded by MAC headers delivered to it by the IP stack on the same
host, with an 0x86DD Ethertype.

I would also like GPCS to receive from the network packets whose MAC dst
  address starts with 33:33:00 and deliver these packets together with
their MAC headers, to the IP stack on same host.  This is paramount for
IPv6 stateless address auto-config and for ND.

I may be wrong assuming that the role of GPCS is this.  Or maybe another
CS has this role (?)

Alex

> 
> Mark
> 
> -----Original Message----- From: [email-masked] 
> Petrescu Sent: 05 December 2006 15:38 To: Alexandru Petrescu Cc: 
> [email-masked]; David Johnston Subject: [16ng] Re: 802.16g
>  GPCS?
> 
>  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."
> 
> 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
> 
>> David Johnston wrote: [snip]
>> Its title is "Management Plane Procedures and Services".  Is it 
>> this document that describes what GPCS should look like?
>> 
>> Alex
>> 
>> _______________________________________________ 16ng mailing list 
>> [email-masked] 
> _______________________________________________ 16ng mailing list 
> [email-masked]

---

From: "David Johnston" <[email-masked]>
Date: Tue, 5 Dec 2006 10:38:38 -0800

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:[email-masked]] 
Sent: Tuesday, December 05, 2006 7:38 AM
To: Alexandru Petrescu
Cc: David Johnston; [email-masked]
Subject: Re: 802.16g GPCS?

Alex

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Wed, 6 Dec 2006 02:03:41 +0100

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: [email-masked]
[mailto:[email-masked]] On Behalf Of David Johnston
Sent: Tuesday, December 05, 2006 7:39 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: [16ng] RE: 802.16g GPCS?

DJ

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, December 05, 2006 7:38 AM
To: Alexandru Petrescu
Cc: David Johnston; [email-masked]
Subject: Re: 802.16g GPCS?

Alex

---

From: "David Johnston" <[email-masked]>
Date: Tue, 5 Dec 2006 21:10:49 -0800

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:[email-masked]] 
Sent: Tuesday, December 05, 2006 5:04 PM
To: David Johnston; Alexandru Petrescu
Cc: [email-masked]
Subject: RE: [16ng] RE: 802.16g GPCS?

Bye
Max

-----Original Message-----

DJ

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, December 05, 2006 7:38 AM
To: Alexandru Petrescu
Cc: David Johnston; [email-masked]
Subject: Re: 802.16g GPCS?

Alex