[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&T Labs)
To v6ops working group,
Here is a J Kim's review on the 802.16 deployment
scenario.
As promised, the 16ng working group has made
several reviews on the 802.16 deployment scenario
with pleasure. Hope this helps and specially thanks
to all reviewers, DJ Johnston, Basavaraj Patil and
Byoung-Jo Kim.
That's it.
Chairs, 16ng working group
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
=========================================================
Hi, Daniel.
Here is my review..
Bests.
Byoung-Jo "J" Kim
macsbug@research.att.com
AT&T Labs - Research
http://macsbug.googlepages.com/
===================[BEGIN]======================
* Overall: The purpose and the content of this ID are mismatched and the
coverage is very restricted to a small set. I don't see significant
value in publishing this ID and fear unnecessary confusions if so. If it
needs to be published, the title and the scope should be limited to the
suitable subset of deployment models, instead of implying comprehensive
coverage. Also, too many irrelevant statements and unsubstantiated
claims are there, some of which I tried to point out.
* Section 1: Largely unnecessary content for ID. Does not state its
scope and intent clearly.
* Section 2.1:
- The content before the definitions of MS are irrelevant.
- Per 802.16e-2005, MS is always SS, thus often referred to as
SS/MS.
- In the BS definition: The following is getting ahead of the
flow. "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."
* Section 2.2:
- Synchronize issues list with the 16ng problem statement
- Bullet 3: The following is not the function of CS: "5)
Forwarding the PDUs to the
corresponding AR."
* Section 2.2.1:
- Lose the following. Irrelevant for this ID if not true: "This
use case will be implemented only with the licensed spectrum. "
- What's the point of this section in an IEFT ID if "All
original IPv6 functionalities [RFC2461], [RFC2462] will not survive."?
Why discuss IPv6 operation at all then?
* Section 2.2.1.1:
- What's the purpose of this paragraph and why does it matter in
this ID?
- If "IEEE 802.16 BSs have only MAC and PHY layers without
router function and
operates as a bridge.", then why "upgrading the following devices to
dual-stack: MS, BS, AR and ER"? as BS is unaware of the IP layer?
* Section 2.2.1.2
- Bullet 2: what's the point of this describing this particular
DHCP arrangement. For all MS cares, a DHCP exists on the local subnet.
Using relay/proxy is deployment decision.
* Section 2.2.1.3
- The following statement is unsubstantiated:
" when supported consumes air bandwidth
as well as it would have adverse effect on MSs that were
in the
dormant mode."
This is for allegedly broadband systems and the actual BW
consumption for ND has never been quantified to justify the above. If
the consumption is not too bad, it may be worth the overhead to keep the
layering and protocols clean. Also, it is not clear that ND cannot be
delivered as part of housekeeping MAC messages while in dormant mode.
Also, as an implementation, all that can be combined with BS
conservatively filtering based on its local knowledge, which often
extends into IP layers of its SS/MS's. Some examples of this in 802.11
land.
- The following is stated without justification as PHS makes
this point moot, while the presence of Ethernet headers can be useful in
shared prefix subnets, multiple hosts behind SS/MS, compatibility with
metro-Ethernet backhaul, and so on, regardless of mobility levels.
"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 ."
- Everything from the "Simple or complex network equipments may
constitute.." till the end of section is irrelevant for this ID and can
be found in other ID and RFCs in far more details. Remove or just refer.
* Section 2.2.1.4: Irrelevant to this ID. Normal stuff and other ways
exist.
* Section 2.2.2:
- In the first sentence, which "end-to-end"?
- The following is out of place, and why can't these usages be
mobile as well? There is no car/bike/bus in campuses?
"Many wireless Internet service providers (Wireless
ISPs) have planned
to use IEEE 802.16 for the purpose of high quality
broadband wireless
service. A company can use IEEE 802.16 to build up
mobile office.
Wireless Internet spreading through a campus or a cafe
can be also
implemented with it."
- This distinction of license and unlicensed spectrum for fixed
model is not correct nor relevant.
"The distinct point of this use case is that it can use
unlicensed
(2.4 & 5 GHz) band as well as licensed (2.6 & 3.5GHz)
band."
* Section 2.2.2.1:
- See comments for section 2.2.1.1.
- I don't think this is standard bridge behavior or is this
describing something special?
"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."
How does the bridge know which one is "appropriate BS"?
* Section 2.2.2.3:
- In the first sentence, which "end-to-end"?
- How? Another tunneling? Is it relevant then? "the IPv6 CS can
also be supported." Just because you can does not mean it is a good
idea.
- Any reference or description of "Relay DAD"? there are earlier
occurrences
* Section 2.2.2.4: Remove. Irrelevant
* Section 2.2.2.5: Remove. MIP should be usable on any normal IP
networks as long as the user/MS has an HA to talk to and it is
reachable.
* Section 2.3: Remove. Does not add any content and all speculative (the
ID admits that!)
* Section 2.5:
- "an MS is authenticated by the AAA server located at its
service provider network." should read " an MS is authenticated by a AAA
server.", kinda Duh? The location of AAA is irrelevant, as this ID lacks
discussions of access network sharing, wholesale, roaming, etc..
- ?? "The AAA server authenticates the MSs and once
authenticated."
- Remove. Irrelevant. "IPsec is a fundamental part of IPv6.
Unlike IPv4, IPsec for
IPv6 may be used within the global end-to-end
architecture. But, we don't
have PKIs across organizations and IPsec isn't
integrated with IEEE
802.16 network mobility management."
* Section 2.6
- Lose the first sentence. Irrelevant
- The second paragraph may be wrong, and at least irrelevant.
- The last paragraph is irrelevant.
===================[END]======================