Subject: Re: [16ng] how 802.16 MAC associates higher layer data packets to CID / Service Flow

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 31 May 2006 21:18:43 +0530

The upper part of 802.16 MAC, service-specific convergence sublayers, interface
to higher layers, and  provides the classification of upper layer
service data units
to the proper MAC connection. For example in case of IPv6 CS, IPv6 source and
destination addresses, next header in the last header of the IP header chain,
Traffic Class, and, source and destination port numbers are used as classifiers.

Syam

On 5/31/06, vimal raj <[email-masked]> wrote:
>
>
>
>
>
> Hiii..
>
>
>
> This is my first mail to this group.. I have some doubt in the
> implementation part of 802.16's MAC especially at associating higher layer
> packets with CID's and service flows.
>
>
>
>
>
> Regards,
>
> vimal
>
>
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>
>
>
>From [email-masked] Thu Jun  1 11:43:27 2006
Date: Thu, 01 Jun 2006 10:47:37 +0900
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
Subject: [16ng] Call for agenda item in Montreal

Dear all, 

It is time to start thinking about 16ng agenda items
for the Montreal meeting on July. Please forward 
any 16ng agenda items (or relevant issues) to be 
presented at upcoming IETF to Gabriel and myself 
including required items below;

o Required Items:

[1] Title of presentation:
[2] Speaker:
[3] Associated I-D or document:
[4] Slot length:
[5] Abstract (in brief)

Note: I've requested 2/30 hours for our discussion
and several items should be a priority than others 
at this meeting. So, you (editor of each item) don't
need to request any slot for relevant discussion. 

o Item: Problem Statement, Goal and Requirement
   Editor: Junghoon Jee / 20 minutes

o Item: IP over Ethernet CS
   Editor: Max Riegel / 30 minutes

o Item: IPv6 over IP CS
   Editor: Syam Madanapalli / 30 minutes

Thanks, 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Thu Jun  1 11:47:43 2006
Date: Thu, 01 Jun 2006 10:51:53 +0900
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
Subject: [16ng] draft-ietf-v6ops-802-16-deployment-scenarios-00.txt

The relevant draft was published by V6OPS as a
new WG item. Please take a look at it and make
your comments if any...

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working Group of the IETF.
> 
> Title : ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks
> Author(s) : M. Shin, Y. Han
> Filename : draft-ietf-v6ops-802-16-deployment-scenarios-00.txt
> Pages : 22
> Date : 2006-5-30
> 
>   This document provides detailed description of IPv6 deployment and
>   integration methods and scenarios in wireless broadband access
>   networks in coexistence with deployed IPv4 services.  In this
>   document we will discuss main components of IPv6 IEEE 802.16 access
>   network and its differences from IPv4 IEEE 802.16 networks and how
>   IPv6 is deployed and integrated in each of the IEEE 802.16
>   technologies using tunneling mechanisms and native IPv6.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-802-16-deployment-scenarios-00.txt

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Wed Jun  7 02:55:39 2006
Content-class: urn:content-classes:message
Date: Tue, 6 Jun 2006 12:58:31 -0400
From: "Erik Colban" <[email-masked]>
To: <[email-masked]>
Subject: [16ng] FW: Comments to IP over IEEE 802.16 (16ng) Draft Charter

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6898A.716015C7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

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.=20

=20

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.

=20

Erik

________________________________

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

=20

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.=20

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.=20

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.=20

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.

------_=_NextPart_001_01C6898A.716015C7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Below is an email that I sent to =
the IESG a
couple of weeks ago with my comments to the working group charter.&nbsp; =
The point
being made is that the wg should address the Generic Packet Convergence
Sublayer (GPCS). The motivation is provided below. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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.&nbsp; Neither =
EtherCS nor &nbsp;IPCS
will do, since the classification is done outside the MAC Convergence =
Sublayer.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Erik<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Erik =
Colban <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, May 24, =
2006 3:34
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Comments to IP =
over IEEE
802.16 (16ng) Draft Charter</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The Description of Working Group, third paragraph states that =
&quot;in
IP CS<br>
case, the criteria by which the Base Station (or other headend =
elements)<br>
sets up the 802.16 MAC connections for data transport are not part =
of<br>
the 802.16 standard, and depend on the type of data services being<br>
offered (e.g., the set up of link layer connections will be =
different<br>
for IPv4 and IPv6 services).&quot; While this is true according to =
published<br>
802.16 standards, 802.16 has added a Generic Packet Convergence =
Sublayer<br>
(GPCS) to Draft Amendment 802.16g, which provides a generic interface =
to<br>
the upper layer. <br>
<br>
With GPCS, the upper layer protocol&nbsp;becomes transparent to the =
802.16<br>
MAC convergence sublayer. At the sending entity, the upper layer<br>
provides an SDU to the MAC together with an Service Flow Identifier<br>
(SFID) and a mobile station identifier (MSID). The MAC maps the SDU =
as<br>
is (i.e. raw) to the connection uniquely identified by the (SFID, =
MSID)<br>
pair. At the receiving end, the MAC delivers the SDU to the upper =
layer.<br>
<br>
GPCS effectively moves the burden of classifying packets and packet<br>
header suppression to the upper layer whereas the MAC CS itself uses =
a<br>
single rule to classify packets, namely the use of the (SFID, MSID)<br>
pair. Rather than having 802.16 specify how classification and PHS =
is<br>
done for various upper layer protocols (as is the case for the =
service<br>
specific CS types that have been specified so far), the expectation =
is<br>
that there will be &quot;ProtocolX-over-802.16&quot; documents to =
specify the<br>
usage of ProtocolX over GPCS. Such documents are out of the scope of<br>
802.16 and could be provided by whichever organization is =
responsible<br>
for the specification of ProtocolX. Hence, in the case of IPv4 and =
IPv6,<br>
it is natural to expect that IETF will provide RFCs that address how<br>
IPv4 and IPv6 is to be used over GPCS. Such RFCs will include how =
the<br>
mobile station and the base station exchange classification rules. =
The<br>
RFCs could address PHS either by providing rules a la those specified =
in<br>
802.16 or by referencing other RFCs such as the RoHC RFCs. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'><br>
Since the upper layer protocol is transparent to GPCS, different<br>
protocols may be used at different times over the same service =
flow/MAC<br>
connection. For instance IPv4 flows, IPv6 flows, or Ethernet flows =
could<br>
be transported over the same connection if they are associated with =
the<br>
same QoS. A Multiprotocol encapsulation protocol, where the packet<br>
headers identify the protocol of the encapsulated packet, has been<br>
proposed in 802.16. However, 802.16 has determined that it is =
outside<br>
its scope to address the specification of such a =
&quot;Multiprotocol&quot;<br>
protocol.&nbsp;<br>
<br>
In view of the above, I would like to suggest that the scope of the<br>
working group cover the usage of GPCS and the following additions be<br>
made to the Description of the Working Group:<br>
<br>
&quot;- Produce &quot;IPv6 over IEEE 802.16 Networks in conjunction with
GPCS&quot;<br>
to define IPv6 operation including the transmission of IPv6 over =
IEEE<br>
802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and<br>
Stateless Address Configuration, Broadcast, Multicast, etc.<br>
[Proposed Standard RFC]<br>
<br>
- Produce &quot;IPv4 over IEEE 802.16 Networks in conjunction with =
GPCS&quot;<br>
to define IPv4 operation including the transmission of IPv4 over =
IEEE<br>
802.16 links, ARP operation, Stateful Address Configuration =
(DHCPv4),<br>
Broadcast, Multicast, etc [Proposed Standard RFC]<br>
<br>
- Produce &quot;Multiprotocol over IEEE 802.16 Networks in conjunction =
with<br>
GPCS&quot;<br>
to define multiprotocol operation over IEEE<br>
802.16 links [Proposed Standard RFC]&quot;<br>
<br>
The working group may eventually find it&nbsp; beneficial to combine =
some of<br>
the proposed RFCs; for instance, &quot;IPv4 operation over IEEE =
802.16<br>
Networks&quot; could cover the cases of IPv4 CS, Ethernet CS and =
GPCS.</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=

</div>

</body>

</html>

------_=_NextPart_001_01C6898A.716015C7--
>From [email-masked] Wed Jun  7 11:46:38 2006
Date: Wed, 07 Jun 2006 10:46:32 +0900
From: Soohong Daniel Park <[email-masked]>
Subject: Re: [16ng] FW: Comments to IP over IEEE 802.16 (16ng) Draft Charter
To: Erik Colban <[email-masked]>, [email-masked]

Erik,

GPCS is still under construction within 16g. Also, 16g
is not a final specification, but ongoing letter ballot (as far
as I am concern). IPCS and EthernetCS are already
tangible status in IEEE802.16 and in scope of WiMAX
specification of course. That's why 16ng is taking into
account both CS at this stage. From the second round,
we may be able to consider further issues, but I am
encouraging you to continue your effort on that in 16ng.

Regards.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Wed Jun  7 18:37:01 2006
Content-class: urn:content-classes:message
Subject: RE: [16ng] FW: Comments to IP over IEEE 802.16 (16ng) Draft Charter
Date: Wed, 7 Jun 2006 10:39:45 +0200
From: "Riegel, Maximilian" <[email-masked]>
To: "Erik Colban" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C68A0D.EDD5689D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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.
=20
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.
=20
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.
=20
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,

=20

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.=20

=20

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.

=20

Erik

________________________________

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

=20

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.=20

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.=20

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.=20

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.

------_=_NextPart_001_01C68A0D.EDD5689D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2876" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D440142408-07062006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2>I would not recommend to add GPCS to the 16ng =
charter.=20
Indeed GPCS get rid of the classification rules&nbsp;in the convergence =
sublayer=20
and relays on external classification information, but GPCS does not =
solve the=20
issues of 16ng. Even with GPCS there are the two cases of plain IP =
transport=20
over 802.16, and IPoETH transport over 802.16.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D440142408-07062006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D440142408-07062006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2>I would recommend to postpone the GPCS topic =
until 802.16g=20
is stable and the specifications on IP-CS and IPoETH-CS are done. GPCS =
may=20
become more or less an editorial issue then.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D440142408-07062006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D440142408-07062006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2>BTW: GPCS does not solve the IP-CS and =
IPoETH-CS issues; it=20
only detaches the classification process (and header suppression=20
process)&nbsp;from 802.16 and introduces a generic&nbsp;(payload=20
agnostic)&nbsp;data plane SAP for 802.16.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D440142408-07062006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D440142408-07062006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2>Bye</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D440142408-07062006><FONT =
face=3D"Courier New"=20
color=3D#000080 size=3D2>Max</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Erik=20
Colban<BR><B>Sent:</B> Tuesday, June 06, 2006 6:59 PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> [16ng] FW: Comments to IP =
over IEEE=20
802.16 (16ng) Draft Charter<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Hi,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Below is an =
email that=20
I sent to the IESG a couple of weeks ago with my comments to the working =
group=20
charter.&nbsp; The point being made is that the wg should address the =
Generic=20
Packet Convergence Sublayer (GPCS). The motivation is provided below.=20
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The main =
motivation for=20
GPCS is that a packet may be classified based on information that is not =
part of=20
the packet that is passed down to the 802.16 MAC Convergence sublayer. =
For=20
instance, in the down-link direction, a packet may arrive at the base =
station=20
encapsulated in GRE. Classification may be based on the GRE key. =
However, only=20
the encapsulated IP packet is passed down to the MAC CS.&nbsp; Neither =
EtherCS=20
nor &nbsp;IPCS will do, since the classification is done outside the MAC =

Convergence Sublayer.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Erik<o:p></o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Erik=20
Colban <BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> =
Wednesday, May=20
24, 2006 3:34 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
[email-masked]'<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
Comments to IP over IEEE 802.16 (16ng) Draft=20
Charter</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">The Description of Working Group, third =
paragraph states=20
that "in IP CS<BR>case, the criteria by which the Base Station (or other =
headend=20
elements)<BR>sets up the 802.16 MAC connections for data transport are =
not part=20
of<BR>the 802.16 standard, and depend on the type of data services=20
being<BR>offered (e.g., the set up of link layer connections will be=20
different<BR>for IPv4 and IPv6 services)." While this is true according =
to=20
published<BR>802.16 standards, 802.16 has added a Generic Packet =
Convergence=20
Sublayer<BR>(GPCS) to Draft Amendment 802.16g, which provides a generic=20
interface to<BR>the upper layer. <BR><BR>With GPCS, the upper layer=20
protocol&nbsp;becomes transparent to the 802.16<BR>MAC convergence =
sublayer. At=20
the sending entity, the upper layer<BR>provides an SDU to the MAC =
together with=20
an Service Flow Identifier<BR>(SFID) and a mobile station identifier =
(MSID). The=20
MAC maps the SDU as<BR>is (i.e. raw) to the connection uniquely =
identified by=20
the (SFID, MSID)<BR>pair. At the receiving end, the MAC delivers the SDU =
to the=20
upper layer.<BR><BR>GPCS effectively moves the burden of classifying =
packets and=20
packet<BR>header suppression to the upper layer whereas the MAC CS =
itself uses=20
a<BR>single rule to classify packets, namely the use of the (SFID,=20
MSID)<BR>pair. Rather than having 802.16 specify how classification and =
PHS=20
is<BR>done for various upper layer protocols (as is the case for the=20
service<BR>specific CS types that have been specified so far), the =
expectation=20
is<BR>that there will be "ProtocolX-over-802.16" documents to specify=20
the<BR>usage of ProtocolX over GPCS. Such documents are out of the scope =

of<BR>802.16 and could be provided by whichever organization is=20
responsible<BR>for the specification of ProtocolX. Hence, in the case of =
IPv4=20
and IPv6,<BR>it is natural to expect that IETF will provide RFCs that =
address=20
how<BR>IPv4 and IPv6 is to be used over GPCS. Such RFCs will include how =

the<BR>mobile station and the base station exchange classification =
rules.=20
The<BR>RFCs could address PHS either by providing rules a la those =
specified=20
in<BR>802.16 or by referencing other RFCs such as the RoHC RFCs.=20
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><BR>Since the upper layer protocol is =
transparent to=20
GPCS, different<BR>protocols may be used at different times over the =
same=20
service flow/MAC<BR>connection. For instance IPv4 flows, IPv6 flows, or =
Ethernet=20
flows could<BR>be transported over the same connection if they are =
associated=20
with the<BR>same QoS. A Multiprotocol encapsulation protocol, where the=20
packet<BR>headers identify the protocol of the encapsulated packet, has=20
been<BR>proposed in 802.16. However, 802.16 has determined that it is=20
outside<BR>its scope to address the specification of such a=20
"Multiprotocol"<BR>protocol.&nbsp;<BR><BR>In view of the above, I would =
like to=20
suggest that the scope of the<BR>working group cover the usage of GPCS =
and the=20
following additions be<BR>made to the Description of the Working=20
Group:<BR><BR>"- Produce "IPv6 over IEEE 802.16 Networks in conjunction =
with=20
GPCS"<BR>to define IPv6 operation including the transmission of IPv6 =
over=20
IEEE<BR>802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6)=20
and<BR>Stateless Address Configuration, Broadcast, Multicast, =
etc.<BR>[Proposed=20
Standard RFC]<BR><BR>- Produce "IPv4 over IEEE 802.16 Networks in =
conjunction=20
with GPCS"<BR>to define IPv4 operation including the transmission of =
IPv4 over=20
IEEE<BR>802.16 links, ARP operation, Stateful Address Configuration=20
(DHCPv4),<BR>Broadcast, Multicast, etc [Proposed Standard RFC]<BR><BR>- =
Produce=20
"Multiprotocol over IEEE 802.16 Networks in conjunction =
with<BR>GPCS"<BR>to=20
define multiprotocol operation over IEEE<BR>802.16 links [Proposed =
Standard=20
RFC]"<BR><BR>The working group may eventually find it&nbsp; beneficial =
to=20
combine some of<BR>the proposed RFCs; for instance, "IPv4 operation over =
IEEE=20
802.16<BR>Networks" could cover the cases of IPv4 CS, Ethernet CS and=20
GPCS.</SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P></DIV></BODY></HTML>

------_=_NextPart_001_01C68A0D.EDD5689D--
>From [email-masked] Thu Jun  8 07:07:38 2006
Content-class: urn:content-classes:message
Subject: RE: [16ng] FW: Comments to IP over IEEE 802.16 (16ng) Draft Charter
Date: Wed, 7 Jun 2006 17:10:16 -0400
From: "Erik Colban" <[email-masked]>
To: "Riegel, Maximilian" <[email-masked]>,
   <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C68A76.C6D7EC28
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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.=20

=20

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.=20

=20

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.=20

=20

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.

=20

Erik

=20

=20

________________________________

From: Riegel, Maximilian [mailto:[email-masked]]=20
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

=20

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.

=20

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.

=20

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.

=20

Bye

Max

=20

________________________________

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,

=20

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.=20

=20

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.

=20

Erik

________________________________

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

=20

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.=20

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.=20

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.=20

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.

------_=_NextPart_001_01C68A76.C6D7EC28
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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). &nbsp;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. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Erik<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Riegel,
Maximilian [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 07, =
2006
1:40 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Erik Colban;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [16ng] FW: =
Comments
to IP over IEEE 802.16 (16ng) Draft Charter</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:navy'>I would =
not
recommend to add GPCS to the 16ng charter. Indeed GPCS get rid of the
classification rules&nbsp;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.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:navy'>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.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:navy'>BTW: =
GPCS does
not solve the IP-CS and IPoETH-CS issues; it only detaches the =
classification
process (and header suppression process)&nbsp;from 802.16 and introduces =
a
generic&nbsp;(payload agnostic)&nbsp;data plane SAP for =
802.16.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";color:navy'>Bye</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";color:navy'>Max</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] =
[mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Erik Colban<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, June 06, =
2006 6:59
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [16ng] FW: =
Comments to IP
over IEEE 802.16 (16ng) Draft Charter</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Below is an email that I sent to =
the IESG
a couple of weeks ago with my comments to the working group =
charter.&nbsp; The
point being made is that the wg should address the Generic Packet =
Convergence
Sublayer (GPCS). The motivation is provided below. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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.&nbsp; Neither =
EtherCS nor
&nbsp;IPCS will do, since the classification is done outside the MAC =
Convergence
Sublayer.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Erik<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Erik =
Colban <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, May 24, =
2006 3:34
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Comments to IP =
over IEEE
802.16 (16ng) Draft Charter</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The Description of Working Group, third paragraph states that =
&quot;in
IP CS<br>
case, the criteria by which the Base Station (or other headend =
elements)<br>
sets up the 802.16 MAC connections for data transport are not part =
of<br>
the 802.16 standard, and depend on the type of data services being<br>
offered (e.g., the set up of link layer connections will be =
different<br>
for IPv4 and IPv6 services).&quot; While this is true according to =
published<br>
802.16 standards, 802.16 has added a Generic Packet Convergence =
Sublayer<br>
(GPCS) to Draft Amendment 802.16g, which provides a generic interface =
to<br>
the upper layer. <br>
<br>
With GPCS, the upper layer protocol&nbsp;becomes transparent to the =
802.16<br>
MAC convergence sublayer. At the sending entity, the upper layer<br>
provides an SDU to the MAC together with an Service Flow Identifier<br>
(SFID) and a mobile station identifier (MSID). The MAC maps the SDU =
as<br>
is (i.e. raw) to the connection uniquely identified by the (SFID, =
MSID)<br>
pair. At the receiving end, the MAC delivers the SDU to the upper =
layer.<br>
<br>
GPCS effectively moves the burden of classifying packets and packet<br>
header suppression to the upper layer whereas the MAC CS itself uses =
a<br>
single rule to classify packets, namely the use of the (SFID, MSID)<br>
pair. Rather than having 802.16 specify how classification and PHS =
is<br>
done for various upper layer protocols (as is the case for the =
service<br>
specific CS types that have been specified so far), the expectation =
is<br>
that there will be &quot;ProtocolX-over-802.16&quot; documents to =
specify the<br>
usage of ProtocolX over GPCS. Such documents are out of the scope of<br>
802.16 and could be provided by whichever organization is =
responsible<br>
for the specification of ProtocolX. Hence, in the case of IPv4 and =
IPv6,<br>
it is natural to expect that IETF will provide RFCs that address how<br>
IPv4 and IPv6 is to be used over GPCS. Such RFCs will include how =
the<br>
mobile station and the base station exchange classification rules. =
The<br>
RFCs could address PHS either by providing rules a la those specified =
in<br>
802.16 or by referencing other RFCs such as the RoHC RFCs. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'><br>
Since the upper layer protocol is transparent to GPCS, different<br>
protocols may be used at different times over the same service =
flow/MAC<br>
connection. For instance IPv4 flows, IPv6 flows, or Ethernet flows =
could<br>
be transported over the same connection if they are associated with =
the<br>
same QoS. A Multiprotocol encapsulation protocol, where the packet<br>
headers identify the protocol of the encapsulated packet, has been<br>
proposed in 802.16. However, 802.16 has determined that it is =
outside<br>
its scope to address the specification of such a =
&quot;Multiprotocol&quot;<br>
protocol.&nbsp;<br>
<br>
In view of the above, I would like to suggest that the scope of the<br>
working group cover the usage of GPCS and the following additions be<br>
made to the Description of the Working Group:<br>
<br>
&quot;- Produce &quot;IPv6 over IEEE 802.16 Networks in conjunction with
GPCS&quot;<br>
to define IPv6 operation including the transmission of IPv6 over =
IEEE<br>
802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and<br>
Stateless Address Configuration, Broadcast, Multicast, etc.<br>
[Proposed Standard RFC]<br>
<br>
- Produce &quot;IPv4 over IEEE 802.16 Networks in conjunction with =
GPCS&quot;<br>
to define IPv4 operation including the transmission of IPv4 over =
IEEE<br>
802.16 links, ARP operation, Stateful Address Configuration =
(DHCPv4),<br>
Broadcast, Multicast, etc [Proposed Standard RFC]<br>
<br>
- Produce &quot;Multiprotocol over IEEE 802.16 Networks in conjunction =
with<br>
GPCS&quot;<br>
to define multiprotocol operation over IEEE<br>
802.16 links [Proposed Standard RFC]&quot;<br>
<br>
The working group may eventually find it&nbsp; beneficial to combine =
some of<br>
the proposed RFCs; for instance, &quot;IPv4 operation over IEEE =
802.16<br>
Networks&quot; could cover the cases of IPv4 CS, Ethernet CS and =
GPCS.</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=

</div>

</body>

</html>

------_=_NextPart_001_01C68A76.C6D7EC28--
>From [email-masked] Mon Jun 12 12:57:50 2006
Date: Mon, 12 Jun 2006 12:00:00 +0900
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
Subject: [16ng] 16ng tentative schedule in Montreal

FYI.

Monday, July 10.
1520-1720 Afternoon Session II 

Room 513C-F    INT    16ng    IP over IEEE 802.16 Networks BOF

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Mon Jun 12 23:06:17 2006
Date: Mon, 12 Jun 2006 16:07:59 +0300
From: Jari Arkko <[email-masked]>
To: Soohong Daniel Park <[email-masked]>
Subject: Re: [16ng] 16ng tentative schedule in Montreal
cc: [email-masked]

Right, but the time and day is subject to change. There's currently multiple
groups in this slot that I need to be in. Also, Daniel had the
same issue. So don't book your flights based on this information :-)

--Jari

Soohong Daniel Park wrote:

>FYI.
>
>Monday, July 10.
>1520-1720 Afternoon Session II 
>
>Room 513C-F    INT    16ng    IP over IEEE 802.16 Networks BOF
>
>
>
>Daniel (Soohong Daniel Park)
>Mobile Convergence Laboratory, SAMSUNG Electronics.
>_______________________________________________
>16ng mailing list
>[email-masked]
>http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>
>
>  
>