Network Working Group                                      J. Kempf, Ed.
Request for Comments: 4830                               DoCoMo USA Labs
Category: Informational                                       April 2007
        
Network Working Group                                      J. Kempf, Ed.
Request for Comments: 4830                               DoCoMo USA Labs
Category: Informational                                       April 2007
        

Problem Statement for Network-Based Localized Mobility Management (NETLMM)

基于网络的本地化移动性管理(NETLMM)问题陈述

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

Abstract

摘要

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.

在IETF中,本地化移动性管理是一个众所周知的概念,已有许多解决方案可用。本文档介绍了现有解决方案的主要缺点,所有这些解决方案都涉及主机的移动性管理,并为基于网络的本地移动性管理提供了一个案例。

Table of Contents

目录

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. The Local Mobility Problem ......................................4
   3. Scenarios for Localized Mobility Management .....................7
      3.1. Large Campus ...............................................7
      3.2. Advanced Cellular Network ..................................7
      3.3. Picocellular Network with Small But Node-Dense Last
           Hop Links ..................................................8
   4. Problems with Existing Solutions ................................8
   5. Advantages of Network-based Localized Mobility Management .......9
   6. Security Considerations ........................................10
   7. Informative References .........................................10
   8. Acknowledgements ...............................................11
   9. Contributors ...................................................12
        
   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. The Local Mobility Problem ......................................4
   3. Scenarios for Localized Mobility Management .....................7
      3.1. Large Campus ...............................................7
      3.2. Advanced Cellular Network ..................................7
      3.3. Picocellular Network with Small But Node-Dense Last
           Hop Links ..................................................8
   4. Problems with Existing Solutions ................................8
   5. Advantages of Network-based Localized Mobility Management .......9
   6. Security Considerations ........................................10
   7. Informative References .........................................10
   8. Acknowledgements ...............................................11
   9. Contributors ...................................................12
        
1. Introduction
1. 介绍

Localized mobility management has been the topic of much work in the IETF. The experimental protocols developed from previous works, namely Fast-Handovers for Mobile IPv6 (FMIPv6) [13] and Hierarchical Mobile IPv6 (HMIPv6) [18], involve host-based solutions that require host involvement at the IP layer similar to, or in addition to, that required by Mobile IPv6 [10] for global mobility management. However, recent developments in the IETF and the Wireless LAN (WLAN) infrastructure market suggest that it may be time to take a fresh look at localized mobility management.

在IETF中,本地化移动性管理一直是许多工作的主题。从以前的工作中开发的实验协议,即移动IPv6快速切换(FMIPv6)[13]和分层移动IPv6(HMIPv6)[18],涉及基于主机的解决方案,这些解决方案需要主机参与IP层,类似于或补充移动IPv6[10]对全球移动性管理的要求。然而,IETF和无线局域网(WLAN)基础设施市场的最新发展表明,是时候重新审视本地化移动性管理了。

First, new IETF work on global mobility management protocols that are not Mobile IPv6, such as Host Identity Protocol (HIP) [16] and IKEv2 Mobility and Multihoming (MOBIKE) [4], suggests that future wireless IP nodes may support a more diverse set of global mobility protocols. While it is possible that existing localized mobility management protocols could be used with HIP and MOBIKE, some would require additional effort to implement, deploy, or in some cases, even specify in a non-Mobile IPv6 mobile environment.

首先,IETF在非移动IPv6的全球移动性管理协议方面的新工作,如主机标识协议(HIP)[16]和IKEv2移动性和多归属(MOBIKE)[4],表明未来的无线IP节点可能支持更多样化的全球移动性协议集。虽然现有的本地化移动性管理协议可以与HIP和MOBIKE一起使用,但有些协议需要额外的努力来实现、部署,或者在某些情况下,甚至在非移动IPv6移动环境中指定。

Second, the success in the WLAN infrastructure market of WLAN switches, which perform localized management without any host stack involvement, suggests a possible paradigm that could be used to accommodate other global mobility options on the mobile node while reducing host stack software complexity, expanding the range of mobile nodes that could be accommodated.

第二,WLAN交换机在WLAN基础设施市场上的成功(在不涉及任何主机堆栈的情况下执行本地化管理)表明了一种可能的范例,可用于在移动节点上适应其他全球移动选项,同时降低主机堆栈软件的复杂性,扩大可容纳的移动节点范围。

This document briefly describes the general local mobility problem and scenarios where localized mobility management would be desirable. Then problems with existing or proposed IETF localized mobility management protocols are briefly discussed. The network-based mobility management architecture and a short description of how it solves these problems are presented. A more detailed discussion of goals for a network-based, localized mobility management protocol and gap analysis for existing protocols can be found in [11]. Note that IPv6 and wireless links are considered to be the initial scope for a network-based localized mobility management, so the language in this document reflects that scope. However, the conclusions of this document apply equally to IPv4 and wired links, where nodes are disconnecting and reconnecting.

本文档简要描述了一般的本地移动性问题以及需要本地化移动性管理的场景。然后简要讨论了现有的或提出的IETF本地化移动性管理协议的问题。提出了基于网络的移动性管理体系结构,并简要描述了它是如何解决这些问题的。有关基于网络的本地化移动性管理协议的目标以及现有协议的差距分析的更详细讨论,请参见[11]。请注意,IPv6和无线链路被认为是基于网络的本地化移动性管理的初始范围,因此本文档中的语言反映了该范围。但是,本文档的结论同样适用于IPv4和有线链路,其中节点正在断开和重新连接。

1.1. Terminology
1.1. 术语

Mobility terminology in this document follows that in RFC 3753 [14], with the addition of some new and revised terminology given here:

本文件中的移动性术语遵循RFC 3753[14]中的术语,并添加了一些新的和修订的术语:

WLAN Switch

无线局域网交换机

A WLAN switch is a multiport bridge Ethernet [8] switch that connects network segments but also allows a physical and logical star topology, which runs a protocol to control a collection of 802.11 [6] access points. The access point control protocol allows the switch to perform radio resource management functions such as power control and terminal load balancing between the access points. Most WLAN switches also support a proprietary protocol for inter-subnet IP mobility, usually involving some kind of inter-switch IP tunnel, which provides session continuity when a terminal moves between subnets.

WLAN交换机是一种多端口桥接以太网[8]交换机,它连接网段,但也允许物理和逻辑星形拓扑,该拓扑运行协议以控制802.11[6]接入点的集合。接入点控制协议允许交换机执行无线资源管理功能,例如接入点之间的功率控制和终端负载平衡。大多数WLAN交换机还支持子网间IP移动的专有协议,通常涉及某种类型的交换机间IP隧道,当终端在子网之间移动时,该隧道提供会话连续性。

Access Network

接入网

An access network is a collection of fixed and mobile network components allowing access to the Internet all belonging to a single operational domain. It may consist of multiple air interface technologies (for example, 802.16e [7], Universal Mobile Telecommunications System (UMTS) [1], etc.) interconnected with multiple types of backhaul interconnections (such as Synchronous Optical Network (SONET) [9], metro Ethernet [15] [8], etc.).

接入网络是固定和移动网络组件的集合,允许访问所有属于单个操作域的互联网。它可以由多个空中接口技术(例如,802.16e[7]、通用移动通信系统(UMTS)[1]等)组成,这些技术与多种类型的回程互连(例如同步光网络(SONET)[9]、城域以太网[15][8]等)互连。

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.

本地移动性是指通过接入网络的移动性。注意,尽管移动节点移动的网络拓扑区域可能受到限制,但实际地理区域可能相当大,这取决于网络拓扑和无线覆盖区域之间的映射。

Localized Mobility Management

本地化移动性管理

Localized Mobility Management is a generic term for any protocol that maintains the IP connectivity and reachability of a mobile node for purposes of maintaining session continuity when the mobile node moves, and whose signaling is confined to an access network.

本地化移动性管理是任何协议的通用术语,该协议维护移动节点的IP连接性和可达性,以便在移动节点移动时保持会话连续性,并且其信令仅限于接入网络。

Localized Mobility Management Protocol

本地化移动性管理协议

A protocol that supports localized mobility management.

支持本地化移动性管理的协议。

Global Mobility Management Protocol

全局移动性管理协议

A Global Mobility Management Protocol is a mobility protocol used by the mobile node to change the global, end-to-end routing of packets for purposes of maintaining session continuity when movement causes a topology change, thus invalidating a global unicast address of the mobile node. This protocol could be Mobile IP [10] [17], but it could also be HIP [16] or MOBIKE [4].

全局移动性管理协议是移动节点使用的移动性协议,用于在移动导致拓扑改变时改变分组的全局、端到端路由以维持会话连续性,从而使移动节点的全局单播地址无效。该协议可以是移动IP[10][17],但也可以是HIP[16]或MOBIKE[4]。

Global Mobility Anchor Point

全球移动定位点

A node in the network where the mobile node maintains a permanent address and a mapping between the permanent address and the local temporary address where the mobile node happens to be currently located. The Global Mobility Anchor Point may be used for purposes of rendezvous and possibly traffic forwarding.

网络中的一种节点,其中移动节点维护一个永久地址以及该永久地址与移动节点当前恰好所在的本地临时地址之间的映射。全球移动锚点可用于会合和可能的业务转发。

Intra-Link Mobility

链路内移动性

Intra-Link Mobility is mobility between wireless access points within a link. Typically, this kind of mobility only involves Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2 mobility. No IP subnet configuration is required upon movement since the link does not change, but some IP signaling may be required for the mobile node to confirm whether or not the change of wireless access point also resulted in the previous access routers becoming unreachable. If the link is served by a single access point/router combination, then this type of mobility is typically absent. See Figure 1.

链路内移动性是指链路内无线接入点之间的移动性。通常,这种移动性只涉及第2层机制,因此链路内移动性通常被称为第2层移动性。移动时不需要IP子网配置,因为链路没有改变,但是移动节点可能需要一些IP信令来确认无线接入点的改变是否也导致先前的接入路由器变得不可访问。如果链路由单个接入点/路由器组合提供服务,则通常不存在这种类型的移动性。参见图1。

2. The Local Mobility Problem
2. 局部流动问题

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., Generic Tunneling Protocol (GTP), Cellular IP, Hawaii, etc.) and the routers form a standard IP routed network (e.g., OSPF, Intermediate System to Intermediate System (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.

本地移动性问题被限制为为接入网络内的移动节点提供IP移动性管理。接入网网关充当聚合路由器。在这种情况下,没有专门的路由协议(例如,通用隧道协议(GTP)、蜂窝IP、夏威夷等),路由器形成标准IP路由网络(例如,OSPF、中间系统到中间系统(is-is)、RIP等)。这如图1所示,其中接入网网关路由器被指定为“ANG”。不包括独立自治系统中的服务提供商之间的转换,或同一服务提供商内更广泛的拓扑“边界”之间的转换。

Figure 1 depicts the scope of local mobility in comparison to global mobility. The Access Network Gateways (ANGs), GA1 and GB1, are gateways to their access networks. The Access Routers (ARs), RA1 and RA2, are in access network A; RB1 is in access network B. Note that

图1描述了本地流动与全球流动的对比范围。接入网网关(ANG)GA1和GB1是其接入网的网关。接入路由器(ar)RA1和RA2位于接入网络A中;RB1位于接入网络B中。请注意

it is possible to have additional aggregation routers between ANG GA1 and ANG GB1, and the access routers if the access network is large. Access Points (APs) PA1 through PA3 are in access network A; PB1 and PB2 are in access network B. Other ANGs, ARs, and APs are also possible, and other routers can separate the ARs from the ANGs. The figure implies a star topology for the access network deployment, and the star topology is the primary interest since it is quite common, but the problems discussed here are equally relevant to ring or mesh topologies in which ARs are directly connected through some part of the network.

在ANG GA1和ANG GB1之间可以有额外的聚合路由器,如果接入网络较大,则可以有接入路由器。接入点(ap)PA1到PA3位于接入网络A中;PB1和PB2位于接入网络B中。也可以使用其他ANG、ARs和AP,其他路由器可以将ARs与ANG分开。该图暗示了接入网络部署的星型拓扑,星型拓扑是主要关注点,因为它非常常见,但这里讨论的问题同样与环形或网状拓扑相关,其中AR通过网络的某个部分直接连接。

Access Network A Access Network B

接入网A接入网B

                  +-------+                  +-------+
                  |ANG GA1| (other ANGs)     |ANG GB1| (other ANGs)
                  +-------+                  +-------+
                   @    @                       @
                  @      @                      @
                 @        @                     @   (other routers)
                @          @                    @
               @            @                   @
              @              @                  @
           +------+       +------+            +------+
           |AR RA1|       |AR RA2|(other ARs) |AR RB1|  (other ARs)
           +------+       +------+            +------+
              *             *                    *
             * *            *                   * *
            *   *           *                  *   *
           *     *          *                 *     *
          *       *         *                *       *
         *         *        * (other APs)   *         * (other APs)
        /\         /\       /\             /\         /\
       /AP\       /AP\     /AP\           /AP\       /AP\
      /PA1 \     /PA2 \   /PA3 \         /PB1 \     /PB2 \
      ------     ------   ------         ------     ------
        
                  +-------+                  +-------+
                  |ANG GA1| (other ANGs)     |ANG GB1| (other ANGs)
                  +-------+                  +-------+
                   @    @                       @
                  @      @                      @
                 @        @                     @   (other routers)
                @          @                    @
               @            @                   @
              @              @                  @
           +------+       +------+            +------+
           |AR RA1|       |AR RA2|(other ARs) |AR RB1|  (other ARs)
           +------+       +------+            +------+
              *             *                    *
             * *            *                   * *
            *   *           *                  *   *
           *     *          *                 *     *
          *       *         *                *       *
         *         *        * (other APs)   *         * (other APs)
        /\         /\       /\             /\         /\
       /AP\       /AP\     /AP\           /AP\       /AP\
      /PA1 \     /PA2 \   /PA3 \         /PB1 \     /PB2 \
      ------     ------   ------         ------     ------
        
         +--+      +--+      +--+         +--+
         |MN|----->|MN|----->|MN|-------->|MN|
         +--+      +--+      +--+         +--+
       Intra-link      Local        Global
       (Layer 2)      Mobility     Mobility
        Mobility
        
         +--+      +--+      +--+         +--+
         |MN|----->|MN|----->|MN|-------->|MN|
         +--+      +--+      +--+         +--+
       Intra-link      Local        Global
       (Layer 2)      Mobility     Mobility
        Mobility
        

Figure 1. Scope of Local and Global Mobility Management

图1。本地和全球流动管理的范围

As shown in the figure, a global mobility protocol may be necessary when a mobile node (MN) moves between two access networks. Exactly what the scope of the access networks is depends on deployment considerations. Mobility between two APs under the same AR constitutes intra-link (or Layer 2) mobility, and is typically handled by Layer 2 mobility protocols (if there is only one AP/cell per AR, then intra-link mobility may be lacking). Between these two lies local mobility. Local mobility occurs when a mobile node moves between two APs connected to two different ARs.

如图所示,当移动节点(MN)在两个接入网络之间移动时,可能需要全局移动协议。接入网络的确切范围取决于部署考虑。同一AR下的两个AP之间的移动性构成链路内(或第2层)移动性,并且通常由第2层移动性协议处理(如果每个AR只有一个AP/小区,则可能缺少链路内移动性)。在这两者之间存在着当地的流动性。当移动节点在连接到两个不同AR的两个AP之间移动时,就会发生本地移动性。

Global mobility protocols allow a mobile node to maintain reachability when the MN's globally routable IP address changes. It does this by updating the address mapping between the permanent address and temporary local address at the global mobility anchor point, or even end to end by changing the temporary local address directly at the node with which the mobile node is corresponding. A global mobility management protocol can therefore be used between ARs for handling local mobility. However, there are three well-known problems involved in using a global mobility protocol for every movement between ARs. Briefly, they are:

全局移动协议允许移动节点在MN的全局可路由IP地址发生变化时保持可达性。它通过更新全局移动锚定点处的永久地址和临时本地地址之间的地址映射来实现这一点,或者甚至通过直接在移动节点所对应的节点处更改临时本地地址来实现端到端。因此,可以在AR之间使用全局移动性管理协议来处理本地移动性。然而,对于ARs之间的每次移动,使用全局移动协议涉及三个众所周知的问题。简而言之,它们是:

1) Update latency. If the global mobility anchor point and/or correspondent node (for route-optimized traffic) is at some distance from the mobile node's access network, the global mobility update may require a considerable amount of time. During this time, packets continue to be routed to the old temporary local address and are essentially dropped.

1) 更新延迟。如果全局移动性锚点和/或对应节点(用于路由优化业务)与移动节点的接入网络处于一定距离,则全局移动性更新可能需要相当长的时间。在此期间,数据包继续被路由到旧的临时本地地址,并且基本上被丢弃。

2) Signaling overhead. The amount of signaling required when a mobile node moves from one last-hop link to another can be quite extensive, including all the signaling required to configure an IP address on the new link and global mobility protocol signaling back into the network for changing the permanent to temporary local address mapping. The signaling volume may negatively impact wireless bandwidth usage and real-time service performance.

2) 信令开销。当移动节点从一个最后一跳链路移动到另一个链路时所需的信令量可以是相当大的,包括在新链路上配置IP地址所需的所有信令以及返回网络以改变永久到临时本地地址映射的全局移动性协议信令。信令量可能会对无线带宽使用和实时服务性能产生负面影响。

3) Location privacy. The change in temporary local address as the mobile node moves exposes the mobile node's topological location to correspondents and potentially to eavesdroppers. An attacker that can assemble a mapping between subnet prefixes in the mobile node's access network and geographical locations can determine exactly where the mobile node is located. This can expose the mobile node's user to threats on their location privacy. A more detailed discussion of location privacy for Mobile IPv6 can be found in [12].

3) 位置隐私。移动节点移动时临时本地地址的变化将移动节点的拓扑位置暴露给通信者,并可能暴露给窃听者。能够在移动节点接入网络中的子网前缀和地理位置之间组装映射的攻击者可以准确确定移动节点的位置。这会使移动节点的用户暴露在其位置隐私的威胁之下。有关移动IPv6位置隐私的更详细讨论,请参见[12]。

These problems suggest that a protocol to localize the management of topologically small movements is preferable to using a global mobility management protocol on each movement to a new link. In addition to these problems, localized mobility management can provide a measure of local control, so mobility management can be tuned for specialized local conditions. Note also that if localized mobility management is provided, it is not strictly required for a mobile node to support a global mobility management protocol since movement within a restricted IP access network can still be accommodated. Without such support, however, a mobile node experiences a disruption in its traffic when it moves beyond the border of the localized mobility management domain.

这些问题表明,与在新链路的每个移动上使用全局移动性管理协议相比,将拓扑上的小移动的管理本地化的协议更可取。除了这些问题之外,本地化移动性管理还可以提供本地控制措施,因此移动性管理可以针对特定的本地条件进行调整。还注意,如果提供了本地化移动性管理,则移动节点不严格要求支持全局移动性管理协议,因为仍然可以适应受限IP接入网络内的移动。然而,如果没有这样的支持,当移动节点移动到本地化移动性管理域的边界之外时,其通信量会受到干扰。

3. Scenarios for Localized Mobility Management
3. 本地化移动性管理的场景

There are a variety of scenarios in which localized mobility management is useful.

在各种场景中,本地化移动性管理非常有用。

3.1. Large Campus
3.1. 大校园

One scenario where localized mobility management would be attractive is a campus WLAN deployment, in which the geographical span of the campus, distribution of buildings, availability of wiring in buildings, etc. preclude deploying all WLAN access points as part of the same IP subnet. WLAN Layer 2 mobility could not be used across the entire campus.

本地化移动性管理具有吸引力的一个场景是校园WLAN部署,其中校园的地理范围、建筑物的分布、建筑物内布线的可用性等都阻止将所有WLAN接入点部署为同一IP子网的一部分。WLAN第2层移动无法在整个校园内使用。

In this case, the campus is divided into separate last-hop links, each served by one or more access routers. This kind of deployment is served today by WLAN switches that coordinate IP mobility between them, effectively providing localized mobility management at the link layer. Since the protocols are proprietary and not interoperable, any deployments that require IP mobility necessarily require switches from the same vendor.

在这种情况下,校园被划分为单独的最后一跳链路,每个链路由一个或多个接入路由器提供服务。如今,这种部署由协调它们之间IP移动性的WLAN交换机提供,有效地在链路层提供本地化移动性管理。由于这些协议是专有的且不可互操作,因此任何需要IP移动性的部署都必然需要来自同一供应商的交换机。

3.2. Advanced Cellular Network
3.2. 高级蜂窝网络

Next-generation cellular protocols, such as 802.16e [7] and Super 3G/3.9G [2], 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) [5] and Bluetooth [3]. Localized mobility management at the IP layer does not replace Layer 2 mobility (where available) but rather complements it. A standardized, interoperable localized mobility management protocol

下一代蜂窝协议,如802.16e[7]和Super 3G/3.9G[2],与当前的3G蜂窝协议相比,具有将IP深入接入网络的潜力,类似于今天的WLAN网络。这意味着接入网络可以成为路由IP网络。可互操作的本地化移动性管理可以跨一组由IP提供服务的无线协议统一本地移动性,包括先进的蜂窝、WLAN和个人区域无线技术,如超宽带(UWB)[5]和蓝牙[3]。IP层的本地化移动性管理不会取代第2层移动性(如果可用),而是对其进行补充。一种标准化、可互操作的本地化移动性管理协议

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 [11] for a more detailed discussion of the goals for a network-based localized mobility management protocol.

因为IP可以消除对IP层本地化移动协议的依赖,这些协议专门用于特定的链路技术或专有技术,这是当今3G协议的情况。预期的好处是降低维护成本和部署复杂性。有关基于网络的本地化移动性管理协议目标的更详细讨论,请参见[11]。

3.3. Picocellular Network with Small But Node-Dense Last-Hop Links
3.3. 具有小型但节点密集的最后一跳链路的微微蜂窝网络

Future radio link protocols at very high frequencies may be constrained to very short, line-of-sight operation. Even some existing protocols, such as UWB [5] and Bluetooth [3], are designed for low transmit power, short-range operation. For such protocols, extremely small picocells become more practical. Although picocells do not necessarily imply "pico subnets", wireless sensors and other advanced applications may end up making such picocellular type networks node-dense, requiring subnets that cover small geographical areas, such as a single room. The ability to aggregate many subnets under a localized mobility management scheme can help reduce the amount of IP signaling required on link movement.

未来甚高频无线链路协议可能会被限制在极短的视线范围内。甚至一些现有的协议,如UWB[5]和蓝牙[3],也是为低发射功率、短距离操作而设计的。对于这样的协议,非常小的微微蜂窝变得更加实用。尽管微微蜂窝并不一定意味着“微微子网”,但无线传感器和其他高级应用程序最终可能会使这种微微蜂窝型网络节点密集,需要覆盖小地理区域(如单个房间)的子网。在本地化移动性管理方案下聚合多个子网的能力有助于减少链路移动所需的IP信令量。

4. Problems with Existing Solutions
4. 现有解决方案的问题

Existing solutions for localized mobility management fall into two classes:

本地化移动性管理的现有解决方案分为两类:

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.

1) 可互操作的IP级协议,需要更改移动节点的IP堆栈,并将本地化移动性管理作为接入网络提供给移动节点的服务来处理。

2) Link specific or proprietary protocols that handle localized mobility for any mobile node but only for a specific type of link layer, for example, 802.11 [6].

2) 链路特定或专有协议,用于处理任何移动节点的本地化移动性,但仅用于特定类型的链路层,例如802.11[6]。

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:

解决方案1的专用本地化移动性管理IETF协议尚未广泛部署,但标准化工作仍在继续。某些移动IPv4部署使用本地化移动管理。对于解决方案1,以下是具体问题:

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 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.

1) 主机堆栈软件需求限制了广泛使用,即使修改很小。WLAN交换机的成功表明,网络运营商和用户不希望修改主机堆栈软件。这种偏好与缺乏广泛的移动IPv4部署无关,因为部署和使用网络要容易得多。

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.

2) 未来的移动节点可以选择其他全局移动管理协议,例如HIP或MOBIKE。现有的本地化移动性管理解决方案都依赖于移动IP或其衍生产品。

3) Existing localized mobility management solutions do not support both IPv4 and IPv6.

3) 现有的本地化移动管理解决方案不同时支持IPv4和IPv6。

4) Existing host-based localized mobility management solutions require setting up additional security associations with network elements in the access domain.

4) 现有的基于主机的本地化移动性管理解决方案需要与接入域中的网络元素建立额外的安全关联。

Market acceptance of WLAN switches has been very large, so Solution 2 is widely deployed and continuing to grow. Solution 2 has the following problems:

WLAN交换机的市场接受度非常高,因此解决方案2得到了广泛部署并继续增长。解决方案2存在以下问题:

1) Existing solutions only support WLAN networks with Ethernet backhaul and therefore are not available for advanced cellular networks or picocellular protocols, or other types of wired backhaul.

1) 现有解决方案仅支持带有以太网回程的WLAN网络,因此不适用于高级蜂窝网络或微微蜂窝协议,或其他类型的有线回程。

2) Each WLAN switch vendor has its own proprietary protocol that does not interoperate with other vendors' equipment.

2) 每个WLAN交换机供应商都有自己的专有协议,不能与其他供应商的设备进行互操作。

3) Because the solutions are based on Layer 2 routing, they may not scale up to a metropolitan area or local province, particularly when multiple kinds of link technologies are used in the backbone.

3) 由于这些解决方案基于第2层路由,它们可能无法扩展到大都市区或地方省份,特别是在主干网中使用多种链路技术时。

5. Advantages of Network-based Localized Mobility Management
5. 基于网络的本地化移动性管理的优势

Having an interoperable, standardized localized mobility management protocol that is scalable to topologically large networks, but requires no host stack involvement for localized mobility management is a highly desirable solution. The advantages that this solution has over Solutions 1 and 2 above are as follows:

拥有一个可互操作、标准化的本地化移动性管理协议,该协议可扩展到拓扑上的大型网络,但不需要主机堆栈参与本地化移动性管理,这是一个非常理想的解决方案。与上述解决方案1和2相比,此解决方案的优势如下:

1) Compared with Solution 1, a network-based solution requires no localized mobility management support on the mobile node and is independent of global mobility management protocol, so it can be used with any or none of the existing global mobility management protocols. The result is a more modular mobility management architecture that better accommodates changing technology and market requirements.

1) 与解决方案1相比,基于网络的解决方案不需要移动节点上的本地化移动性管理支持,并且独立于全局移动性管理协议,因此它可以与任何现有的全局移动性管理协议一起使用。其结果是一个更加模块化的移动性管理体系结构,能够更好地适应不断变化的技术和市场需求。

2) Compared with Solution 2, an IP-level network-based localized mobility management solution works for link protocols other than Ethernet, and for wide area networks.

2) 与解决方案2相比,基于IP级别网络的本地化移动性管理解决方案适用于以太网以外的链路协议和广域网。

RFC 4831 [11] discusses a reference architecture for a network-based, localized mobility protocol and the goals of the protocol design.

RFC 4831[11]讨论了基于网络的本地化移动协议的参考体系结构以及协议设计的目标。

6. Security Considerations
6. 安全考虑

Localized mobility management has certain security considerations, one of which -- the need for security from access network to mobile node -- was discussed 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 that is equivalent to what is needed for routing information security, and security between the host and network that is 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 [11].

本地化移动性管理有一定的安全考虑因素,本文讨论了其中一个因素——从接入网络到移动节点的安全需求。基于主机的本地化移动性管理协议具有向主机提供服务所涉及的所有安全问题。基于网络的本地化移动性管理要求网元之间的安全性相当于路由信息安全所需的安全性,主机和网络之间的安全性相当于网络访问所需的安全性,但仅此而已。关于基于网络的本地化移动性管理的安全目标的更完整的讨论可以在[11]中找到。

7. Informative References
7. 资料性引用

[1] 3GPP, "UTRAN Iu interface: General aspects and principles", 3GPP TS 25.410, 2002, http://www.3gpp.org/ftp/Specs/html-info/25410.htm.

[1] 3GPP,“UTRAN Iu接口:一般方面和原则”,3GPP TS 25.4102002,http://www.3gpp.org/ftp/Specs/html-info/25410.htm.

[2] 3GPP, "3GPP System Architecture Evolution: Report on Technical Options and Conclusions", TR 23.882, 2005, http://www.3gpp.org/ftp/Specs/html-info/23882.htm.

[2] 3GPP,“3GPP系统架构演进:技术选择和结论报告”,TR 23.8822005,http://www.3gpp.org/ftp/Specs/html-info/23882.htm.

[3] Bluetooth SIG, "Specification of the Bluetooth System", November, 2004, available at http://www.bluetooth.com.

[3] 蓝牙SIG,“蓝牙系统规范”,2004年11月,可在http://www.bluetooth.com.

[4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.

[4] Eronen,P.,“IKEv2移动性和多址协议(MOBIKE)”,RFC4552006年6月。

[5] IEEE 802.15 WPAN High Rate Alternative PHY Task Group 3a (TG3a), http://www.ieee802.org/15/pub/TG3a.html.

[5] IEEE 802.15 WPAN高速备选PHY任务组3a(TG3a),http://www.ieee802.org/15/pub/TG3a.html.

[6] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Std. 802.11, 1999.

[6] IEEE,“无线局域网介质访问控制(MAC)和物理层(PHY)规范”,IEEE标准802.111999。

[7] IEEE, "Amendment to IEEE Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed Broadband Wireless Access Systems - Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE Std. 802.16e-2005, 2005.

[7] IEEE,“局域网和城域网IEEE标准的修订——第16部分:固定宽带无线接入系统的空中接口——许可频带内固定和移动组合操作的物理和介质接入控制层”,IEEE标准802.16e-2005。

[8] IEEE, "Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std. 802.3-2005, 2005.

[8] IEEE,“带冲突检测的载波侦听多址接入(CSMA/CD)接入方法和物理层规范”,IEEE标准802.3-2005,2005年。

[9] ITU-T, "Architecture of Transport Networks Based on the Synchronous Digital Hierarchy (SDH)", ITU-T G.803, March, 2000.

[9] ITU-T,“基于同步数字体系(SDH)的传输网络体系结构”,ITU-T G.803,2000年3月。

[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[10] Johnson,D.,Perkins,C.,和J.Arkko,“IPv6中的移动支持”,RFC 37752004年6月。

[11] Kempf, J., Ed., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.

[11] Kempf,J.,Ed.,“基于网络的本地化移动性管理(NETLMM)的目标”,RFC 48312007年4月。

[12] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", Work in Progress, February 2007.

[12] Koodli,R.,“IP地址位置隐私和移动IPv6:问题陈述”,正在进行的工作,2007年2月。

[13] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.

[13] Koodli,R.,“移动IPv6的快速切换”,RFC 4068,2005年7月。

[14] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.

[14] Way,J.和M.Kojo,“机动性相关术语”,RFC 3753,2004年6月。

[15] Metro Ethernet Forum, " Metro Ethernet Network Architecture Framework - Part 1: Generic Framework", MEF 4, May, 2004.

[15] Metro Ethernet论坛,“Metro Ethernet网络架构框架-第1部分:通用框架”,MEF 4,2004年5月。

[16] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.

[16] Moskowitz,R.和P.Nikander,“主机身份协议(HIP)体系结构”,RFC4423,2006年5月。

[17] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.

[17] Perkins,C.,“IPv4的IP移动支持”,RFC 3344,2002年8月。

[18] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.

[18] Soliman,H.,Castelluccia,C.,El Malki,K.,和L.Bellier,“分层移动IPv6移动性管理(HMIPv6)”,RFC 41402005年8月。

8. Acknowledgements
8. 致谢

The authors would like to acknowledge the following for particularly diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin.

作者要感谢以下几位特别认真的评论:Vijay Devarapalli、Peter McCann、Gabriel Montegon、Vidya Narayanan、Pekka Savola和Fred Templin。

9. Contributors
9. 贡献者

Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kleung@cisco.com

Kent Leung Cisco Systems,Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号,邮编95134电子邮件:kleung@cisco.com

Phil Roberts Motorola Labs Schaumberg, IL USA EMail: phil.roberts@motorola.com

Phil Roberts Motorola Labs Schaumbeg,伊利诺伊州美国电子邮件:Phil。roberts@motorola.com

Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 EMail: nishidak@nttdocomo.co.jp

西田胜寿NTT DoCoMo Inc.3-5 Hikarino oka,横须贺市神奈川,日本电话:+81 46 840 3545电子邮件:nishidak@nttdocomo.co.jp

Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 EMail: gerardo.giaretta@tilab.com

Gerardo Giaretta Telecom Italia Lab通过G.Reiss Romoli,274 10148意大利都灵电话:+39 011 2286904电子邮件:Gerardo。giaretta@tilab.com

Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 EMail: marco.liebsch@ccrle.nec.de

Marco Liebsch NEC网络实验室Kurfuersten Anlage 36 69115德国海德堡电话:+49 6221-90511-46电子邮件:Marco。liebsch@ccrle.nec.de

Editor's Address

编辑地址

James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com

詹姆斯·肯普夫·多科莫美国实验室加利福尼亚州圣何塞市地铁路181号300室95110美国电话:+1408 451 4711电子邮件:kempf@docomolabs-美国网

Full Copyright Statement

完整版权声明

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。