Subject: [16ng] WG Adoption : draft-riegel-16ng-ip-over-eth-over-80216-01

From: "Soohong Daniel Park" <[email-masked]>
Date: Wed, 8 Nov 2006 08:02:15 +0900

Hi folks,

During the meeting today, we had consensus that the Transmission of IP
Packets over Ethernet over IEEE 802.16 would be accepted as a WG
draft.

The relevant WG deliverables are described in our charter:

- Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet
CS" 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 Ethernet
CS" 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]

The latest version of this document can be found at:
http://www.watersprings.org/pub/id/draft-riegel-16ng-ip-over-eth-over-80216-01.txt

NOTE: Both IPv4 and IPv6 are merged into the one document following
the WG consensus and AD's approval.

Unless there are any strong objections from the ML, we'll ask the
author to publish the next version as a WG I-D.

Thanks,

Gabriel & Daniel
Chairs, 16NG Working Group
>From [email-masked] Wed Nov  8 12:57:21 2006
Content-class: urn:content-classes:message
Subject: RE: [16ng] WG Adoption : draft-riegel-16ng-ip-over-eth-over-80216-01
Date: Tue, 7 Nov 2006 19:20:33 -0800
From: "David Johnston" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Comments on draft-riegel-16ng-ip-over-eth-over-80216-01...

A little cleanup. Change
3.
   Service-specific Convergence Sublayer (CS):  Sublayer in the IEEE
802.16
      MAC layer which classifiers external network data and associates
      them to the proper MAC service flow identifier and connection
      identifier

7.1 s/feeded/fed/

7.1 I don't understand the text mandating unicasting to the SS. I think
it is ambiguous as to which layers address with unicast addresses and
which address with multicast addresses. There are 3 that matter.
1) The 802.16 MAC CPS, that has unicast and multicast CIDs. =20
2) The 802.3 CS service that carries unicast, broadcast and multicast 48
bit MAC addresses
3) The IP layer that carries unicast, broadcast and multicast v4 and v6
addresses.

Which of these is being constrained to be unicast? (1) is already
constrained by text earlier in the document.

Broadcast IP traffic should be carried on a broadcast MAC address over a
unicast connection. 802.1D specifies the meaning of a point-to-point LAN
in the context of bridging and 802.16k specifies that a pair of
communicating 802.16 CSs are in fact such a point-to-point LAN. So this
text perhaps should specify that all IP traffic, regardless of address
type is carried over Ethernet packets that are carried over unicast CIDs
at the 802.16 MAC CPS sublayer.

DJ

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Soohong Daniel
Park
Sent: Tuesday, November 07, 2006 3:02 PM
To: [email-masked]
Subject: [16ng] WG Adoption :
draft-riegel-16ng-ip-over-eth-over-80216-01

Hi folks,

During the meeting today, we had consensus that the Transmission of IP
Packets over Ethernet over IEEE 802.16 would be accepted as a WG
draft.

The relevant WG deliverables are described in our charter:

- Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet
CS" 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 Ethernet
CS" 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]

The latest version of this document can be found at:
http://www.watersprings.org/pub/id/draft-riegel-16ng-ip-over-eth-over-80
216-01.txt

NOTE: Both IPv4 and IPv6 are merged into the one document following
the WG consensus and AD's approval.

Unless there are any strong objections from the ML, we'll ask the
author to publish the next version as a WG I-D.

Thanks,

Gabriel & Daniel
Chairs, 16NG Working Group
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>RE: [16ng] WG Adoption : =
draft-riegel-16ng-ip-over-eth-over-80216-01</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">C</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">omments on</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Courier =
New">draft-riegel-16ng-ip-over-eth-over-80216-01</FONT></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&#8230;</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">A =
little c</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Courier New">leanup. Change</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">3.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp; Service-specific Convergence Sublayer (CS):&nbsp; =
Sublayer in</FONT></SPAN><SPAN LANG=3D"en-us"><U> <FONT SIZE=3D2 =
FACE=3D"Courier New">the</FONT></U></SPAN><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2 FACE=3D"Courier New"> IEEE 802.16</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MAC layer which =
classifie</FONT></SPAN><SPAN LANG=3D"en-us"><STRIKE><U><FONT SIZE=3D2 =
FACE=3D"Courier New">r</FONT></U></STRIKE></SPAN><SPAN =
LANG=3D"en-us"><U><FONT SIZE=3D2 FACE=3D"Courier =
New">s</FONT></U></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Courier New"> external network data and =
associates</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; them to the proper MAC service flow =
identifier and connection</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifier</FONT></SPAN></P>
<BR>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">7.1 s/feeded/fed/</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">7.1 I don&#8217;t understand the</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">text</FONT></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-us"> <FONT SIZE=3D2 FACE=3D"Courier =
New">mandating</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Courier New"> unicasting to the SS. I think it is ambiguous as =
to which layers address</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT =
SIZE=3D2 FACE=3D"Courier New">with</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">unicast</FONT></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New"> =
addresses</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Courier New"> and which address</FONT></SPAN><SPAN =
LANG=3D"en-us"> <FONT SIZE=3D2 FACE=3D"Courier =
New">with</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Courier New">multicast</FONT></SPAN><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2 FACE=3D"Courier New"> addresses</FONT></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">. There are 3 that =
matter.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">1) =
The 802.16 MAC CPS, that has unicast and multicast =
CIDs.&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> </SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">2) =
The 802.3</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Courier New">CS</FONT></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Courier New"> service that carries unicast, broadcast and =
multicast 48 bit MAC addresses</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">3) =
The IP layer that carries unicast, broadcast and multicast v4 and v6 =
addresses.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Which of these is being constrained to be unicast? (1) is already =
constrained by text earlier in the document.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Broadcast IP traffic should be carried on a broadcast MAC address =
over a unicast connection. 802.1D specifies the meaning of a =
point-to-point LAN in the context of bridging and 802.16k specifies that =
a pair of communicating 802.16 CSs are in fact such a point-to-point =
LAN. So this text perhaps should specify that all IP traffic, regardless =
of address type is carried over Ethernet packets that are carried over =
unicast CIDs at the 802.16 MAC CPS sublayer.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">DJ</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">-----Original Message-----<BR>
From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:16ng-bounces@eeca=
16.sogang.ac.kr</A>] On Behalf Of Soohong Daniel Park<BR>
Sent: Tuesday, November 07, 2006 3:02 PM<BR>
To: [email-masked]<BR>
Subject: [16ng] WG Adoption : =
draft-riegel-16ng-ip-over-eth-over-80216-01</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">Hi =
folks,</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">During the meeting today, we had consensus that the Transmission of =
IP</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Packets over Ethernet over IEEE 802.16 would be accepted as a =
WG</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">draft.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">The relevant WG deliverables are described in our =
charter:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">- =
Produce &quot;IPv6 over IEEE 802.16 Networks in conjunction with =
Ethernet</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">CS&quot; to define IPv6 operation including the transmission of =
IPv6 over</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) =
and</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Stateless Address Configuration, Broadcast, Multicast, etc. =
[Proposed</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Standard RFC]</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">- =
Produce &quot;IPv4 over IEEE 802.16 Networks in conjunction with =
Ethernet</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">CS&quot; to define IPv4 operation including the transmission of =
IPv4 over</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">IEEE 802.16 links, ARP operation, Stateful Address =
Configuration</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">(DHCPv4), Broadcast, Multicast, etc [Proposed Standard =
RFC]</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">The latest version of this document can be found =
at:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"http://www.watersprings.org/pub/id/draft-riegel-16ng-ip-over-eth-=
over-80216-01.txt">http://www.watersprings.org/pub/id/draft-riegel-16ng-i=
p-over-eth-over-80216-01.txt</A></FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">NOTE: Both IPv4 and IPv6 are merged into the one document =
following</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">the WG consensus and AD's approval.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Unless there are any strong objections from the ML, we'll ask =
the</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">author to publish the next version as a WG I-D.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Thanks,</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Gabriel &amp; Daniel</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">Chairs, 16NG Working Group</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">_______________________________________________</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">16ng mailing list</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">[email-masked]</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"http://eeca16.sogang.ac.kr/mailman/listinfo/16ng">http://eeca16.s=
ogang.ac.kr/mailman/listinfo/16ng</A></FONT></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C702E4.DA49DD48--
>From [email-masked] Fri Nov 10 11:02:03 2006
Content-class: urn:content-classes:message
Date: Thu, 9 Nov 2006 20:22:32 -0500
From: "Ken Young" <[email-masked]>
To: <[email-masked]>
cc: Brian Smith <[email-masked]>
Subject: [16ng] Follow up on 16ng WG session

This is a multi-part message in MIME format.

------_=_NextPart_001_01C70466.B240C970
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I had stated that I would follow up on 2 items from Tuesday's session.

First, I mentioned a DHCP relay option to identify port in a relay =
agent.  This is option 82 and this is covered in RFC3046.  This option =
was used by DSLAMs for the same purpose as proposed here.

Second, I wanted to follow up on why Proxy ARP is not required for the =
IPv4 CS.  The link layer elements are described below:

                                                 +-------+
                                                 |       |
       +-----+               +-----+             |       |
       | SS  |---------------| BS  |-------------|  AR   |
       +-----+               +-----+             |       |
                                                 |       |
                                                 +-------+

      +--------+      +-------------------+      +-------+
      |   IP   |      |         IP        |      |  IP   |
      +--------+      +--------+--+-------+      +-------+
      | 802.16 | ---> | 802.16 |  |  GRE  |      |  GRE  |
      +--------+      +--------+  +-------+      +-------+
                                  |  PHY  | ---> |  PHY  |
                                  +-------+      +-------+

Each SS is represented as a single unnumbered p2p link at the AR.  The =
SS has only it IP address and a default route pointing to the AR.  Since =
there is no subnet provisioned against the SS's IP interface, it will =
never ARP since there is no possibility of an SS sharing this link.  All =
communication must be directed through the AR.  As such, the AR has no =
need for Proxy ARP.

Hope this helps,
Ken

------_=_NextPart_001_01C70466.B240C970
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C70466.B240C970--
>From [email-masked] Fri Nov 10 11:56:28 2006
Content-class: urn:content-classes:message
Date: Thu, 9 Nov 2006 18:19:35 -0800
From: "David Johnston" <[email-masked]>
To: "Daniel Park" <[email-masked]>, <[email-masked]>
Subject: [16ng] Review of 16ng problem statement

This is a review of the 16ng problem statement. I probably count as an
802.16 expert.

Section 1. End of paragraph 2.
The base spec is IEEE 802.16-2004, not IEEE 802.16e. 

Section 1. Paragraph 2.

802.16e is not a useful spec to refer to since it is an amendment made
of deltas against a base document. 'IEEE 802.16' without a year (like
IEEE 802.16-2004) implies the current draft with all amendments applied.
So replace instances IEEE 802.16(e) and IEEE802.16e with IEEE 802.16.

Similarly for instances of 802.16(e) in the following paragraphs.

Section 1. Paragraph 3 is incorrect.

802.16 is point to multipoint at the PHY, but point to point and
connection oriented at the MAC. 802.16 Subscriber Stations are perfectly
capable of broadcasting 802 traffic. They sent it out on the network
with a unicast, multicast or broadcast 48 bit 802 MAC address. However
the point to point nature of the 802 network created by the SS-BS
connection means we have a network with only two nodes. A BS with
multiple SSs creates not one but multiple point to point networks that
are independent at the MAC service level. Forwarding of 802.16 packets
from SS to SS or between SSs and backhaul is by means outside the 802.16
spec, E.G. 802.1D bridging or IP routing. This is consistent with
switched Ethernet, that works the same way over wires and switches.

Orthogonal to 802 level MAC address types, 802.16 connections are
unicast, multicast or MBS. Only downlink connections can be MBS or
multicast, however this is invisible to IP. The addressing that IP is
aware of is the either 802 MAC addressing for the Ethernet subpart of
the packet CS or no addressing over point to point links in the case of
the IP specific part of the packet CS.

This lack of forwarding behaviour between SSs is the support for the
assertion in section 1, para 4 that ARP and neighbor discovery are
inappropriate to apply, along with the rest of the paragraph. The
support given in para 3 is incorrect.

Section 4 Overview of the IEEE 802.16-2004 MAC layer

"The topology of the IEEE 802.16-2004 [IEEE802.16] network is point-
   to-multipoint (PMP)"

No, not at the MAC level. It is a group of point to point networks at
the MAC level, physically arranged in a PMP structure with the BS
terminating one end of each connection and an individual SS terminating
the other end of each connection.

"Each node possesses RSA-based authorization mechanism using x.509
certificate attesting to its MAC address/BSId." This behaviour is
optional. It is possible to only support EAP, which may have any
credential that the chosen EAP method requires, although if it is to be
an X.509 cert, 802.16 provides a certificate profile. The 16ng WG MIGHT
want to deprecate the use of RSA based authorization, relying instead
solely on EAP through the PKMv2 protocol in 802.16e that supports EAP
authentication. This is most consistent with an IETF way of doing things
and most likely to be compatible with future work the IETF might do on
key hierarchies and handover keying. Also the IETF might want to
deprecate the use of the cert profile in 802.16 if it clashes with the
cert profile for TLS, EAP-TLS or anything else.

Section 4.2
The correct name for the 6 byte MAC header is the Generic MAC Header.

It should probably be pointed out that since fragmentation and
aggregation is possible in the MAC between the MSDUs at the MAC service
and MPDUs at the PHY service, there is not necessarily a 1:1
relationship between MSDUs and MPDUs. There may be a 1:1, many:1 or
1:many relationship.

Section 4.3
"802.16 define numerous convergence sublayer types" is misleading.
Better to say:

Starting from where it says "802.16 define numerous convergence sublayer
types" Replace to the end of section 4.3 with:

[
802.16 defines two convergence sublayer types, the ATM CS and the Packet
CS. The ATM CS support ATM directly. The Packet CS is subdivided into
three specific subparts

o "The IP Specific Subpart" Carries IP packets over a point to point
connection.

o "The 802.3 Ethernet Specific Subpart" Carries packets encoded in the
802.3/Ethernet packet format with 802.3 style headers.

o "The 802.1Q VLAN Specific Subpart" Carries 802 style packets that
contain 802.1Q VLAN Tags.

Classifiers applied to connections at the time of connection
establishment further classifies and subdivides the nature of the
traffic over a connection. 

The classifications that apply to the IP CS include IPv4 over the IP CS,
IPv6 over the IP CS, IP2 with ROHC header compression over IP CS and IP2
with ECRTP header compression over IP CS".

The classifications that apply to the Ethernet CS include 
packet over the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6
over the 802.3/Ethernet CS, 802.3/Ethernet CS with ROHC Header
Compression and 802.3/Ethernet with ECRTP Header Compression.

The classifications that apply to the 802.1Q/VLAN CS include IPv4 over
802.1Q/VLAN and IPv6 over 802.1Q/VLAN.

It should be noted that while the 802.3/Ethernet CS has a packet
classification that does not restrict the IP version (packet over the
802.3/Ethernet CS) , the IP CS and 802.1Q/VLAN CS do not. All the IP
classifiers for those CSs are either IPv4 or IPv6.

The classifiers enable the MAC to be sure of the presence of fields in
the headers and so to be able to apply the payload header suppression
(PHS) feature of 802.16 to those headers.

For the sake of brevity in this document, the following naming
conventions will be used for particular classifications of particular
subparts of particular CSs.

IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, IPv4).
IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, IPv6).
Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 (Packet,
802.3/Ethernet)

An implementation of 802.16 can support multiple CS types.

We can observe that the CS type, subpart and classification actually
defines the type of data interface (eg.  IPv4/IPv6 or 802.3 ) that is
presented by 802.16 to the higher layer application.

]

Section 5, para 6. Communications among SSes on the same IP Subnet:

It is not 'unclear', it is undefined.

Section 5.1
Replace
" There is no way of how to use ARP facilities on SS."
With
" There is no way to use ARP facilities on an SS unless 802.1D bridging
is used at the BS to forward traffic between different SSs, forming an
802 bridged LAN"

A new section should be added to address the problems of:
"Section 5.2.3 IPv4 and IPv6 interleaved over IP CS."

This is a problem because there is no classifier to cater for this
configuration.

Section 8 Security Considerations
"In [IEEE802.16e] case, PKMv2 EAP-based authentication is recommended
for the secure connection between SS and BS/IP Gateway."

I agree, however this is the problem statement. Should we be making
recommendations? Lets mandate PKMv2+EAP in a solution document.

DJ

-----Original Message-----
From: Daniel Park [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 4:31 PM
To: David Johnston
Cc: gabriel montenegro; ext Soohong Daniel Park
Subject: Reviewer on 16ng problem statement

DJ,

Sorry for asking you again, but I think the 16ng problem statement
should be reviewed by several experts. Even, its WGLC expired, we
didn't have any comments on that. Can you review it ? But please feel
free to let me know your opinion.

The latest version can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-16ng-ps-goals-00.txt

Thanks in advance,

Daniel