Document: draft-ietf-netlmm-nohost-ps-04 Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Tuesday 7/4/2006 10:43 AM CST IESG Telechat Date: Thursday, 6 July 2006 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.