Internet Engineering Task Force (IETF)                   M. Liebsch, Ed.
Request for Comments: 6279                                           NEC
Category: Informational                                         S. Jeong
ISSN: 2070-1721                                                     ETRI
                                                                   Q. Wu
                                                                  Huawei
                                                               June 2011
        
Internet Engineering Task Force (IETF)                   M. Liebsch, Ed.
Request for Comments: 6279                                           NEC
Category: Informational                                         S. Jeong
ISSN: 2070-1721                                                     ETRI
                                                                   Q. Wu
                                                                  Huawei
                                                               June 2011
        

Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement

代理移动IPv6(PMIPv6)本地化路由问题声明

Abstract

摘要

Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6.

代理移动IPv6是基于网络的移动性管理的IETF标准。在代理移动IPv6中,移动节点在拓扑上锚定在本地移动锚上,本地移动锚转发注册移动节点的所有数据。不考虑本地路由的设置和维护,该路由允许在两个移动节点的移动接入网关之间转发数据包,而无需本地移动锚参与转发。本文档描述了代理移动IPv6中本地化路由的问题空间。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6279.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc6279.

Copyright Notice

版权公告

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2011 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1. Introduction ....................................................2
   2. Conventions and Terminology .....................................3
   3. Problem Statement for Localized Routing in PMIPv6 ...............4
      3.1. General Observation ........................................4
      3.2. Use Cases Analysis .........................................5
      3.3. IPv4 Considerations ........................................8
           3.3.1. Localized Routing for Communication between
                  IPv4 Home Addresses .................................8
           3.3.2. IPv4 Transport Network Considerations ...............9
   4. Functional Requirements for Localized Routing ...................9
   5. Roaming Considerations .........................................10
   6. Security Considerations ........................................11
   7. Acknowledgments ................................................12
   8. References .....................................................13
      8.1. Normative References ......................................13
      8.2. Informative References ....................................13
        
   1. Introduction ....................................................2
   2. Conventions and Terminology .....................................3
   3. Problem Statement for Localized Routing in PMIPv6 ...............4
      3.1. General Observation ........................................4
      3.2. Use Cases Analysis .........................................5
      3.3. IPv4 Considerations ........................................8
           3.3.1. Localized Routing for Communication between
                  IPv4 Home Addresses .................................8
           3.3.2. IPv4 Transport Network Considerations ...............9
   4. Functional Requirements for Localized Routing ...................9
   5. Roaming Considerations .........................................10
   6. Security Considerations ........................................11
   7. Acknowledgments ................................................12
   8. References .....................................................13
      8.1. Normative References ......................................13
      8.2. Informative References ....................................13
        
1. Introduction
1. 介绍

The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the base protocol for network-based localized mobility management (NetLMM). The scope of the base protocol covers the setup and maintenance of a tunnel between a Mobile Node's (MN's) Mobile Access Gateway (MAG) and its selected Local Mobility Anchor (LMA). Data packets will always traverse the MN's MAG and its LMA, irrespective of the location of the MN's remote communication endpoint. Even though an MN may be attached to the same MAG or a different MAG as its Correspondent Node (CN) within the same provider domain, packets being associated with their communication will traverse the MN's and the CN's LMA, which can be located topologically far away from the MN's and the CN's MAG or even in a separate provider domain.

IETF已指定代理移动IPv6(PMIPv6)[RFC5213]作为基于网络的本地化移动性管理(NetLMM)的基本协议。基本协议的范围包括在移动节点(MN)的移动接入网关(MAG)与其选择的本地移动锚(LMA)之间建立和维护隧道。数据包将始终穿过MN的MAG及其LMA,而与MN的远程通信端点的位置无关。即使MN可以连接到同一提供商域内与其对应节点(CN)相同的MAG或不同的MAG,与它们的通信相关联的分组也将穿过MN和CN的LMA,其可以在拓扑上远离MN和CN的MAG,或者甚至位于单独的提供商域中。

[RFC5213] addresses the need to enable local routing of traffic between two nodes being attached to the same MAG, but does not specify the complete procedure to establish such localized routing state on the shared MAG.

[RFC5213]解决了在连接到同一MAG的两个节点之间启用流量本地路由的需要,但未指定在共享MAG上建立这种本地化路由状态的完整过程。

The NetLMM Extensions (NetExt) Working Group has an objective to design a solution for localized routing in PMIPv6. This objective includes the specification of protocol messages and associated protocol operation between PMIPv6 components to support the setup of a direct routing path for data packets between the MN's and the CN's MAG, while both hosts receive mobility service according to the PMIPv6 protocol [RFC5213]. As a result of localized routing, these packets will be forwarded between the two associated MAGs without traversing the MN's and the CN's LMA(s). In cases where one or both nodes hand over to a different MAG, the localized routing protocol maintains the localized routing path. Relevant protocol interfaces may include the interface between associated MAGs, between a MAG and an LMA, and between LMAs. The setup of localized routing with CNs not registered with a PMIPv6 network is out of scope of the NetExt solution and this problem statement.

NetLMM扩展(NetExt)工作组的目标是为PMIPv6中的本地化路由设计一个解决方案。该目标包括PMIPv6组件之间协议消息和相关协议操作的规范,以支持MN和CN的MAG之间数据包的直接路由路径的设置,同时两个主机根据PMIPv6协议接收移动服务[RFC5213]。作为本地化路由的结果,这些分组将在两个相关的mag之间转发,而无需穿过MN和CN的LMA。在一个或两个节点切换到不同MAG的情况下,本地化路由协议保持本地化路由路径。相关协议接口可包括相关MAG之间、MAG与LMA之间以及LMA之间的接口。未向PMIPv6网络注册CNs的本地化路由设置超出NetExt解决方案和本问题说明的范围。

This document analyzes and discusses the problem space of always using the default route through two communicating mobile nodes' local mobility anchors. Furthermore, the problem space of enabling localized routing in PMIPv6 is analyzed and described, while different communication and mobility scenarios are taken into account. Based on the analysis, a list of key functional requirements is provided, serving as input to the design of the protocol solution.

本文分析和讨论了通过两个通信移动节点的本地移动锚始终使用默认路由的问题空间。此外,还分析和描述了PMIPv6中实现本地化路由的问题空间,同时考虑了不同的通信和移动场景。在分析的基础上,提供了关键功能需求列表,作为协议解决方案设计的输入。

2. Conventions and Terminology
2. 公约和术语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

This document uses the terminology of [RFC5213]. In addition, the following terms are used in the context of this problem statement:

本文件使用[RFC5213]的术语。此外,本问题陈述中使用了以下术语:

o Mobile Node (MN): Mobile Node without IP mobility support, which is attached to a Mobile Access Gateway (MAG) and registered with a Local Mobility Anchor (LMA) according to the PMIPv6 specification [RFC5213].

o 移动节点(MN):不支持IP移动性的移动节点,根据PMIPv6规范[RFC5213]连接到移动接入网关(MAG)并向本地移动性锚(LMA)注册。

o Correspondent Node (CN): Correspondent Node according to its definition in [RFC3775] with or without IP mobility support. The CN represents the communication peer of an MN that is attached to a MAG and registered with an LMA according to the PMIPv6 specification.

o 对应节点(CN):根据[RFC3775]中的定义,有或没有IP移动性支持的对应节点。CN表示根据PMIPv6规范连接到MAG并向LMA注册的MN的通信对等方。

o Localized Routing: Result of signaling to set up routing states on relevant network entities to allow forwarding of data packets between an MN and a CN, which are attached to MAGs sharing the same provider domain, without intervention of the MN's LMA and the CN's LMA in data forwarding.

o 本地化路由:在相关网络实体上设置路由状态的信令结果,以允许在MN和CN之间转发数据包,这些数据包连接到共享同一提供商域的MAG,而不需要MN的LMA和CN的LMA在数据转发中进行干预。

o Localized Routing States: Information for localized routing on relevant forwarding entities on the optimized data path between an MN and a CN. Such information includes route entries and tunnel endpoints and may include further information about the MN and the CN, such as the communicating nodes' Mobile Node Identifier and their assigned Home Network Prefix.

o 本地化路由状态:MN和CN之间优化数据路径上相关转发实体的本地化路由信息。此类信息包括路由条目和隧道端点,并且可以包括关于MN和CN的进一步信息,例如通信节点的移动节点标识符及其分配的家庭网络前缀。

o Provider Domain: A network domain in which network components are administered by a single authority, e.g., the mobile operator.

o 提供商域:一个网络域,其中网络组件由一个机构(如移动运营商)管理。

3. Problem Statement for Localized Routing in PMIPv6
3. PMIPv6中本地化路由的问题陈述
3.1. General Observation
3.1. 一般观察

The Mobile IPv6 (MIPv6) protocol [RFC3775] has built-in mechanisms for direct communication between an MN and a CN. Mechanisms for route optimization in MIPv6 cannot be directly applied in PMIPv6. Following the paradigm of PMIPv6, MNs are not involved in mobility signaling and hence cannot perform signaling to set up localized routes. Instead, the solution for localized routing must consider functions in the network to find out whether or not a localized route is to be used and then control the setup and maintenance of localized routing states accordingly without any assistance from the MN and the CN. In the case of communication between two nodes attached to the PMIPv6 network infrastructure and where each node is registered with an LMA, data packets between these two nodes will always traverse the responsible LMA(s). At least some deployments would benefit from having such communication localized, rather than having packets traverse the core network to the LMA(s). In the context of this document, such localized communication comprises offloading traffic from LMAs and establishing an optimized forwarding path between the two communication endpoints.

移动IPv6(MIPv6)协议[RFC3775]具有用于MN和CN之间直接通信的内置机制。MIPv6中的路由优化机制不能直接应用于PMIPv6。遵循PMIPv6的范例,MNs不参与移动信令,因此无法执行信令以建立本地化路由。相反,局部路由的解决方案必须考虑网络中的功能来确定是否要使用本地化路由,然后在没有来自MN和CN的任何帮助的情况下相应地控制局部化路由状态的建立和维护。在连接到PMIPv6网络基础设施的两个节点之间进行通信的情况下,并且在每个节点向LMA注册的情况下,这两个节点之间的数据分组将始终穿过负责的LMA。至少一些部署将受益于将此类通信本地化,而不是让数据包穿过核心网络到达LMA。在本文档的上下文中,这种本地化通信包括从lma卸载流量和在两个通信端点之间建立优化的转发路径。

Localized routing is understood in [RFC5213] as optimization of traffic between an MN and a CN that are attached to an access link connected to the same MAG. In such a case, the MAG forwards traffic

在[RFC5213]中,本地化路由被理解为连接到同一MAG的接入链路的MN和CN之间的流量优化。在这种情况下,MAG转发流量

directly between the MN and the CN, assuming the MAG is enabled to support this feature (setting of the EnableMAGLocalRouting flag on the MAG) and the MN's LMA enforces this optimization. [RFC5213] does not specify how an LMA can enforce optimization for such local communication. Maintaining local forwarding between the MN and the regular IPv6 CN gets more complex in the case where the MN performs a handover to a different MAG. Such a use case is not considered in the specification and is out of scope of this problem statement. This document focuses on use cases where both nodes, the MN and the CN, are within a PMIPv6 network and served by an LMA in a domain of LMAs.

直接在MN和CN之间,假设MAG已启用以支持此功能(在MAG上设置EnableMAGLocalRouting标志),并且MN的LMA强制执行此优化。[RFC5213]未指定LMA如何对此类本地通信实施优化。在MN执行到不同MAG的切换的情况下,维护MN和常规IPv6 CN之间的本地转发变得更加复杂。规范中未考虑此类用例,并且超出了本问题陈述的范围。本文档主要关注节点MN和CN都位于PMIPv6网络内并由LMA域中的LMA服务的用例。

With localized routing, operators have the possibility of offloading traffic from LMAs and from the core network. Establishment of a direct path between the MN's and the CN's MAG can be beneficial for the following reasons: First, by limiting the communication to the access nodes, the data traffic traversing the MAG - LMA path (network) can be reduced. This is significant, considering that the transport network between the access and the core is often the bottleneck in terms of costs and performance. Second, there may be performance benefits for data flows between the MN and the CN in terms of delay and packet loss, especially when the MN and the CN are attached to the same MAG and the LMA is topologically far away from that MAG. Even when the MN and the CN are attached to different MAGs, there could be benefit in limiting the communication to the access network only, rather than traversing the transport network to the LMA. Furthermore, offloading traffic from the LMA by means of localized routing can improve scalability of the LMA, as it represents a bottleneck for traffic being forwarded by many MAGs.

通过本地化路由,运营商可以从LMA和核心网络卸载流量。在MN和CN的MAG之间建立直接路径可能出于以下原因而有益:首先,通过限制到接入节点的通信,可以减少通过MAG-LMA路径(网络)的数据流量。考虑到接入和核心之间的传输网络通常是成本和性能方面的瓶颈,这一点非常重要。第二,在延迟和分组丢失方面,MN和CN之间的数据流可能具有性能优势,特别是当MN和CN连接到同一MAG并且LMA在拓扑上远离该MAG时。即使当MN和CN连接到不同的MAG时,将通信仅限于接入网络,而不是将传输网络穿越到LMA,这可能是有益的。此外,通过局部路由从LMA卸载流量可以提高LMA的可伸缩性,因为它代表了许多mag转发的流量的瓶颈。

3.2. Use Cases Analysis
3.2. 用例分析

This problem statement focuses on local communication between PMIPv6 managed nodes, which attach to MAGs sharing the same provider domain. The following list analyzes different use cases, which consider the existence of multiple LMAs. Figure 1 depicts a PMIPv6-based network with two mobility anchors. According to [RFC5213], the MN moves in the PMIPv6 domain being built by its LMA and MAG. The same applies to the CN, which moves in the PMIPv6 domain built by the CN's LMA and MAG. The analysis takes no assumption on whether the MN and the CN share the same PMIPv6 domain or not.

此问题陈述主要关注PMIPv6托管节点之间的本地通信,这些节点连接到共享同一提供商域的MAG。下面的列表分析不同的用例,考虑多个LMAS的存在。图1描述了具有两个移动锚的基于PMIPv6的网络。根据[RFC5213],MN在由其LMA和MAG构建的PMIPv6域中移动。同样的情况也适用于CN,其在由CN的LMA和MAG构建的PMIPv6域中移动。分析不假设MN和CN是否共享同一PMIPv6域。

                              Internet Backbone
                             :                  :
                             +------------------+
                             |                  |
                          +----+              +----+
                          |LMA1|              |LMA2|
                          +----+              +----+
                             |                  |
                             |                  |
                        +----+------------------+----+
                        |                            |
                     +----+                       +----+
                     |MAG1|                       |MAG2|
                     +----+                       +----+
                     :    :                          :
                   +---+ +---+                     +---+
                   |MN | |CN1|                     |CN2|
                   +---+ +---+                     +---+
        
                              Internet Backbone
                             :                  :
                             +------------------+
                             |                  |
                          +----+              +----+
                          |LMA1|              |LMA2|
                          +----+              +----+
                             |                  |
                             |                  |
                        +----+------------------+----+
                        |                            |
                     +----+                       +----+
                     |MAG1|                       |MAG2|
                     +----+                       +----+
                     :    :                          :
                   +---+ +---+                     +---+
                   |MN | |CN1|                     |CN2|
                   +---+ +---+                     +---+
        

Figure 1: Reference Architecture for Localized Routing in PMIPv6

图1:PMIPv6中本地化路由的参考体系结构

All "A" use cases below assume that both the MN and the CN are registered with an LMA according to the PMIPv6 protocol. Whereas MAG1 is always considered as the MN's current Proxy Care-of Address, the CN can be either connected to the same MAG or to a different MAG or LMA as the MN. Accordingly, these topological differences are denoted as follows:

下面的所有“A”用例都假设MN和CN都根据PMIPv6协议向LMA注册。鉴于MAG1始终被视为MN的当前代理转交地址,CN可以连接到同一MAG,也可以连接到与MN不同的MAG或LMA。因此,这些拓扑差异表示如下:

A[number of MAGs][number of LMAs]

A[管理小组的数目][管理小组的数目]

A11: The MN and the CN (CN1) connect to the same MAG (MAG1) and are registered with the same LMA (LMA). The common MAG may forward data packets between the MN and the CN directly without forwarding any packet to the LMA. [RFC5213] addresses this use case, but does not specify the complete procedure to establish such localized routing state on the shared MAG.

A11:MN和CN(CN1)连接到同一个MAG(MAG1)并在同一个LMA(LMA)中注册。公共MAG可以直接在MN和CN之间转发数据分组,而不向LMA转发任何分组。[RFC5213]解决了这个用例,但没有指定在共享MAG上建立这种本地化路由状态的完整过程。

A12: The MN and the CN (CN1) connect to the same MAG (MAG1) and are registered with different LMAs (LMA1 and LMA2). The common MAG may forward data packets between the MN and the CN directly without forwarding any packet to the LMAs. Following the policy of [RFC5213] and enforcement of the setup of a localized forwarding path, potential problems exist in the case where LMA1 and LMA2 differ in their policy to control the MAG.

A12:MN和CN(CN1)连接到同一个MAG(MAG1),并在不同的LMA(LMA1和LMA2)中注册。公共MAG可以直接在MN和CN之间转发数据分组,而不向lma转发任何分组。按照[RFC5213]的策略和实施本地化转发路径的设置,在LMA1和LMA2控制MAG的策略不同的情况下,存在潜在问题。

A21: The CN (CN2) connects to a different MAG (MAG2) than the MN (MAG1), but the MN and the CN are registered with the same LMA (LMA1). The result of localized routing should be the existence

A21:CN(CN2)连接到与MN(MAG1)不同的MAG(MAG2),但MN和CN使用相同的LMA(LMA1)注册。本地化路由的结果应该是存在的

of routing information at MAG1 and MAG2, which allows direct forwarding of packets between the MN's MAG1 and the CN's MAG2. As LMA1 is the common anchor for the MN and the CN and maintains location information for both nodes, no major race condition and instability in updating the states for localized routing is expected.

在MAG1和MAG2处的路由信息,其允许在MN的MAG1和CN的MAG2之间直接转发分组。由于LMA1是MN和CN的公共锚点,并且维护两个节点的位置信息,因此在更新局部路由的状态时不会出现主要竞争条件和不稳定性。

A22: The CN (CN2) connects to a different MAG (MAG2) and a different LMA (LMA2) than the MN (MAG1, LMA1). The result of localized routing should be the existence of routing information at MAG1 and MAG2, which allows direct forwarding of packets between the MN's MAG1 and the CN's MAG2. As the location information of the CN and the MN is maintained at different LMAs, both LMAs need to be involved in the procedure to set up localized routing. In the case of a handover of the MN and/or the CN to a different MAG, non-synchronized control of updating the states for localized routing may result in race conditions, superfluous signaling, and packet loss.

A22:CN(CN2)连接到不同于MN(MAG1,LMA1)的MAG(MAG2)和LMA(LMA2)。本地化路由的结果应该是MAG1和MAG2处存在路由信息,这允许在MN的MAG1和CN的MAG2之间直接转发分组。由于CN和MN的位置信息保持在不同的lma上,因此两个lma都需要参与建立本地化路由的过程。在将MN和/或CN切换到不同MAG的情况下,为局部路由更新状态的非同步控制可能导致竞争条件、多余信令和分组丢失。

The following list summarizes general problems with setting up and maintaining localized routing between an MN and a CN. In the context of this problem statement, the MN and the CN are always assumed to be registered at an LMA according to the PMIPv6 protocol [RFC5213].

下表总结了在MN和CN之间设置和维护本地化路由的一般问题。在该问题陈述的上下文中,根据PMIPv6协议[RFC5213],MN和CN始终假定在LMA处注册。

o MNs do not participate in mobility management and hence cannot perform binding registration at a CN on their own. Rather, entities in the network infrastructure must take over the role of MNs to set up and maintain a direct route. Accordingly, a solution for localized routing in PMIPv6 must specify protocol operation between relevant network components, such as between a MAG and an LMA, to enable localized routing for data traffic without traversing the MN's and the CN's LMA(s).

o MN不参与移动性管理,因此不能自己在CN上执行绑定注册。相反,网络基础设施中的实体必须接管MNs的角色,以建立和维护直接路由。因此,PMIPv6中用于本地化路由的解决方案必须指定相关网络组件之间的协议操作,例如MAG和LMA之间的协议操作,以便在不穿越MN和CN的LMA的情况下实现数据业务的本地化路由。

o In the case where the MN and the CN are both registered with different LMAs according to the PMIPv6 protocol, relevant information for the setup of a localized routing path, such as the current MAG of the MN and the CN, is distributed between these LMAs. This may complicate the setup and stable maintenance of states enabling localized routing.

o 在MN和CN都根据PMIPv6协议在不同lma中注册的情况下,在这些lma之间分发用于设置本地化路由路径的相关信息,例如MN和CN的当前MAG。这可能会使启用本地化路由的状态的设置和稳定维护复杂化。

o In the case where localized routing between an MN and a CN has been successfully set up and both nodes move and attach to a new access router simultaneously, signaling the new location and maintenance of states for localized routing at relevant routers may run into a race condition situation. This can happen in the case where coordination of signaling for localized routing and provisioning of relevant state information is distributed between different network entities, e.g., different LMAs. In such a case,

o 在MN和CN之间的本地化路由已经成功建立并且两个节点同时移动并连接到新的接入路由器的情况下,在相关路由器处用信令发送用于本地化路由的新位置和状态的维护可能会进入竞态情况。在不同网络实体(例如,不同lma)之间分配用于本地化路由和提供相关状态信息的信令协调的情况下,这可能发生。在这种情况下,,

as a result of the MN's handover, updated information about the MN's location may arrive at the CN's previous MAG, while the CN has already moved to a new MAG. The same applies to the other direction, where the system may update the MN's previous MAG about the CN's new location, while the MN has moved to a new MAG in the meantime. The protocol solution must deal with such exceptional handover cases efficiently to avoid or resolve such problems.

作为MN的切换的结果,关于MN的位置的更新信息可能到达CN的先前MAG,而CN已经移动到新MAG。这同样适用于另一个方向,其中系统可能更新关于CN的新位置的MN的先前MAG,同时MN已经移动到新MAG。协议解决方案必须有效地处理此类异常切换情况,以避免或解决此类问题。

3.3. IPv4 Considerations
3.3. IPv4注意事项

According to [RFC5844], the basic configuration requirements for supporting IPv4 in PMIPv6 are that LMAs and MAGs are both IPv4 and IPv6 enabled. Also, LMAs and MAGs must have a globally unique IPv6 address configured, irrespective of enabled support for IPv6 routing between these components. This requirement should also apply to configuration requirements of localized routing.

根据[RFC5844],在PMIPv6中支持IPv4的基本配置要求是LMA和MAG同时启用IPv4和IPv6。此外,LMA和MAG必须配置全局唯一的IPv6地址,而不管这些组件之间是否支持IPv6路由。此要求也应适用于本地化路由的配置要求。

Additional issues emerge when localized routing is considered for PMIPv6 with IPv4 support. These can be classified into two general groups: issues with localized routing between an MN's and a CN's IPv4 Home Addresses, and transport plane issues. The following subsections analyze these two groups.

当考虑使用IPv4支持的PMIPv6进行本地化路由时,会出现其他问题。这些问题可以分为两大类:MN和CN的IPv4主地址之间的本地化路由问题,以及传输平面问题。以下小节将分析这两个组。

3.3.1. Localized Routing for Communication between IPv4 Home Addresses
3.3.1. IPv4主地址之间通信的本地化路由

In the case where an LMA and a MAG hold a registration to support IPv4 Home Address mobility for an MN, the MAG and the LMA must support appropriate encapsulation of IPv4 packets. To enable localized routing, the MN's MAG must encapsulate and forward routing path optimized packets to the CN's MAG and needs to ensure that the chosen encapsulation mode is supported by the correspondent MAG. Incompatibility in a selected encapsulation mode causes failure in setting up a localized route.

在LMA和MAG持有注册以支持MN的IPv4归属地址移动的情况下,MAG和LMA必须支持IPv4分组的适当封装。要启用本地化路由,MN的MAG必须将路由路径优化的数据包封装并转发到CN的MAG,并且需要确保相应的MAG支持所选的封装模式。所选封装模式中的不兼容会导致设置本地化路由失败。

When localized routing is used for IPv4 traffic, the conceptual data structures on associated MAGs must be augmented with appropriate parameters for forwarding localized traffic. MAGs may need to maintain a routing state for each MN-CN-pair and make routing decisions for uplink traffic based on the packet's complete IPv4 source and destination address. Hence, conceptual data structures to handle states for localized routes need to comprise this address tuple for unique identification.

当本地化路由用于IPv4流量时,必须使用适当的参数来扩展相关MAG上的概念数据结构,以转发本地化流量。MAG可能需要维护每个MN-CN对的路由状态,并根据数据包的完整IPv4源地址和目标地址为上行链路流量做出路由决策。因此,用于处理本地化路由状态的概念数据结构需要包含此地址元组以进行唯一标识。

As a known constraint, IPv4 addresses of two nodes that hold addresses from a private address space may overlap. To uniquely identify both nodes, the IPv4 address of the MN and the CN must not overlap. To cope with overlapping address spaces, the localized routing solution could use additional mechanisms to tag and uniquely identify the MN and the CN.

作为已知的约束,持有来自专用地址空间的地址的两个节点的IPv4地址可能重叠。要唯一标识这两个节点,MN和CN的IPv4地址不得重叠。为了处理重叠的地址空间,本地化路由解决方案可以使用额外的机制来标记和唯一标识MN和CN。

3.3.2. IPv4 Transport Network Considerations
3.3.2. IPv4传输网络注意事项

The transport network between the LMA and the MAG may be based on IPv6 or IPv4. Deployments may ensure that the same transport mechanism (i.e., IPv6 or IPv4) is used for operational consistency. Similar to the encapsulation requirement stated in the previous section, the IP version used for localized routing is also assumed, by configuration, to be consistent across all MAGs within the associated provider domain. The design of optional mechanisms for negotiating the IP version to use as well as the encapsulation mode to use are outside the scope of the NetExt WG's solution for localized routing.

LMA和MAG之间的传输网络可以基于IPv6或IPv4。部署可确保使用相同的传输机制(即IPv6或IPv4)实现操作一致性。与前一节中所述的封装要求类似,通过配置,还假设用于本地化路由的IP版本在相关提供商域内的所有MAG中保持一致。用于协商要使用的IP版本以及要使用的封装模式的可选机制的设计超出了NetExt WG本地化路由解决方案的范围。

4. Functional Requirements for Localized Routing
4. 本地化路由的功能需求

Several tasks need to be performed by the network infrastructure components before relevant information for such direct communication is discovered and associated states for localized routing can be set up. The following list summarizes some key functions that need to be performed by the PMIPv6-enabled network infrastructure to substitute mobile nodes in setting up a direct route.

在发现此类直接通信的相关信息并设置本地化路由的相关状态之前,网络基础设施组件需要执行若干任务。下表总结了启用PMIPv6的网络基础设施在设置直接路由时需要执行的一些关键功能,以替代移动节点。

o Detection of the possibility to perform localized routing. This function includes looking at a data packet's source and destination address.

o 检测执行本地化路由的可能性。此功能包括查看数据包的源地址和目标地址。

o Initiation of a procedure that sets up a localized routing path.

o 启动设置本地化路由路径的过程。

o Discovery of stateful entities (i.e., the LMA(s) and/or the MAG(s)) that maintain and can provide relevant information needed to set up a localized routing path. Such information may include the routable address of an LMA or MAG, where one or both mobile nodes are connected to and registered with that LMA or MAG.

o 发现有状态实体(即,LMA和/或MAG),这些实体维护并能够提供建立本地化路由路径所需的相关信息。此类信息可包括LMA或MAG的可路由地址,其中一个或两个移动节点连接到该LMA或MAG并向其注册。

o Control in setting up and maintaining (e.g., during handover) the localized routing path. Control is also needed to terminate the use of a localized routing path and to delete associated states, whereas a trigger for the termination may come from a non-PMIPv6- related component.

o 控制本地化路由路径的设置和维护(例如,在切换期间)。还需要控制来终止本地化路由路径的使用并删除关联状态,而终止的触发器可能来自非PMIPv6相关组件。

o Enforcement of administrative policy rules to localized routing. Such policies allow operators to have further control of the setup of a localized route and enable the possibility to disallow localized routing, for example, to ensure that traffic traverses charging-related functions on the LMA. Explicit authorization of localized routing is, for example, discussed in [PMIP6-LR]. As a further example, mobile-node- and operator-specific policy rules can be established on PMIPv6 components during PMIPv6 bootstrapping according to [RFC5779].

o 对本地化路由执行管理策略规则。此类策略允许运营商进一步控制本地化路由的设置,并允许禁止本地化路由的可能性,例如,以确保流量通过LMA上的收费相关功能。例如,在[PMIP6-LR]中讨论了本地化路由的显式授权。作为进一步的示例,根据[RFC5779],在PMIPv6引导期间,可以在PMIPv6组件上建立特定于移动节点和运营商的策略规则。

5. Roaming Considerations
5. 漫游注意事项

Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs, MAGs) tied by the MN and the CN may be distributed between different provider domains (i.e., domain A, B, C) and the MN and/or CN moves from one provider domain to another one. In order to support localized routing when roaming occurs, it is required that MAGs to which the MN and CN connect be within the same provider domain, and each MAG has a security relationship with the corresponding LMA, which maintains the registration of the MN or the CN, respectively.

图2显示了PMIPv6漫游情况,其中由MN和CN绑定的PMIPv6组件(例如,lma、mag)可以分布在不同的提供商域(即,域A、B、C)之间,并且MN和/或CN从一个提供商域移动到另一个提供商域。为了在漫游发生时支持本地化路由,要求MN和CN连接到的MAG位于同一提供商域内,并且每个MAG与相应的LMA具有安全关系,LMA分别维护MN或CN的注册。

According to the roaming model as depicted in Figure 2, the MN's PMIPv6 domain is characterized by its MAG (MAG1/MAG1') and its LMA (LMA1), whereas the CN's PMIPv6 domain is characterized by the CN's MAG (MAG2/MAG2') and its LMA (LMA2/LMA2'). A solution for localized routing cannot take any assumption about whether or not the MN and CN share the same PMIPv6 domain; hence, MAG1/MAG1' may not share a security association with LMA2/LMA2', and MAG2/MAG2' may not share a security association with LMA1, respectively.

根据图2所示的漫游模型,MN的PMIPv6域以其MAG(MAG1/MAG1')和LMA(LMA1)为特征,而CN的PMIPv6域以CN的MAG(MAG2/MAG2')和LMA(LMA2/LMA2')为特征。本地化路由解决方案不能假设MN和CN是否共享同一个PMIPv6域;因此,MAG1/MAG1'可能不与LMA2/LMA2'共享安全关联,而MAG2/MAG2'可能不分别与LMA1共享安全关联。

It is not required that LMAs, which hold the registration for the MN and the CN, respectively, be part of the same provider domain as the MAGs where the MN and CN attach. When the MN's MAG and LMA belong to different provider domains (A and C), localized routing is subject to policy governing the service level agreements between these domains. The same applies to the provider domains that provide the CN's MAG and LMA. Based on the above requirements, four PMIPv6 roaming and non-roaming cases can be taken into account.

不要求分别持有MN和CN注册的LMA与MN和CN所在的MAG属于同一提供商域。当MN的MAG和LMA属于不同的提供商域(A和C)时,本地化路由受管理这些域之间的服务级别协议的策略的约束。这同样适用于提供CN的MAG和LMA的提供商域。基于上述要求,可考虑四种PMIPv6漫游和非漫游情况。

o Case 1: The MN's MAG (MAG1), the CN's MAG (MAG2), the MN's LMA (LMA1), and the CN's LMA (LMA2) are located in the same provider domain A.

o 案例1:MN的MAG(MAG1)、CN的MAG(MAG2)、MN的LMA(LMA1)和CN的LMA(LMA2)位于同一提供商域A中。

o Case 2: The MN's MAG (MAG1), the CN's MAG (MAG2), and the MN's LMA (LMA1) are located in the same domain A, while the CN's LMA (LMA2') is located in provider domain B.

o 案例2:MN的MAG(MAG1)、CN的MAG(MAG2)和MN的LMA(LMA1)位于同一域A中,而CN的LMA(LMA2')位于提供商域B中。

o Case 3: The MN's MAG (MAG1') and the CN's MAG (MAG2') are located in domain C, while the MN's LMA (LMA1) and the CN's LMA (LMA2) are located in provider domain A.

o 案例3:MN的MAG(MAG1')和CN的MAG(MAG2')位于域C中,而MN的LMA(LMA1)和CN的LMA(LMA2)位于提供商域A中。

o Case 4: The MN's MAG (MAG1') and the CN's MAG (MAG2') are located in provider domain C, while the MN's LMA (LMA1) is located in provider domain A and the CN's LMA (LMA2') is located in provider domain B.

o 案例4:MN的MAG(MAG1')和CN的MAG(MAG2')位于提供商域C中,而MN的LMA(LMA1)位于提供商域A中,CN的LMA(LMA2')位于提供商域B中。

In these roaming cases, the MN can be allowed to roam within its domain (e.g., the MN's home domain in which the MN's LMA is located) or over different domains (e.g., the MN moves from its home domain to a visited domain). During mobility, the CN and MN should remain attached to MAGs of the same provider domain to maintain efficient routing of traffic between their MAGs.

在这些漫游情况下,可以允许MN在其域内(例如,MN的LMA所在的MN的归属域)或在不同域上漫游(例如,MN从其归属域移动到访问域)。在移动期间,CN和MN应保持与相同提供商域的mag的连接,以维持其mag之间的业务的有效路由。

                                     |
           +-----+       +-----+     |      +-----+
           |LMA1 |       |LMA2 |     |      |LMA2'|
           +-----+       +-----+     |      +-----+
                                     |
                                     |
                                     |
                                     |
           +-----+       +-----+     |
           |MAG1 |       |MAG2 |     |
           +-----+       +-----+     |
                                     |
                                     |
                  Provider Domain A  |  Provider Domain B
       ------------------------------+-------------------------------
                             Provider Domain C
        
                                     |
           +-----+       +-----+     |      +-----+
           |LMA1 |       |LMA2 |     |      |LMA2'|
           +-----+       +-----+     |      +-----+
                                     |
                                     |
                                     |
                                     |
           +-----+       +-----+     |
           |MAG1 |       |MAG2 |     |
           +-----+       +-----+     |
                                     |
                                     |
                  Provider Domain A  |  Provider Domain B
       ------------------------------+-------------------------------
                             Provider Domain C
        
                          +-----+        +-----+
                          |MAG1'|        |MAG2'|
                          +-----+        +-----+
        
                          +-----+        +-----+
                          |MAG1'|        |MAG2'|
                          +-----+        +-----+
        

Figure 2: PMIPv6 Roaming Cases Considered for Localized Routing

图2:本地化路由考虑的PMIPv6漫游情况

6. Security Considerations
6. 安全考虑

A protocol solution for localized routing in a PMIPv6 network must counter unauthorized change of a routing path. In particular, the control plane for localized routing must preclude the blocking or hijacking of mobile nodes' traffic by malicious or compromised network components. A security solution must support suitable mechanisms for authentication of control plane components of the localized routing functional architecture for both roaming and

PMIPv6网络中用于本地化路由的协议解决方案必须阻止未经授权的路由路径更改。特别是,用于本地化路由的控制平面必须防止恶意或受损网络组件阻塞或劫持移动节点的流量。安全解决方案必须支持适当的机制,以便对漫游和移动的本地化路由功能体系结构的控制平面组件进行身份验证

non-roaming scenarios. Any possibility for Internet hosts to interfere with the localized routing procedure in a malicious manner must be precluded.

非漫游场景。必须排除Internet主机以恶意方式干扰本地化路由过程的任何可能性。

Since network entities other than MNs and CNs perform signaling to set up localized routing, the MIPv6 return routability test [RFC3775] is not suitable to authenticate associated signaling messages in PMIPv6. Solutions for localized routing in PMIPv6 need to mitigate, or to provide sufficient defense against, possible security threats. When PMIPv6 participants are administered within the same domain, infrastructure-based authorization mechanisms, such as IPsec, may be usable to protect signaling for localized routing.

由于MNs和CNs以外的网络实体执行信令以建立本地化路由,因此MIPv6返回路由能力测试[RFC3775]不适合验证PMIPv6中的相关信令消息。PMIPv6中的本地化路由解决方案需要缓解或提供足够的防御,以应对可能的安全威胁。当PMIPv6参与者在同一域内管理时,基于基础设施的授权机制(如IPsec)可用于保护本地化路由的信令。

Existing security associations according to [RFC5213] can be re-used to protect signaling for localized routing on the interface between a MAG and an LMA. In the case where a protocol solution for localized routing in PMIPv6 relies on protocol operation between MAGs, means for protection of signaling between these MAGs must be provided. The same applies for signaling on a possible protocol interface between two LMAs of the same domain.

根据[RFC5213]的现有安全关联可重新用于保护MAG和LMA之间接口上的本地化路由的信令。在PMIPv6中用于本地化路由的协议解决方案依赖于MAG之间的协议操作的情况下,必须提供用于保护这些MAG之间的信令的方法。这同样适用于相同域的两个lma之间的可能协议接口上的信令。

7. Acknowledgments
7. 致谢

Many aspects of the problem space for route optimization in PMIPv6 have been discussed in the context of a PMIPv6 Route Optimization Design Goals document, which was submitted to the NetLMM WG in November 2007. This group of contributors includes Sangjin Jeong, Christian Vogt, Ryuji Wakikawa, Marco Liebsch, Behcet Sarikaya, Shinta Sugimoto, Long Le, Alice Qinxia, and Jaehwoon Lee. Many thanks to Rajeev Koodli for his comments about the structure and scope of this problem statement for the NetExt WG.

在2007年11月提交给NetLMM工作组的PMIPv6路线优化设计目标文件中,讨论了PMIPv6路线优化问题空间的许多方面。这组撰稿人包括郑桑进、克里斯蒂安·沃格特、若川龙治、马可·列布希、白塞特·萨里卡亚、杉本真田、龙乐、爱丽丝·钦霞和李在焕。非常感谢Rajeev Koodli对NetExt工作组本问题陈述的结构和范围所作的评论。

This problem statement reflects the results of the discussion in the NetExt group. Many thanks to Hidetoshi Yokota, Carlos Bernardos, Ashutosh Dutta, Sri Gundavelli, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn, Dirk von Hugo, Frank Xia, Xiangsong Cui, and Basavaraj Patil for their comments and support to improve the quality of the problem statement.

此问题陈述反映了NetExt小组的讨论结果。非常感谢横田英寿、卡洛斯·贝尔纳多斯、阿什图什·杜塔、斯里·冈达维利、莫哈娜·杰亚塔兰、朱尼·科霍宁、格伦·佐恩、德克·冯·雨果、夏弗兰克、崔祥松和巴萨瓦拉伊·帕蒂尔为提高问题陈述的质量所作的评论和支持。

8. References
8. 工具书类
8.1. Normative References
8.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

[RFC5213]Gundavelli,S.,Ed.,Leung,K.,Devarapalli,V.,Chowdhury,K.,和B.Patil,“代理移动IPv6”,RFC 5213,2008年8月。

[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.

[RFC5844]Wakikawa,R.和S.Gundavelli,“代理移动IPv6的IPv4支持”,RFC 5844,2010年5月。

8.2. Informative References
8.2. 资料性引用

[PMIP6-LR] Zorn, G., Wu, Q., Liebsch, M., and J. Korhonen, "Diameter Support for Proxy Mobile IPv6 Localized Routing", Work in Progress, May 2011.

[PMIP6-LR]Zorn,G.,Wu,Q.,Liebsch,M.,和J.Korhonen,“代理移动IPv6本地化路由的Diameter支持”,正在进行的工作,2011年5月。

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

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

[RFC5779] Korhonen, J., Ed., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010.

[RFC5779]Korhonen,J.,Ed.,Bournelle,J.,Chowdhury,K.,Muhanna,A.,和U.Meyer,“Diameter代理移动IPv6:移动接入网关和本地移动锚与Diameter服务器的交互”,RFC 5779,2010年2月。

Authors' Addresses

作者地址

Marco Liebsch (editor) NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany

Marco Liebsch(编辑)NEC实验室欧洲NEC欧洲有限公司Kurfuersten Anlage 36 69115德国海德堡

   Phone: +49 6221 4342146
   EMail: liebsch@neclab.eu
        
   Phone: +49 6221 4342146
   EMail: liebsch@neclab.eu
        

Sangjin Jeong ETRI 218 Gajeongno, Yuseong Daejeon 305-700 Korea

Sangjin Jeong ETRI 218 Gajeongno,Yuseong Daejeon 305-700韩国

   Phone: +82 42 860 1877
   EMail: sjjeong@etri.re.kr
        
   Phone: +82 42 860 1877
   EMail: sjjeong@etri.re.kr
        

Qin Wu Huawei Technologies Co., Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China

中国南京雨花区软件大道101号秦武华为技术有限公司210012

   Phone: +86 25 56623633
   EMail: sunseawq@huawei.com
        
   Phone: +86 25 56623633
   EMail: sunseawq@huawei.com