Subject: [16ng] Review of 16ng problem statement

From: "David Johnston" <[email-masked]>
Date: Thu, 9 Nov 2006 18:19:35 -0800

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

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

---

From: "David Johnston" <[email-masked]>
Date: Fri, 10 Nov 2006 10:52:27 -0800

Sorry, I unicasted the email.. sending to the list this time.

-----Original Message-----
From: David Johnston 
Sent: Friday, November 10, 2006 10:51 AM
To: 'Mark Thomas'
Subject: RE: [16ng] Review of 16ng problem statement

You are right. It isn't a strict star topology. Multicast transport
connections, MBS transport connections and the downlink broadcast
management connection do not fit into a star topology. So my proposed
text is broken. The star topology is true at the Ethernet CS server
level however. Whatever is in there in the end needs to be unambiguous
about the level (MAC CPS, MAC CS) to which [uni|multi|broad]cast
terminology is being applied.

Trying to use multicast connections to emulate the broadcast nature of
802.3 for Ethernet emulation is fraught with difficulties. 802.11 did
something similar, and in the process, broke support of 802.1D bridges
at the STA. To have the BS place multi/broadcast traffic on multicast
connections but direct unicast MAC addressed packets onto unicast CIDs
means that the BS is routing by MAC address and this is exactly a
forbidden behaviour for 802 media that is known to break 802.1D.

In addition, multicast groups tend to need to be sent at the most robust
MCS as required for the recipient of the most attenuated/interfered with
SS. So there is a complexity in making efficient use of the channel.

This does not mean it cannot be done with care, but a lot of CS
behaviour would need to written to ensure compliance with the 802.1D
ISS, and that is way out of scope for this group and is not current work
for 802.16. I spent some time figuring out how to have the CS use
multicast groups to more efficiently model the Ethernet service, but it
turned out to be complex with a high likelihood of being wrong. Smarter
minds than mine are required :(

In the IP over Ethernet CS proposal, the difficulties were acknowledged
and a star topology using unicast transport connections with filtering
applied to limit flood damage was proposed.

-----Original Message-----
From: Mark Thomas [mailto:[email-masked]] 
Sent: Friday, November 10, 2006 7:36 AM
To: David Johnston
Subject: RE: [16ng] Review of 16ng problem statement

Hi DJ,

You mention below that 802.16 consists of "...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." This describes a star
topology. How do you reconcile this description with the fact that
802.16 connections can easily be unicast or multicast? There is no
fundamental difference between unicast and multicast apart from the
number of participating SSs. In a typical network providing transparent
Ethernet service, we find it convenient to deliver downlink frames with
unknown or broadcast Ethernet destination address using a multicast
connection. This is surely point to multipoint at the Ethernet link
layer and at the 802.16 link layer.

Thanks, Mark

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Johnston
Sent: 10 November 2006 02:20
To: Daniel Park; [email-masked]
Subject: [16ng] Review of 16ng problem statement

Section 1. Paragraph 2.

Section 4.2

Section 4.3

[

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.

]

Section 5.1
Replace

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.

Thanks in advance,

Daniel