|
TO: 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
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.
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 Sometimes there can be alternative IEEE 802.16 network deployments where a BS is integrated with an access
router, 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 Or ?Figure 1
illustrates the key elements of
? 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 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.
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 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.
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 |