I am the assigned Gen-ART reviewer for this draft, currently on an IESG
telechat agenda. For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please wait for direction from your document shepherd or AD before posting
a new version of the draft.
Summary: This document is almost ready for publication as an Informational
RFC, but two problems (larger than nits) need to be fixed. They are tagged
as "Spencer/Problem:", and appear in Sections 1.1 and 3.1. Both should be
fixable using RFC Editor notes, if no further revision of the document is
produced.
Other comments are included for the document editor and RFC editor's
convenience, but aren't part of the Gen-ART review.
Thanks,
Spencer
Abstract
Spencer: "makes a case for network-based local mobility management" just
seems odd in a problem statement Abstract (would have made more sense in
the requirements draft). "and presents a "Problem Statement" based on the
identified shortcomings of previous solutions." maybe? But the
Introduction does a much better job of describing what's being done here.
Localized mobility management is a well understood concept in the
IETF with a number of solutions already available. This document
looks at the principal shortcomings of the existing solutions, all
of which involve the host in mobility management, and makes a case
for network-based local mobility management.
Contributors
Spencer: including this section is quite nice. I wish IESG would encourage
the convention (we sure don't have "one way" of handling more than 5
authors in common practice).
Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and
Marco Liebsch all contributed major effort to this document. Their
names are not included in the authors' section due to the RFC
Editor's limit of 5 names.
1.0 Introduction
Localized mobility management has been the topic of much work in
the IETF. The experimental protocols developed from previous work,
namely FMIPv6 [1] and HMIPv6 [2], involve host-based solutions that
require host involvement at the IP layer similar to or in addition
to that required by Mobile IPv6 [3] for global mobility management.
Spencer: "or in addition to" seems distracting. I think the sentence would
be just as helpful, and more readable, without it.
However, recent developments in the IETF and the WLAN
infrastructure market suggest that it may be time to take a fresh
look at localized mobility management.
1.1 Terminology
Local Mobility (revised)
Local Mobility is mobility over an access network. Note
that, although the area of network topology over which the
mobile node moves may be restricted, the actual geographic
area could be quite large, depending on the mapping between
the network topology and the wireless coverage area.
Spencer/Problem: I wish this definition explicitly said whether there was
any relationship between an access network and an IP subnet - this is
pretty fundamental to understanding the problem being targeted in this
document, and at this point in the document, I'm guessing - so if I guess
wrong, I may be confused for a while. I think I can figure this out based
on the "Intra-Link Mobility" definition further down, but again - I'm
guessing.
2.0 The Local Mobility Problem
The local mobility problem is restricted to providing IP mobility
management for mobile nodes within an access network. The access
network gateways function as aggregation routers. In this case,
there is no specialized routing protocol (e.g. GTP, Cellular IP,
Hawaii, etc.) and the routers form a standard IP routed network
(e.g. OSPF, IS-IS, RIP, etc.). This is illustrated in Figure 1,
where the access network gateway routers are designated as "ANG".
Transitions between service providers in separate autonomous
systems or across broader topological "boundaries" within the same
service provider are excluded.
Spencer: again, I'm not yet sure of the relationship between subnets and
access networks, so struggling with "topological" in this sentence.
3.1 Large Campus
One scenario where localized mobility management would be
attractive is a large campus wireless LAN deployment. Having a
single broadcast domain for all WLAN access points doesn't scale
very well. Also, sometimes parts of the campus cannot be covered
by one VLAN for other reasons (e.g., some links are other than
802.3).
Spencer/Problem: extremely confused here. (1) is it 802.3, or 802.1 (where
VLANs live)? (2) is it 802.3, or 802.11/16/other wireless? (3) Are you
telling me something about VLAN support across 802 MAC variations, or
something else? I'm just too scrambled to suggest text, but something
needs help here.
3.2 Advanced Cellular Network
Next generation cellular protocols such as 802.16e [8] and Super
3G/3.9G [9] have the potential to run IP deeper into the access
network than the current 3G cellular protocols, similar to today's
WLAN networks. This means that the access network can become a
routed IP network. Interoperable localized mobility management can
unify local mobility across a diverse set of wireless protocols all
served by IP, including advanced cellular, WLAN, and personal area
wireless technologies such as UltraWide Band (UWB) [10] and
Bluetooth [11]. Localized mobility management at the IP layer does
not replace Layer 2 mobility (where available) but rather
complements it. A standardized, interoperable localized mobility
Spencer: the "Localized mobility management" sentence just previously is
VERY helpful, and should appear much sooner in the document.
management protocol for IP can remove the dependence on IP layer
localized mobility protocols that are specialized to specific link
technologies or proprietary, which is the situation with today's 3G
protocols. The expected benefit is a reduction in maintenance cost
and deployment complexity. See [6] for a more detailed discussion
of the goals for a network-based localized mobility management
protocol.
4.0 Problems with Existing Solutions
Existing solutions for localized mobility management fall into
three classes:
Spencer: but only two are listed - which way is the counting mistake?
The dedicated localized mobility management IETF protocols for
Solution 1 are not yet widely deployed, but work continues on
standardization. Some Mobile IPv4 deployments use localized
mobility management. For Solution 1, the following are specific
problems:
Spencer: It's not obvious that this section has subsections, but it does
(one for Solution 1, another for Solution 2). Suggest adding headings like
"4.1 Problems with Host-based Localized Mobility Management", '4.2
Problems with Link-specific Localized Mobility Management", and "4.3
Rationale for an Interoperable, Standardized Localized Mobility Management
Protocol" for ease of scanning. But it does not help that both Solution 1
and Solution 2 are "buried" in the leadoff paragraphs (in this case, not
mentioned until the third sentence).
1) Interoperable IP level protocols that require changes to the
mobile node's IP stack and handle localized mobility management
as a service provided to the mobile node by the access network,
2) Link specific or proprietary protocols that handle localized
mobility for any mobile node but only for a specific type of
link layer, namely 802.11 running on an 802.3 wired network
backhaul.
The dedicated localized mobility management IETF protocols for
Solution 1 are not yet widely deployed, but work continues on
standardization. Some Mobile IPv4 deployments use localized
Spencer: a reference for "work continues on standardization" would be
helpful here.
mobility management. For Solution 1, the following are specific
problems:
1) The host stack software requirement limits broad usage even if
the modifications are small. The success of WLAN switches
indicates that network operators and users prefer no host stack
Spencer: "users prefer" seems way overstated. "deploy solutions that do
not require host stack software modifications more quickly and easily"?
software modifications. This preference is independent of the
lack of widespread Mobile IPv4 deployment, since it is much
easier to deploy and use the network.
2) Future mobile nodes may choose other global mobility management
protocols, such as HIP or MOBIKE. The existing localized
mobility management solutions all depend on Mobile IP or
derivatives.
3) Existing localized mobility management solutions do not support
both IPv4 and IPv6.
4) Existing host-based localized mobility management solutions
require setting up additional security associations with network
elements in the access domain.
6.0 Security Considerations
Localized mobility management has certain security considerations,
one of which - need for access network to mobile node security -
was touched on in this document. Host-based localized mobility
management protocols have all the security problems involved with
providing a service to a host. Network-based localized mobility
management requires security among network elements equivalent to
what is needed for routing information security, and security
between the host and network equivalent to what is needed for
network access, but no more. A more complete discussion of the
security goals for network-based localized mobility management can
be found in [6].
Spencer: Hmm. The corresponding section in [6] is just a little longer
than this one, so I'm not sure I see the point of having two security
considerations sections that are both so short, with one pointing to the
other, but not saying the same things, in two documents that are going
through approval at roughly the same time. My suggestion is to pick one
document, put all the text in it, and have the other point to it without
editorializing.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
