Subject: [16ng] Fw: Review on v6ops 802.16 deployment scenario (by DJ Johnston)

From: Daniel Park <[email-masked]>
Date: Mon, 11 Dec 2006 08:14:24 +0900

RE: Review on v6ops 802.16 deployment scenarioTO: v6ops working group

Here is DJ's review.

Two more experts are in the progress of
reviewing this deliverable on behalf of the
16ng working group. It will be available soon.

Hope this helps.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

======================================================

My thoughts...

2.1. Last sentence of first paragraph..

This paragraph reads like 802.16 is some sort of competitor to 802.11 through is wider footprint and improved mobility. In reality they are highly complementary technologies. I suggest to change..

"So it is expected that IEEE 802.16 network could be the next step of IEEE 802.11 network."

To

" So it is expected that IEEE 802.16 network could be the next step ofin IEEE 802.11 wireless networks.

2.1 Second bullet point

The wording below needs clarification.

" 

   o  BS: Base Station.  A generalized equipment set providing

      management and control of MS connections.  There is a

      unidirectional mapping between BS and MS medium access control

      (MAC) peers for the purpose of transporting a service flow's

      traffic.  A connection is identified by a connection identifier

      (CID).  All traffic is carried on the connection.  Sometimes there

      can be alternative IEEE 802.16 network deployment where a BS is

      integrated with an access router, composing one box in view of

      implementation.

"

Change to:

" 

   o  BS: Base Station.  A generalized equipment set providing

      management and control of MS-BS connections.  There is a

      unidirectional A transport connection is a unidirectional mapping 

      between BS and MS medium access control

      (MAC) peers for the purpose of transporting a service flow's

      traffic.  A connection is identified by a connection identifier

      (CID).  All IP data traffic is carried on the transport connections. 

      Sometimes there

      can be alternative IEEE 802.16 network deployments where a BS is

      integrated with an access router, composing comprising a one box in view of

      implementation.

"

2.1, the diagram.

The following diagram describes far more than an 802.16e network that the text claims:

"

Figure 1 illustrates the key elements of IEEE 802.16(e) networks.

          Customer |     Access Provider    | Service Provider

          Premise  |                        | (Backend Network)

       +-----+            +----+     +----+   +--------+

       | MSs |--(802.16)--| BS |-----|    |   | Edge   |   ISP

       +-----+            +----+     | AR |---| Router |==>Network

                                  +--|    |   | (ER)   |

                                  |  +----+   +--------+

       +-----+            +----+  |                |  +------+

       | MSs |--(802.16)--| BS |--+                +--|AAA   |

       +-----+            +----+                      |Server|

                                                      +------+

             Figure 1: Key Elements of IEEE 802.16(e) Networks

"

You might change the text to say:

   "Figure 1 illustrates the key elements of IEEE 802.16(e)WiMax networks."

        Or

   "Figure 1 illustrates the key elements of IEEE 802.16(e) networks typical mobile 802.16 deployments."

"

   1.  Lacking of Facility for IPv6 Native Multicasting

   IEEE 802.16 PMP mode is a connection oriented technology without bi-

   directional native multicast support.

"

Well this is true, but it is also true for modern Ethernet. The difference is that in the Ethernet model (it defines a point to point link), the presence of an 802.1D relay is assumed to be present, but the same assumptions are not being made for 802.16. 802.16 connections joined by an 802.1D relay do support native bidirectional multicast.

So two cases exist..

BS joins connections together with a bridge => bidi mcast ok

BS doesn't => we have a collection of mostly independent tubes.

I suggest 

"

   1.  Lacking of Facility for IPv6 Native Multicasting

   IEEE 802.16 PMP mode is a connection oriented technology without bi-

   directional native multicast support.  IPv6 neighbor discovery

   [RFC2461] supports various functions for the interaction between

   nodes attached on the same subnet, such as on-link determination and

   address resolution.  It is designed with no dependence on a specific

   link layer technology, but requires that the link layer technology

   support native multicast. To support bidirectional native multicast

   and 802.16 BS must deploy additional mechanisms, such as 802.1D

   bridging. The absence of this This lacking of facility for IPv6 native

   multicast results in inappropriateness to apply the standard neighbor

   discover protocol specially regarding, address resolution, router

   discovery, stateless auto-configuration and duplicated address

   detection.

"

"

2.  Impact on IPv6 Subnet Model

   IEEE 802.16 is different from existing wireless access technologies

   such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the

   encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a

   complete description of IPv6 operation is not present.  IEEE 802.16

   can rather benefit from IETF input and specification to support IPv6

   operation.  Especially, BS should look at the classifiers and decide

   where to send the packet, since IEEE 802.16 connection always ends at

   BS, while IPv6 connection terminates at a default router.  This

   operation and limitation may be dependent on the given subnet model

   [I-D.madanapalli-16ng-subnet-model-analysis].

"

A CS looks at classifiers and decides not where to send the packet, but how. I.E. on which CID. That CID would be one of the set of CIDs that links to the same peer CS. The difference is in the QoS properties that apply to each CID, not the denstination.

So the classification in the CS is rather moot. I suggest

2.  Impact on IPv6 Subnet Model

   IEEE 802.16 is different from existing wireless access technologies

   such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the

   encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a

   complete description of IPv6 operation is not present.  IEEE 802.16

   can rather benefit from IETF input and specification to support IPv6

   operation.  Especially, BS should look at the classifiers and decide

   where to send the packet, sSince one end of an IEEE 802.16 connection always ends at

   BS, while an IPv6 connection terminates at a default router.  This

   operation and limitation may be dependent on the given subnet model

   [I-D.madanapalli-16ng-subnet-model-analysis].

2.2.1.3

"

   Note that in this scenario IPv6 CS may be more appropriate than

   Ethernet CS to transport IPv6 packets, since there are some overhead

   of Ethernet CS (e.g., Ethernet header) under mobile access

   environments .

"

For fairly static Ethernet headers (like a link terminating to IP at both ends, PHS eliminates most of the overhead. I suggest.

   Note that in this scenario IPv6 CS may be more appropriate than

   Ethernet CS to transport IPv6 packets, since there are some overhead

   of Ethernet CS (e.g., Ethernet header) under mobile access

   environments . However PHS, if deployed, mitigates much of this overhead.

2.2.2.1

"

   The BRAS in Figure 4 is providing the functionality of the AR.  The

   Ethernet bridge is necessary for protecting the BRAS from 802.16 link

   layer peculiarities.  The Ethernet bridge relays all traffic received

   through BS to its network side port(s) connected to BRAS.  Any

   traffic received from BRAS is relayed to appropriate BS.  Since

   802.16 MAC layer has no native support for multicast (and broadcast)

   in the uplink direction, the Ethernet bridge will emulate Ethernet

   level multicast (and broadcast) by relaying the multicast frame

   received from the MS to all of its ports.  Ethernet bridge may also

   provide some IPv6 specific functions to increase link efficiency of

   the 802.16 radio link (see Section 2.2.2.3).

"

This text assumes that native multicast is a property of Ethernet. I used to be for fat-yellow-coax, but isn't for modern point to point ethenet. The bridge does not emulate Ethernet level multicast. In the 802 architecture, the bridge is the thing that implements multicast, not the medium (although exceptions exist).

I suggest:

"

   The BRAS in Figure 4 is providing the functionality of the AR.  The

   Ethernet bridge is necessary for protecting the BRAS from 802.16 link

   layer peculiarities.  The Ethernet bridge relays all traffic received

   through BS to its network side port(s) connected to BRAS.  Any

   traffic received from BRAS is relayed to appropriate BS.  Since

   802.16 MAC layer has no native support for multicast (and broadcast)

   in the uplink direction, the Ethernet bridge will implement emulate Ethernet

   level multicast (and broadcast) by relaying the multicast frame

   received from the MS to all of its ports.  The Ethernet bridge may also

   provide some IPv6 specific functions to increase link efficiency of

   the 802.16 radio link (see Section 2.2.2.3).

"

"

2.2.2.3.  IPv6 Transport

   Note that in this scenario Ethernet CS may be more appropriate than

   IPv6 CS to transport IPv6 packets, since the scenario need to support

   plain Ethernet connectivity end-to-end.  However, the IPv6 CS can

   also be supported.  Every MS and the BS has the Ethernet type MAC

   address.  If the MS is using IP CS, then the BS needs to take care of

   the Ethernet header.  In the upstream direction, the BS will need to

   generate an appropriate Ethernet header and prepend it to the IP

   datagram.  In the downstream direction, the BS will use the

   destination address from the Ethernet header to identify the MS and

   then it will strip the Ethernet header before relaying the IP

   datagram over the 802.16 MAC connection.  Ethernet bridge may provide

   implementation of authoritative address cache and Relay DAD.

   Authoritative address cache is a mapping between the IPv6 address and

   the MAC addresses of all attached MSs.

"

This description does not seem to fit with the definition of the CSs. When using the IP specific part of the Packet CS, there is no Ethernet header. The MAC address of the equipment at both ends of the connection is known to the BS and MS and need not be communicated.

I may have read this wrongly. If you are talking about the Ethernet specific part of the packet CS in sentence 4 onwards (not the IP CS) , then the text is mostly ok, but unclear about what CS is being referred to. Also the adding and removing of Ethernet headers is the role of the Ethernet CS, not some additional behavior that is yet to be defined.

I suggest

"

2.2.2.3.  IPv6 Transport

   Note that in this scenario Ethernet CS may be more appropriate than

   IPv6 CS to transport IPv6 packets, since the scenario needs to support

   plain Ethernet connectivity end-to-end.  However, the IPv6 CS can

   also be supported. The MS and BS will consider the connections between

   the peer IP CSs at the MS and BS to form a point to point link.

   Every MS and the BS has the Ethernet type MAC

   address.  If the MS is using IP CS, then the BS needs to take care of

   the Ethernet header.  In the upstream direction, the BS will need to

   generate an appropriate Ethernet header and prepend it to the IP

   datagram.  In the downstream direction, the BS will use the

   destination address from the Ethernet header to identify the MS and

   then it will strip the Ethernet header before relaying the IP

   datagram over the 802.16 MAC connection. In the Ethernet CS case, an Ethernet bridge may provide

   implementation of authoritative address cache and Relay DAD.

   Authoritative address cache is a mapping between the IPv6 address and

   the MAC addresses of all attached MSs.

"

That's all.

DJ