Gen-ART review of draft-ietf-v6ops-802-16-deployment-scenarios-06.txt
Brian E Carpenter <brian.e.carpenter <at> gmail.com>
2008-01-07 02:31:25 GMT
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Reviewer: Brian Carpenter
Review Date: 2008-01-07
IETF LC End Date: n/a
IESG Telechat date: 2008-01-10
Summary: Clarifications needed in discussions of mobility, QoS, AAA.
I have a little difficulty reviewing this since I think that the
802.16 model (with several alternative convergence sublayers instead of
simply emulating Ethernet service) is fundamentally misguided. So
I'm pessimistic about the success of WiMax in general. However,
this draft attempts to deal with the way 802.16 has been designed
and is not to blame for the defects in that design.
(I apologise for not making these comments during WG Last Call.)
> 126.96.36.199. Mobility
> As for mobility management, the movement between BSs is handled by
> Mobile IPv6 [RFC3775], if it requires a subnet change.
This is a bit confusing as it is followed by some references
to 802.16 layer 2 roaming. This whole discussion would be easier to
understand if reorganized to clearly separate the layer 2 and layer 3
issues. For example:
> In addition, due to the problems caused by the existence of multiple
> convergence sublayers [RFC4840], the mobile access scenarios need
> solutions about how roaming will work when forced to move from one CS
> to another (e.g., IPv6 CS to Ethernet CS). Note that, at this phase
> this issue is the out of scope of this document. It should be also
> discussed in the 16ng WG.
This is indeed the crucial defect in the 802.16 design - but are we discussing
the layer 2 problem (noticing that it's time to switch to a different
convergence sublayer) or the layer 3 problem (noticing that Mobile IPv6
needs to find a new router and c/o address)?
Under the fixed-access scenario we find:
> 188.8.131.52. Mobility
> No mobility functions are supported in the fixed access scenario.
> However, mobility can be supported in the radio coverage without any
> mobility protocol like WLAN technology. Therefore, a user can access
> Internet nomadically in the coverage.
I can't understand the 2nd and 3rd sentences of this paragraph. Also, I know
of no reason why Mobile IPv6 can't be supported in this scenario if desired.
> 2.4. IPv6 QoS
> In IEEE 802.16 networks, a connection is unidirectional and has a QoS
> specification. The 802.16 supported QoS has different semantics from
> IP QoS (e.g., diffserv). Mapping CID to Service Flow IDentifier
> (SFID) defines QoS parameters of the service flow associated with
> that connection. In order to interwork with IP QoS, IP QoS (e.g.,
> diffserv, or flow label for IPv6) mapping to IEEE 802.16 link
> specifics should be provided.
This doesn't follow. IP-layer mechanisms for QoS are orthogonal to
layer 2 QoS, and are managed by layer 3 entities, which assume best-effort
QoS at layer 2. In any case, as noted in the draft, the semantics
are different at the different layers. So any attempt at mapping is
propably doomed. Also, the flow label has no semantics today...
> 2.5. IPv6 Security
> When initiating the connection, an MS is authenticated by the AAA
This is the first time that a connection mechanism is mentioned
in the draft. It seems to need more description or a reference.
> server located at its service provider network. All the parameters
> related to authentication (username, password and etc.) are forwarded
> by the BS to the AAA server. The AAA server authenticates the MSs
> and when an MS is once authenticated and associated successfully with
> BS, IPv6 an address will be acquired by the MS through stateless
> autoconfiguration or DHCPv6. Note the initiation and authentication
> process is the same as used in IPv4.
Does the AAA exchange run over IP? If so, what IP address is used? If not,
what packetization is used for the AAA exchange?
Gen-art mailing list
Gen-art <at> ietf.org