Subject: RE: [16ng] FW: Comments to IP over IEEE 802.16 (16ng) Draft Charter

From: "Riegel, Maximilian" <[email-masked]>
Date: Wed, 7 Jun 2006 10:39:45 +0200

I would not recommend to add GPCS to the 16ng charter. Indeed GPCS get
rid of the classification rules in the convergence sublayer and relays
on external classification information, but GPCS does not solve the
issues of 16ng. Even with GPCS there are the two cases of plain IP
transport over 802.16, and IPoETH transport over 802.16.
 
I would recommend to postpone the GPCS topic until 802.16g is stable and
the specifications on IP-CS and IPoETH-CS are done. GPCS may become more
or less an editorial issue then.
 
BTW: GPCS does not solve the IP-CS and IPoETH-CS issues; it only
detaches the classification process (and header suppression process)
from 802.16 and introduces a generic (payload agnostic) data plane SAP
for 802.16.
 
Bye
Max

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Erik Colban
Sent: Tuesday, June 06, 2006 6:59 PM
To: [email-masked]
Subject: [16ng] FW: Comments to IP over IEEE 802.16 (16ng) Draft Charter

Hi,

Below is an email that I sent to the IESG a couple of weeks ago with my
comments to the working group charter.  The point being made is that the
wg should address the Generic Packet Convergence Sublayer (GPCS). The
motivation is provided below. 

The main motivation for GPCS is that a packet may be classified based on
information that is not part of the packet that is passed down to the
802.16 MAC Convergence sublayer. For instance, in the down-link
direction, a packet may arrive at the base station encapsulated in GRE.
Classification may be based on the GRE key. However, only the
encapsulated IP packet is passed down to the MAC CS.  Neither EtherCS
nor  IPCS will do, since the classification is done outside the MAC
Convergence Sublayer.

Erik

________________________________

From: Erik Colban 
Sent: Wednesday, May 24, 2006 3:34 PM
To: [email-masked]'
Subject: Comments to IP over IEEE 802.16 (16ng) Draft Charter

The Description of Working Group, third paragraph states that "in IP CS
case, the criteria by which the Base Station (or other headend elements)
sets up the 802.16 MAC connections for data transport are not part of
the 802.16 standard, and depend on the type of data services being
offered (e.g., the set up of link layer connections will be different
for IPv4 and IPv6 services)." While this is true according to published
802.16 standards, 802.16 has added a Generic Packet Convergence Sublayer
(GPCS) to Draft Amendment 802.16g, which provides a generic interface to
the upper layer. 

With GPCS, the upper layer protocol becomes transparent to the 802.16
MAC convergence sublayer. At the sending entity, the upper layer
provides an SDU to the MAC together with an Service Flow Identifier
(SFID) and a mobile station identifier (MSID). The MAC maps the SDU as
is (i.e. raw) to the connection uniquely identified by the (SFID, MSID)
pair. At the receiving end, the MAC delivers the SDU to the upper layer.

GPCS effectively moves the burden of classifying packets and packet
header suppression to the upper layer whereas the MAC CS itself uses a
single rule to classify packets, namely the use of the (SFID, MSID)
pair. Rather than having 802.16 specify how classification and PHS is
done for various upper layer protocols (as is the case for the service
specific CS types that have been specified so far), the expectation is
that there will be "ProtocolX-over-802.16" documents to specify the
usage of ProtocolX over GPCS. Such documents are out of the scope of
802.16 and could be provided by whichever organization is responsible
for the specification of ProtocolX. Hence, in the case of IPv4 and IPv6,
it is natural to expect that IETF will provide RFCs that address how
IPv4 and IPv6 is to be used over GPCS. Such RFCs will include how the
mobile station and the base station exchange classification rules. The
RFCs could address PHS either by providing rules a la those specified in
802.16 or by referencing other RFCs such as the RoHC RFCs. 

Since the upper layer protocol is transparent to GPCS, different
protocols may be used at different times over the same service flow/MAC
connection. For instance IPv4 flows, IPv6 flows, or Ethernet flows could
be transported over the same connection if they are associated with the
same QoS. A Multiprotocol encapsulation protocol, where the packet
headers identify the protocol of the encapsulated packet, has been
proposed in 802.16. However, 802.16 has determined that it is outside
its scope to address the specification of such a "Multiprotocol"
protocol. 

In view of the above, I would like to suggest that the scope of the
working group cover the usage of GPCS and the following additions be
made to the Description of the Working Group:

"- Produce "IPv6 over IEEE 802.16 Networks in conjunction with GPCS"
to define IPv6 operation including the transmission of IPv6 over IEEE
802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and
Stateless Address Configuration, Broadcast, Multicast, etc.
[Proposed Standard RFC]

- Produce "IPv4 over IEEE 802.16 Networks in conjunction with GPCS"
to define IPv4 operation including the transmission of IPv4 over IEEE
802.16 links, ARP operation, Stateful Address Configuration (DHCPv4),
Broadcast, Multicast, etc [Proposed Standard RFC]

- Produce "Multiprotocol over IEEE 802.16 Networks in conjunction with
GPCS"
to define multiprotocol operation over IEEE
802.16 links [Proposed Standard RFC]"

The working group may eventually find it  beneficial to combine some of
the proposed RFCs; for instance, "IPv4 operation over IEEE 802.16
Networks" could cover the cases of IPv4 CS, Ethernet CS and GPCS.

---

From: "Erik Colban" <[email-masked]>
Date: Wed, 7 Jun 2006 17:10:16 -0400

Whether GPCS is added now or later, it is something that one would need
to keep in mind. Otherwise one could end up with unpractical design
choices. 

For instance, IP-CS only allows for classification based on the
information in the IP packet. Hence, if classification is based on
information contained in the encapsulting Ethernet frame, then IPoETH-CS
must be used. However, this is only true in the absence of GPCS. 

When GPCS is used, the sending entity (BS or SS) may classify the IP
packet based on the encapsulating Ethernet frame, then strip of the
Ethernet header before passing the IP packet to the MAC convergence
sublayer. At the receiving entity the MAC CS delivers the IP packet.
Based on the service flow that the IP packet is received on the
receiving entity is able to regenerate the Ethernet frame (if
necessary).  The same could be applied when PPP frames are encapsulated
in Ethernet frames; the sending entity strips off the encapsulating
Ethernet frame, and the receivig entity regenerates the Ethernet frame
based on the service flow that the PPP frame is received on. There is no
need for yet another CS. 

Yes, I agree that GPCS does not solve all issues, but the problem
statement is different. I agree that classification and header
suppression is not done by the MAC, but still needs to be performed. The
stronger reason why IETF should look at GPCS.

Erik

From: Riegel, Maximilian [mailto:[email-masked]] 
Sent: Wednesday, June 07, 2006 1:40 AM
To: Erik Colban; [email-masked]
Subject: RE: [16ng] FW: Comments to IP over IEEE 802.16 (16ng) Draft
Charter

Bye

Max

Hi,

Erik

From: Erik Colban