Network Working Group J. Kempf, Ed.
Request for Comments: 3374 September 2002
Category: Informational
Network Working Group J. Kempf, Ed.
Request for Comments: 3374 September 2002
Category: Informational
Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network
问题描述：在IP访问网络中的节点之间执行上下文传输的原因
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 Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly. In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization, and Accounting (AAA), header compression, and Quality of Service (QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called "context transfer". This document discusses the desirability of context transfer for facilitating seamless IP mobility.
在支持主机移动性的IP接入网络中，主机和网络之间的路由路径可能频繁且快速地改变。在某些情况下，主机可能会在主机移动时留下的子网上建立某些上下文传输候选服务。此类服务的示例包括身份验证、授权和计费（AAA）、报头压缩和服务质量（QoS）。为了让主机在新的子网上获得这些服务，主机必须通过从头开始执行必要的信令流来明确地重新建立服务。在某些情况下，此过程会大大减慢在新子网上建立移动主机的过程。另一种方法是将与这些服务或上下文相关的现有状态的信息传输到新的子网，这一过程称为“上下文传输”。本文讨论了上下文传输促进无缝IP移动的可取性。
Table of Contents
目录
1.0 Introduction................................................2
2.0 Reference Definitions.......................................3
3.0 Scope of the Context Transfer Problem.......................3
4.0 The Need for Context Transfer...............................4
4.1 Fast Context Transfer-candidate Service Re-establishment....4
4.1.1 Authentication, Authorization, and Accounting (AAA).........4
4.1.2 Header Compression..........................................5
4.1.3 Quality of Service (QoS)....................................6
4.2 Interoperability............................................6
5.0 Limitations on Context Transfer.............................7
5.1 Router Compatibility........................................7
5.2 Requirement to Re-initialize Service from Scratch...........7
5.3 Suitability for the Particular Service......................7
5.4 Layer 2 Solutions Better....................................7
6.0 Performance Considerations..................................8
7.0 Security Considerations.....................................8
8.0 Recommendations.............................................9
9.0 Acknowledgements............................................9
10.0 References.................................................10
11.0 Complete List of Authors' Addresses........................12
12.0 Full Copyright Statement...................................14
1.0 Introduction................................................2
2.0 Reference Definitions.......................................3
3.0 Scope of the Context Transfer Problem.......................3
4.0 The Need for Context Transfer...............................4
4.1 Fast Context Transfer-candidate Service Re-establishment....4
4.1.1 Authentication, Authorization, and Accounting (AAA).........4
4.1.2 Header Compression..........................................5
4.1.3 Quality of Service (QoS)....................................6
4.2 Interoperability............................................6
5.0 Limitations on Context Transfer.............................7
5.1 Router Compatibility........................................7
5.2 Requirement to Re-initialize Service from Scratch...........7
5.3 Suitability for the Particular Service......................7
5.4 Layer 2 Solutions Better....................................7
6.0 Performance Considerations..................................8
7.0 Security Considerations.....................................8
8.0 Recommendations.............................................9
9.0 Acknowledgements............................................9
10.0 References.................................................10
11.0 Complete List of Authors' Addresses........................12
12.0 Full Copyright Statement...................................14
In networks where the hosts are mobile, the routing path through the network must often be changed in order to deliver the host's IP traffic to the new point of access. Changing the basic routing path is the job of a IP mobility protocol, such as Mobile IPv4 [1] and Mobile IPv6 [2]. But the success of real time services such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of the impact of this traffic redirection. In the process of establishing the new routing path, the nodes along the new path must be prepared to provide similar routing treatment to the IP packets as was provided along the old routing path.
In networks where the hosts are mobile, the routing path through the network must often be changed in order to deliver the host's IP traffic to the new point of access. Changing the basic routing path is the job of a IP mobility protocol, such as Mobile IPv4 [1] and Mobile IPv6 [2]. But the success of real time services such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of the impact of this traffic redirection. In the process of establishing the new routing path, the nodes along the new path must be prepared to provide similar routing treatment to the IP packets as was provided along the old routing path.translate error, please retry
In many cases, the routing treatment of IP packets within a network may be regulated by a collection of context transfer-candidate services that influence how packets for the host are treated. For example, whether a particular host has the right to obtain any routing at all out of the local subnet may depend on whether the host negotiated a successful AAA exchange with a network access server at some point in the past. Establishing these services initially results in a certain amount of related state within the network and requires a perhaps considerable amount of time for the protocol
在许多情况下，网络内IP分组的路由处理可由影响主机分组的处理方式的上下文传输候选服务的集合来调节。例如，特定主机是否有权从本地子网获得任何路由可能取决于主机是否在过去的某个时间点与网络访问服务器协商成功的AAA交换。建立这些服务最初会导致网络中出现一定数量的相关状态，并且协议可能需要相当长的时间
exchanges. If the host is required to re-establish those services by the same process as it uses to initially establish them, delay-sensitive real time traffic may be seriously impacted.
交流。如果主机需要通过与最初建立这些服务相同的过程重新建立这些服务，则延迟敏感的实时流量可能会受到严重影响。
An alternative is to transfer enough information on the context transfer-candidate service state, or context, to the new subnet so that the services can be re-established quickly, rather than require the mobile host to establish them from scratch. The transfer of service context may be advantageous in minimizing the impact of host mobility on, for example, AAA, header compression, QoS, policy, and possibly sub-IP protocols and services such as PPP. Context transfer at a minimum can be used to replicate the configuration information needed to establish the respective protocols and services. In addition, it may also provide the capability to replicate state information, allowing stateful protocols and services at the new node to be activated along the new path with less delay and less signaling overhead.
另一种方法是将有关上下文传输候选服务状态或上下文的足够信息传输到新子网，以便可以快速重新建立服务，而不是要求移动主机从头开始建立服务。服务上下文的传输在最小化主机移动性对例如AAA、报头压缩、QoS、策略以及可能的子IP协议和服务（例如PPP）的影响方面可能是有利的。上下文传输至少可用于复制建立相应协议和服务所需的配置信息。此外，它还可以提供复制状态信息的能力，允许新节点处的有状态协议和服务沿着新路径被激活，具有更少的延迟和更少的信令开销。
In this document, a case is made for why the Seamoby Working Group should investigate context transfer.
在本文件中，提出了Seamoby工作组为什么应该调查上下文转移的案例。
Context
上下文
The information on the current state of a service required to re-establish the service on a new subnet without having to perform the entire protocol exchange with the mobile host from scratch.
在新子网上重新建立服务而不必从头开始与移动主机进行整个协议交换所需的有关服务当前状态的信息。
Context Transfer
上下文转移
The movement of context from one router or other network entity to another as a means of re-establishing specific services on a new subnet or collection of subnets.
将上下文从一个路由器或其他网络实体移动到另一个路由器或其他网络实体，作为在新的子网或子网集合上重新建立特定服务的手段。
Context Transfer Candidate Service
上下文转移候选服务
A service that is a candidate for context transfer. In this document, only services that are concerned with the forwarding treatment of packets, such as QoS and security, or involve granting or denying the mobile host access to the network, such as AAA, are considered to be context transfer-candidate services.
作为上下文传输候选的服务。在本文档中，只有与数据包的转发处理有关的服务（例如QoS和安全性）或涉及允许或拒绝移动主机访问网络的服务（例如AAA）被视为上下文传输候选服务。
The context transfer problem examined in this document is restricted to re-establishing services for a mobile host that are, in some sense, related to the forwarding treatment of the mobile host's
本文中研究的上下文传输问题仅限于为移动主机重新建立服务，这些服务在某种意义上与移动主机数据的转发处理有关
packets or network access for the mobile host. It is not concerned with actually re-establishing routing information. Routing changes due to mobility are the domain of the IP mobility protocol. In addition, transfer of context related to application-level services, such as those associated with the mobile host's HTTP proxy, is also not considered in this document, although a generic context transfer protocol for transferring the context of services related to forwarding treatment or network access may also function for application-level services as well.
移动主机的数据包或网络访问。它与实际重新建立路由信息无关。由于移动性而引起的路由变化是IP移动性协议的领域。此外，本文件也不考虑与应用程序级服务相关的上下文传输，例如与移动主机HTTP代理相关的上下文传输，尽管用于传输与转发处理或网络访问相关的服务上下文的通用上下文传输协议也可用于应用级服务。
An important consideration in whether a service is a candidate for context transfer is whether it is possible to obtain a "correct" context transfer for the service in a given implementation and deployment, that is, one which will result in the same context at the new access router as would have resulted had the mobile host undergone a protocol exchange with the access router from scratch. For some services, the circumstances under which context transfer may result in correctness may be very limited [11].
服务是否是上下文传输的候选对象的一个重要考虑因素是，在给定的实现和部署中，是否可能获得服务的“正确”上下文传输，即，如果移动主机从头开始与接入路由器进行协议交换，将在新的接入路由器上产生相同的上下文。对于某些服务，上下文传输可能导致正确性的情况可能非常有限[11]。
There are two basic motivations for context transfer:
上下文转换有两个基本动机：
1) The primary motivation, as mentioned in the introduction, is the need to quickly re-establish context transfer-candidate services without requiring the mobile host to explicitly perform all protocol flows for those services from scratch.
1) 如引言中所述，主要动机是需要快速重新建立上下文传输候选服务，而无需移动主机从头显式地执行这些服务的所有协议流。
2) An additional motivation is to provide an interoperable solution that works for any Layer 2 radio access technology.
2) 另一个动机是提供适用于任何第2层无线接入技术的互操作解决方案。
These points are discussed in more detail in the following subsections.
以下小节将更详细地讨论这些要点。
As mentioned in the introduction, there are a variety of context transfer-candidate services that could utilize a context transfer solution. In this section, three representative services are examined. The consequences of not having a context transfer solution are examined as a means of motivating the need for such a solution.
如引言中所述，有多种上下文传输候选服务可以利用上下文传输解决方案。在本节中，将研究三种代表性服务。没有上下文转换解决方案的后果将被视为激发这种解决方案需求的一种手段。
One of the more compelling applications of context transfer is facilitating the re-authentication of the mobile host and re-establishment of the mobile host's authorization for network access in a new subnet by transferring the AAA context from the
上下文传输的一个更引人注目的应用是，通过从移动主机传输AAA上下文，促进移动主机的重新身份验证，并重新建立移动主机在新子网中的网络访问授权
mobile host's previous AAA server to another. This would allow the mobile host to continue access in the new subnet without having to redo an AAA exchange with the new subnet's AAA server. Naturally, a security association between the AAA servers is necessary so that the mobile host's sensitive authentication information can be securely transferred.
将移动主机的前一个AAA服务器连接到另一个服务器。这将允许移动主机在新子网中继续访问，而无需与新子网的AAA服务器重新进行AAA交换。当然，AAA服务器之间的安全关联是必要的，以便移动主机的敏感身份验证信息可以安全地传输。
In the absence of context transfer, there are two ways that can currently be used for AAA:
在没有上下文传输的情况下，目前有两种方式可用于AAA：
1) Layer 2 mechanisms, such as EAP [3] in PPP [4] or 802.1x [5] can be used to redo the initial protocol exchange, or possibly to update it. Currently, there is no general Layer 3 mechanism for conducting an AAA exchange between a host and an AAA server in the network.
1) 第2层机制，如PPP[4]或802.1x[5]中的EAP[3]可用于重做初始协议交换，或可能用于更新初始协议交换。目前，没有通用的第3层机制用于在网络中的主机和AAA服务器之间进行AAA交换。
2) If the mobile host is using Mobile IPv4 (but not Mobile IPv6 currently), the host can use the AAA registration keys [6] extension for Mobile IPv4 to establish a security association with the new Foreign Agent.
2) 如果移动主机正在使用移动IPv4（但当前不是移动IPv6），则主机可以使用移动IPv4的AAA注册密钥[6]扩展与新的外部代理建立安全关联。
Since 2) is piggybacked on the Mobile IPv4 signaling, the performance is less likely to be an issue, but 2) is not a general solution. The performance of 1) is likely to be considerably less than is necessary for maintaining good real time stream performance.
由于2）基于移动IPv4信令，性能不太可能成为问题，但2）不是通用解决方案。1）的性能可能大大低于保持良好实时流性能所需的性能。
In [7], protocols are described for efficient compression of IP headers to avoid sending large headers over low bandwidth radio network links. Establishing header compression generally requires from 1 to 4 exchanges between the last hop router and the mobile host with full or partially compressed headers before full compression is available. During this period, the mobile host will experience an effective reduction in the application-available bandwidth equivalent to the uncompressed header information sent over the air. Limiting the uncompressed traffic required to establish full header compression on a new last hop router facilitates maintaining adequate application-available bandwidth for real time streams, especially for IPv6 where the headers are larger.
在[7]中，描述了有效压缩IP报头的协议，以避免通过低带宽无线网络链路发送大报头。建立报头压缩通常需要在最后一跳路由器和移动主机之间进行1到4次交换，并使用完全或部分压缩的报头，然后才能进行完全压缩。在此期间，移动主机将经历应用程序可用带宽的有效减少，相当于通过空中发送的未压缩报头信息。限制在新的最后一跳路由器上建立完整报头压缩所需的未压缩流量有助于为实时流保持足够的应用程序可用带宽，特别是对于报头较大的IPv6。
Context transfer can help in this case by allowing the network entity performing header compression, usually the last hop router, to transfer the header compression context to the new router. The timing of context transfer must be arranged so that the header context is transferred from the old router as soon as the mobile host
在这种情况下，上下文传输可以帮助执行头压缩的网络实体（通常是最后一跳路由器）将头压缩上下文传输到新路由器。必须安排上下文传输的时间，以便在移动主机启动后立即从旧路由器传输报头上下文
is no longer receiving packets through the old router, and installed on the new router before any packets are delivered to or forwarded from the mobile host.
不再通过旧路由器接收数据包，并在任何数据包发送到移动主机或从移动主机转发之前安装在新路由器上。
Significant QoS protocol exchanges between the mobile host and routers in the network may be required in order to establish the initial QoS treatment for a mobile host's packets. The exact mechanism whereby QoS for a mobile host should be established is currently an active topic of investigation in the IETF. For existing QoS approaches (Diffsrv and Intsrv) preliminary studies have indicated that the protocol flows necessary to re-establish QoS in a new subnet from scratch can be very time consuming for Mobile IP, and other mobility protocols may suffer as well.
为了为移动主机的分组建立初始QoS处理，可能需要在移动主机和网络中的路由器之间进行显著的QoS协议交换。为移动主机建立QoS的确切机制目前是IETF中一个活跃的研究主题。对于现有的QoS方法（Diffsrv和Intsrv），初步研究表明，从头开始在新子网中重新建立QoS所需的协议流对于移动IP来说可能非常耗时，并且其他移动协议也可能受到影响。
A method of transferring the mobile host's QoS context from the old network to the new could facilitate faster re-establishment of the mobile host's QoS treatment on the new subnet. However, for QoS mechanisms that are end-to-end, transferring context at the last hop router may be insufficient to completely re-initialize the mobile host's QoS treatment, since some number of additional routers in the path between the mobile host and corresponding node may also need to be involved.
将移动主机的QoS上下文从旧网络传输到新网络的方法可以促进在新子网上更快地重新建立移动主机的QoS处理。然而，对于端到端的QoS机制，在最后一跳路由器处传输上下文可能不足以完全重新初始化移动主机的QoS处理，因为移动主机和相应节点之间的路径中可能还需要涉及一些额外的路由器。
A particular concern for seamless handover is that different Layer 2 radio protocols may define their own solutions for context transfer. There are ongoing efforts within 3GPP [8] and IEEE [9] to define such solutions. These solutions are primarily designed to facilitate the transfer of Layer 2-related context over a wired IP network between two radio access networks or two radio access points. However, the designs can include extensibility features that would allow Layer 3 context to be transferred. Such is the case with [10], for example.
无缝切换的一个特别关注点是，不同的第2层无线协议可能会为上下文传输定义自己的解决方案。3GPP[8]和IEEE[9]正在努力定义此类解决方案。这些解决方案主要设计用于促进在两个无线接入网络或两个无线接入点之间通过有线IP网络传输与第2层相关的上下文。但是，这些设计可以包括允许传输第3层上下文的可扩展性特性。例如[10]就是这样。
If Layer 2 protocols were to be widely adopted as an optimization measure for Layer 3 context transfer, seamless mobility of a mobile host having Layer 2 network interfaces that support multiple radio protocols would be difficult to achieve. Essentially, a gateway or translator between Layer 2 protocols would be required, or the mobile host would be required to perform a full re-initialization of its context transfer-candidate services on the new radio network, if no translator were available, in order to hand over a mobile host between two access technologies.
如果第2层协议被广泛采用作为第3层上下文传输的优化措施，那么具有支持多个无线电协议的第2层网络接口的移动主机的无缝移动性将难以实现。基本上，将需要第2层协议之间的网关或转换器，或者如果没有可用的转换器，则移动主机将需要在新的无线网络上执行其上下文传输候选服务的完全重新初始化，以便在两种接入技术之间移交移动主机。
A general Layer 3 context transfer solution may also be useful for Layer 2 protocols that do not define their own context transfer protocol. Consideration of this issue is outside the scope of the Seamoby Working Group, however, since it depends on the details of the particular Layer 2 protocol.
一般的第3层上下文传输解决方案对于没有定义自己的上下文传输协议的第2层协议也很有用。然而，对这一问题的审议不属于Seamoby工作组的范围，因为它取决于特定的第2层议定书的细节。
Context transfer may not always be the best solution for re-establishing context transfer-candidate services on a new subnet. There are certain limitations on when context transfer may be useful. These limitations are discussed in the following subsections.
对于在新子网上重新建立上下文传输候选服务，上下文传输可能并不总是最佳的解决方案。上下文转移何时有用有一定的限制。以下小节将讨论这些限制。
Context transfer between two routers is possible only if the receiving router supports the same context transfer-candidate services as the sending router. This does not mean that the two nodes are identical in their implementation, nor does it even imply that they must have identical capabilities. A router that cannot make use of received context should refuse the transfer. This results in a situation no different than a mobile host handover without context transfer, and should not be considered an error or failure situation.
只有当接收路由器支持与发送路由器相同的上下文传输候选服务时，两个路由器之间的上下文传输才是可能的。这并不意味着这两个节点的实现是相同的，甚至也不意味着它们必须具有相同的功能。无法使用接收到的上下文的路由器应拒绝传输。这导致的情况与没有上下文传输的移动主机切换没有什么不同，因此不应将其视为错误或失败情况。
The primary motivation for context transfer assumes that quickly re-establishing the same level of context transfer-candidate service on the new subnet is desirable. And yet, there may be situations where either the device or the access network would prefer to re-establish or re-negotiate the level of service. For example, if the mobile host crosses administrative domains where the operational policies change, negotiation of a different level of service may be required.
上下文传输的主要动机是假设需要在新子网上快速重新建立相同级别的上下文传输候选服务。然而，可能存在设备或接入网络希望重新建立或重新协商服务级别的情况。例如，如果移动主机跨越操作策略改变的管理域，则可能需要协商不同级别的服务。
Context transfer assumes that it is faster to establish the service by context transfer rather than from scratch. This may not be true for certain types of service, for example, multicast, "push" information services.
上下文传输假定通过上下文传输而不是从头开始建立服务更快。对于某些类型的服务，例如多播、“推送”信息服务，情况可能并非如此。
Context transfer is an enhancement to improve upon the performance of a handover for Layer 3 context transfer-candidate services. Many networks provide support for handover at Layer 2, within and between
上下文传输是一种增强，用于改善第3层上下文传输候选服务的切换性能。许多网络在第2层、内部和之间提供切换支持
subnets. Layer 3 context transfer may not provide a significant improvement over Layer 2 solutions, even for Layer 3 context, if the handover is occurring between two subnets supporting the same Layer 2 radio access technology.
子网。如果切换发生在支持相同第2层无线接入技术的两个子网之间，则第3层上下文传输可能不会比第2层解决方案提供显著的改进，即使对于第3层上下文也是如此。
The purpose of context transfer is to sustain the context transfer-candidate services being provided to a mobile host's traffic during handover. It is essentially an enhancement to IP mobility that ultimately must result in an improvement in handover performance. A context transfer solution must provide performance that is equal to or better than re-initializing the context transfer-candidate service between the mobile host and the network from scratch. Otherwise, context transfer is of no benefit.
上下文传输的目的是维持在切换期间向移动主机的业务提供的上下文传输候选服务。它本质上是对IP移动性的增强，最终必须提高切换性能。上下文传输解决方案必须提供等同于或优于从头开始重新初始化移动主机和网络之间的上下文传输候选服务的性能。否则，上下文转换将毫无益处。
Any context transfer standard must provide mechanism for adequately securely the context transfer process, and a recommendation to deploy security, as is typically the case for Internet standards. Some general considerations for context transfer security include:
任何上下文传输标准都必须提供足够安全的上下文传输过程的机制，以及部署安全性的建议，这通常是互联网标准的情况。上下文传输安全的一些一般注意事项包括：
- Information privacy: the context may contain information which the end user or network operator would prefer to keep hidden from unauthorized viewers.
- 信息隐私：上下文可能包含最终用户或网络运营商希望对未经授权的观众隐藏的信息。
- Transfer legitimacy: a false or purposely corrupted context transfer could have a severe impact upon the operation of the receiving router, and therefore could potentially affect the operation of the access network itself. The potential threats include denial of service and theft of service attacks.
- 传输合法性：错误或故意损坏的上下文传输可能会对接收路由器的操作产生严重影响，因此可能会影响访问网络本身的操作。潜在威胁包括拒绝服务和窃取服务攻击。
- Security preservation: part of the context transfer may include information pertinent to a security association established between the mobile host and another entity on the network. For this security association to be preserved during handover, the transfer of the security context must include the appropriate security measures.
- 安全保护：上下文传输的一部分可能包括与移动主机和网络上另一实体之间建立的安全关联相关的信息。为了在移交期间保留此安全关联，安全上下文的传输必须包括适当的安全措施。
It is expected that the measures used to secure the transport of information between peers (e.g., IPSEC [10]) in an IP network should be sufficient for context transfer. However, given the above considerations, there may be reason to provide for additional security measures beyond the available IETF solutions.
预计用于保护IP网络中对等方（例如IPSEC[10]）之间信息传输的措施应足以进行上下文传输。然而，鉴于上述考虑，可能有理由在现有IETF解决方案之外提供额外的安全措施。
Since context transfer requires a trust relationship between network entities, the compromise of only one of the network entities that transfer context may be sufficient to reduce the security of the whole system, if for example the context transferred includes encryption keying material. When the host moves from the compromised network entity to an uncompromised network entity in the presence of context transfer, the compromised context may be used to decrypt the communication channel. When context transfer is not used, a compromise of only one network entity only gives access to what that network entity can see. When the mobile host moves to an uncompromised network entity in the absence of context transfer, security can be re-established at the new entity. However, to the extent that context transfer happens primarily between routers, the security of context transfer will depend on the security of the routers. Any compromise of security on a router that affects context transfer may also lead to other, equally serious disruptions in network traffic.
由于上下文传输需要网络实体之间的信任关系，因此仅传输上下文的网络实体之一的妥协可能足以降低整个系统的安全性，如果例如传输的上下文包括加密密钥材料。当主机在存在上下文传输的情况下从受损网络实体移动到未受损网络实体时，受损上下文可用于解密通信信道。当不使用上下文传输时，只有一个网络实体的折衷只允许访问该网络实体可以看到的内容。当移动主机在没有上下文传输的情况下移动到一个不妥协的网络实体时，可以在新实体上重新建立安全性。然而，由于上下文传输主要发生在路由器之间，因此上下文传输的安全性将取决于路由器的安全性。路由器上影响上下文传输的任何安全隐患也可能导致其他同样严重的网络流量中断。
The context transfer investigation must identify any novel security measures required for context transfer that exceed the capabilities of the existing or emerging IETF solutions.
上下文传输调查必须确定上下文传输所需的超出现有或新兴IETF解决方案能力的任何新的安全措施。
The following steps are recommended for Seamoby:
建议Seamoby执行以下步骤：
- Investigation into candidate router-related services for context and an analysis of the transfer requirements for each candidate;
- 针对上下文对候选路由器相关服务进行调查，并分析每个候选路由器的传输需求；
- The development of a framework and protocol(s) that will support the transfer of context between the routing nodes of an IP network.
- 支持IP网络路由节点之间上下文传输的框架和协议的开发。
The context transfer solution must inter-work with existing and emerging IP protocols, in particular, those protocols supporting mobility in an IP network.
上下文传输解决方案必须与现有和新兴的IP协议相互协作，特别是那些支持IP网络中移动性的协议。
The editor would like to thank the Seamoby CT design team (listed at the end of the document as co-authors), who were largely responsible for the initial content of this document, for their hard work, and especially Gary Kenward, who shepherded the document through its initial versions.
编辑要感谢Seamoby CT设计团队（作为合著者列在文件末尾），他们主要负责本文件的初始内容，感谢他们的辛勤工作，特别是Gary Kenward，他指导了本文件的初始版本。
[1] Perkins, C., "IP Mobility Support", RFC 3220, January 2002.
[1] Perkins，C.，“IP移动支持”，RFC 3220，2002年1月。
[2] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[2] Johnson，D.和C.Perkins，“IPv6中的移动支持”，正在进行中。
[3] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[3] Blunk，L.和Vollbrecht，J.，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[4] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[5] IEEE Std. P802.1X/D11, "Standard for Port based Network Access Control", March 2001.
[5] IEEE标准P802.1X/D11，“基于端口的网络访问控制标准”，2001年3月。
[6] Perkins, C., and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress.
[6] Perkins，C.和P.Calhoun，“移动IP的AAA注册密钥”，正在进行中。
[7] Borman, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren T., Le, K., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[7] Borman，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L.，Hakenberg，R.，Koren T.，Le，K.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[8] 3GPP TR 25.936 V4.0.0, "Handovers for Real Time Services from PS Domain," 3GPP, March 2001.
[8] 3GPP TR 25.936 V4.0.0，“PS域实时服务的切换”，3GPP，2001年3月。
[9] IEEE Std. 802.11f/D2.0, "Draft Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," July 2001.
[9] IEEE标准802.11f/D2.0，“通过支持IEEE 802.11运行的配电系统间接入点协议实现多供应商接入点互操作性的推荐规程草案”，2001年7月。
[10] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[10] Kent，S.和Atkinson，R.，“互联网协议的安全架构”，RFC 2401，1998年11月。
[11] Aboba, B. and M. Moore, "A Model for Context Transfer in IEEE 802", Work in Progress.
[11] Aboba，B.和M.Moore，“IEEE 802中的上下文传输模型”，正在进行中。
O. Henrik Levkowetz A Brand New World Osterogatan 1 S-164 28 Kista SWEDEN
O.Henrik Levkowetz全新世界Osterogatan 1 S-164 28瑞典基斯塔
Phone: +46 8 477 9942
EMail: henrik@levkowetz.com
Phone: +46 8 477 9942
EMail: henrik@levkowetz.com
Pat R. Calhoun Black Storm Networks 110 Nortech Parkway San Jose CA 95134 USA
Pat R.Calhoun Black Storm Networks美国加利福尼亚州圣何塞Nortech Parkway 110号，邮编95134
Phone: +1 408-941-0500
EMail: pcalhoun@bstormnetworks.com
Phone: +1 408-941-0500
EMail: pcalhoun@bstormnetworks.com
James Kempf NTT DoCoMo USA Laboratories 181 Metro Drive, Suite 300 San Jose, CA 95110 USA
詹姆斯·肯普夫NTT DoCoMo美国实验室美国加利福尼亚州圣何塞市地铁路181号300室95110
Phone: 408-451-4711 EMail: kempf@docomolabs-usa.com
电话：408-451-4711电子邮件：kempf@docomolabs-美国网
Gary Kenward Nortel Networks 3500 Carling Avenue Nepean, Ontario K2G 6J8 CANADA
Gary Kenward Nortel Networks加拿大安大略省内皮恩卡林大道3500号K2G 6J8
Phone: +1 613-765-1437
EMail: gkenward@nortelnetworks.com
Phone: +1 613-765-1437
EMail: gkenward@nortelnetworks.com
Hamid Syed Nortel Networks 100 Constellation Crescent Nepean Ontario K2G 6J8 CANADA
哈米德赛德北电网络100星座月牙形尼泊尔安大略省K2G 6J8加拿大
Phone: +1 613 763-6553
EMail: hmsyed@nortelnetworks.com
Phone: +1 613 763-6553
EMail: hmsyed@nortelnetworks.com
Jukka Manner Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki FINLAND
尤卡态度赫尔辛基大学计算机科学系P.O盒26（TeulLuuukkutu 23）FIF-000 014赫尔辛基芬兰
Phone: +358-9-191-44210
EMail: jmanner@cs.helsinki.fi
Phone: +358-9-191-44210
EMail: jmanner@cs.helsinki.fi
Madjid Nakhjiri Motorola 1501 West Shure Drive Arlington Heights IL 60004 USA
Madjid Nakhjiri摩托罗拉1501西舒尔大道美国伊利诺伊州阿灵顿高地60004
Phone: +1 847-632-5030
EMail: madjid.nakhjiri@motorola.com
Phone: +1 847-632-5030
EMail: madjid.nakhjiri@motorola.com
Govind Krishnamurthi Communications Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington MA 01803 USA
美国马萨诸塞州伯灵顿路5号诺基亚研究中心Govind Krishnamurthi通信系统实验室邮编：01803
Phone: +1 781 993 3627
EMail: govind.krishnamurthi@nokia.com
Phone: +1 781 993 3627
EMail: govind.krishnamurthi@nokia.com
Rajeev Koodli Communications Systems Lab, Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
Rajeev Koodli通信系统实验室，诺基亚研究中心313 Fairchild Drive Mountain View加利福尼亚94043
Phone: +1 650 625 2359
EMail: rajeev.koodli@nokia.com
Phone: +1 650 625 2359
EMail: rajeev.koodli@nokia.com
Kulwinder S. Atwal Zucotto Wireless Inc. Ottawa Ontario K1P 6E2 CANADA
加拿大安大略省渥太华Kulwinder S.Atwal Zucotto Wireless Inc.K1P 6E2
Phone: +1 613 789 0090
EMail: kulwinder.atwal@zucotto.com
Phone: +1 613 789 0090
EMail: kulwinder.atwal@zucotto.com
Michael Thomas Cisco Systems 375 E Tasman Rd San Jose CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼东路375号迈克尔·托马斯·思科系统公司95134
Phone: +1 408 525 5386
EMail: mat@cisco.com
Phone: +1 408 525 5386
EMail: mat@cisco.com
Mat Horan COM DEV Wireless Group San Luis Obispo CA 93401 USA
Mat Horan通信发展无线集团美国加州圣路易斯奥比斯波93401
Phone: +1 805 544 1089
EMail: mat.horan@comdev.cc
Phone: +1 805 544 1089
EMail: mat.horan@comdev.cc
Phillip Neumiller 3Com Corporation 1800 W. Central Road Mount Prospect IL 60056 USA
Phillip Neumiller 3Com Corporation 1800美国伊利诺伊州中部公路西侧Mount Prospect 60056
EMail: phil_neumiller@3com.com
EMail: phil_neumiller@3com.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。