Network Working Group                                    H. Chaskar, Ed.
Request for Comments: 3583                         Nokia Research Center
Category: Informational                                   September 2003
        
Network Working Group                                    H. Chaskar, Ed.
Request for Comments: 3583                         Nokia Research Center
Category: Informational                                   September 2003
        

Requirements of a Quality of Service (QoS) Solution for Mobile IP

移动IP服务质量(QoS)解决方案的要求

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 (2003). All Rights Reserved.

版权所有(C)互联网协会(2003年)。版权所有。

Abstract

摘要

Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP.

移动IP确保在移动节点更改其与Internet的连接点时将数据包正确路由到移动节点。然而,还需要在网络中的中间节点处向移动节点的分组流提供适当的服务质量(QoS)转发处理,以便可以通过移动IP支持QoS敏感的IP服务。本文档描述了对IP QoS机制的要求,以使其在移动IP中能够令人满意地运行。

Table of Contents

目录

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Problem Statement. . . . . . . . . . . . . . . . . . . .  2
       1.2.  An approach for solving QoS problem in Mobile IP . . . .  3
   2.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Requirements of a QoS solution for Mobile IP . . . . . . . . .  3
       3.1.  Performance requirements . . . . . . . . . . . . . . . .  4
       3.2.  Interoperability requirements. . . . . . . . . . . . . .  5
       3.3.  Miscellaneous requirements . . . . . . . . . . . . . . .  6
       3.4.  Standard requirements. . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  7
   5.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       7.1.  Normative References . . . . . . . . . . . . . . . . . .  8
       7.2.  Informative References . . . . . . . . . . . . . . . . .  8
   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Problem Statement. . . . . . . . . . . . . . . . . . . .  2
       1.2.  An approach for solving QoS problem in Mobile IP . . . .  3
   2.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Requirements of a QoS solution for Mobile IP . . . . . . . . .  3
       3.1.  Performance requirements . . . . . . . . . . . . . . . .  4
       3.2.  Interoperability requirements. . . . . . . . . . . . . .  5
       3.3.  Miscellaneous requirements . . . . . . . . . . . . . . .  6
       3.4.  Standard requirements. . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  7
   5.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       7.1.  Normative References . . . . . . . . . . . . . . . . . .  8
       7.2.  Informative References . . . . . . . . . . . . . . . . .  8
   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
        
1. Introduction
1. 介绍

Mobile IP is a technology that allows a "mobile node" (MN) to change its point of attachment to the Internet while communicating with the "correspondent node" (CN) using IP. The formal description of Mobile IP can be found in [1, 6]. Mobile IP primarily addresses the correct routing of packets to MN's current point of attachment with the Internet.

移动IP是一种允许“移动节点”(MN)在使用IP与“对应节点”(CN)通信的同时更改其与Internet的连接点的技术。移动IP的形式描述见[1,6]。移动IP主要解决将数据包正确路由到MN与Internet的当前连接点的问题。

It is also essential to provide proper Quality of Service (QoS) forwarding treatment to the packets sent by or destined to MN as they propagate along different routes in the network due to node mobility. This document will identify the requirements that Mobile IP places on an IP QoS mechanism.

由于节点的移动性,当数据包在网络中沿不同的路由传播时,还必须向由MN发送或目的地为MN的数据包提供适当的服务质量(QoS)转发处理。本文档将确定移动IP对IP QoS机制的要求。

1.1. Problem Statement
1.1. 问题陈述

When an MN using Mobile IP undergoes handover from one access router to another, the path traversed by MN's packet stream in the network may change. Such a change may be limited to a small segment of the end-to-end path near the extremity, or it could also have an end-to-end impact. Further, the packets belonging to MN's ongoing session may start using a new care-of address after handover. Hence, they may not be recognized by some forwarding functions in the nodes even along that segment of the end-to-end path that remains unaltered after handover. Finally, handover may occur between the subnets that are under different administrative control.

当使用移动IP的MN经历从一个接入路由器到另一个接入路由器的切换时,由MN的分组流在网络中穿过的路径可能改变。这种变化可能仅限于靠近末端的端到端路径的一小段,也可能产生端到端的影响。此外,属于MN的正在进行的会话的分组可以在切换后开始使用新的转交地址。因此,即使沿着在切换后保持不变的端到端路径段,节点中的一些转发功能也可能无法识别它们。最后,在不同管理控制下的子网之间可能发生切换。

In the light of this scenario, it is essential to establish proper QoS support for the MN's packet stream along the new packet path.

鉴于这种情况,必须沿新的分组路径为MN的分组流建立适当的QoS支持。

1.2. An approach for solving the QoS problem in Mobile IP
1.2. 一种解决移动IP中QoS问题的方法

There are four important steps involved in solving the QoS problem for Mobile IP. They are as follows: (1) List the requirements that Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS solutions against these requirements, (3) Decide if current solutions need to be extended, or if new ones need to be defined, and (4) Depending on the result of step 3, define new solutions or fix the old ones.

解决移动IP的QoS问题涉及四个重要步骤。它们如下:(1)列出移动IP对QoS机制的要求,(2)根据这些要求评估当前的IP QoS解决方案,(3)决定当前的解决方案是否需要扩展,或者是否需要定义新的解决方案,以及(4)根据第3步的结果,定义新的解决方案或修复旧的解决方案。

Of these, the first step, i.e., the requirements step, is addressed in this document. The last three steps are not dealt with here in detail. However, so as to create useful insight into the Mobile IP QoS problem, at times this document highlights the shortcomings of some well known current proposals for establishing QoS support for the packet stream in the network, when directly used with Mobile IP.

其中,第一步,即需求步骤,在本文件中进行了说明。最后三个步骤在这里不作详细介绍。然而,为了对移动IP QoS问题产生有用的见解,本文档有时强调了一些众所周知的当前建议的缺点,这些建议用于在网络中直接与移动IP一起使用时建立对分组流的QoS支持。

2. 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 BCP 14, RFC 2119 [2].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。

3. Requirements of a QoS solution for Mobile IP
3. 移动IP的QoS解决方案需求

This section describes the requirements for a QoS solution for its satisfactory operation with Mobile IP. Conversely, note that only Mobile IP-specific requirements are described here. We do not assume any particular version (4 or 6) of IP while describing the requirements. Solutions can be designed for IPv4 and IPv6 independently, or a single solution can be designed to work with both versions.

本节描述了QoS解决方案的要求,以使其能够在移动IP上满意地运行。相反,请注意,此处仅描述了特定于移动IP的要求。在描述需求时,我们不假设IP的任何特定版本(4或6)。可以为IPv4和IPv6独立设计解决方案,也可以为两个版本设计单个解决方案。

In this document, we assume that the target access router for MN's handover is already pinned down by other protocols. For example, Seamoby working group has started work on the candidate access router discovery protocols [7]. Thus, any QoS-capability specific negotiations that may affect the handover decision are outside the scope of QoS solution as such, rather need to be performed by candidate and target access router selection protocols.

在本文中,我们假设用于MN切换的目标接入路由器已经被其他协议锁定。例如,Seamoby工作组已经开始研究候选访问路由器发现协议[7]。因此,可能影响切换决策的任何QoS能力特定的协商本身不在QoS解决方案的范围内,而是需要由候选和目标接入路由器选择协议执行。

3.1. Performance requirements
3.1. 性能要求

1. Minimize the interruption in QoS at the time of handover:

1. 将切换时的QoS中断降至最低:

At the time of handover, interruption in QoS would occur if the packets sent by or destined to the MN arrive at the intermediate node in the new packet path without that node having information about their QoS forwarding requirement. Then, those packets will receive default forwarding treatment. Such QoS interruption MUST be minimized. A good metric for this performance is the number of packets that may potentially get served with the "default" QoS at the time of handover. The number of such packets MUST be minimized.

在切换时,如果由MN发送或目的地为MN的分组到达新分组路径中的中间节点,而该节点没有关于其QoS转发需求的信息,则QoS将发生中断。然后,这些数据包将接受默认的转发处理。这种QoS中断必须最小化。这种性能的一个好指标是在切换时可能获得“默认”QoS服务的数据包数量。此类数据包的数量必须最小化。

As an example, this performance metric is computed in [8] for the case of end-to-end RSVP signaling [3] with Mobile IPv6. It is shown there that when the end-to-end path of packets changes at large after handover or when the care-of address changes after handover, OPWA (One Pass With Advertisement) model of reservation used by RSVP causes the latency of about one round-trip time between the MN and the CN before QoS can be established along the new packet path. In other words, the packets using the new care-of address that would be released by the MN or the CN during one round-trip time, after these nodes are ready to use the new care-of address, may get default forwarding treatment at the intermediate nodes. Such a latency in QoS programming may be acceptable at the time of session initiation, but it is not acceptable in the middle of an active session as would be the case with handover.

例如,对于使用移动IPv6的端到端RSVP信令[3],在[8]中计算了该性能度量。这里表明,当分组的端到端路径在切换后大幅度改变时,或者当转交地址在切换后改变时,RSVP使用的OPWA(带广告的一次传递)预约模型导致MN和CN之间大约一个往返时间的延迟,然后才能沿新分组路径建立QoS。换句话说,在这些节点准备好使用新的转交地址之后,使用将由MN或CN在一个往返时间内释放的新转交地址的分组可以在中间节点处获得默认转发处理。在会话启动时,QoS编程中的这样的延迟可能是可接受的,但是在活动会话的中间,与切换的情况一样,这是不可接受的。

2. Localize the QoS (re)establishment to the affected parts of the packet path in the network:

2. 将QoS(重新)建立本地化到网络中数据包路径的受影响部分:

In many cases, handover changes only a small segment of the end-to-end path of MN's packet stream near the extremity. Then, the QoS mechanism MUST limit the extent of QoS (re)establishment to the affected segment of the end-to-end path only.

在许多情况下,切换仅改变靠近末端的MN分组流的端到端路径的一小部分。然后,QoS机制必须将QoS(重新)建立的范围仅限于端到端路径的受影响段。

However, note that handover may sometimes cause the end-to-end path of MN's packet stream in the network to change at large. This may happen, for example, in the case of handover between different administrative domains. If the QoS mechanism used to establish QoS support for the MN's packet stream along the new packet path in the network is based on the explicit end-to-end provisioning as such, it MUST perform so at the time of such handover.

然而,请注意,切换有时可能导致网络中MN的分组流的端到端路径普遍改变。例如,在不同管理域之间进行切换时,可能会发生这种情况。如果用于沿网络中的新分组路径为MN的分组流建立QoS支持的QoS机制基于这样的显式端到端供应,则其必须在这种切换时执行。

When the care-of address changes upon handover, it may be required to perform some signaling even over the unchanged part of the end-to-end path if the path contains any QoS mechanisms that use IP address as a key to forwarding functions. Examples are FILTER SPECs in the IntServ nodes or packet classifiers at the edges of DiffServ networks. However, double provisioning of resources over the unchanged part of the packet path MUST be avoided.

当转交地址在切换时改变时,如果路径包含使用IP地址作为转发功能密钥的任何QoS机制,则可能需要在端到端路径的未改变部分上执行一些信令。例如,IntServ节点中的过滤器规格或DiffServ网络边缘的数据包分类器。但是,必须避免在数据包路径的未更改部分重复提供资源。

Note that the QoS signaling protocol such as RSVP [9] can localize the QoS signaling to the affected parts of the end-to-end path if the care-of address does not change upon handover. However, if the care-of address changes upon handover, RSVP as currently defined [4] fails to localize the QoS signaling. In addition, it will cause double reservations on the part of end-to-end path that remains unchanged after handover.

注意,如果转交地址在切换时没有改变,诸如RSVP[9]之类的QoS信令协议可以将QoS信令定位到端到端路径的受影响部分。然而,如果转交地址在切换时发生变化,则当前定义的RSVP[4]无法定位QoS信令。此外,这将导致端到端路径在切换后保持不变的部分出现双重保留。

3. Releasing after handover the QoS state (if any) along the old packet path:

3. 切换后沿旧数据包路径释放QoS状态(如果有):

The QoS mechanism MUST provide some means (explicit or timer-based) to release any QoS state along the old packet path that is not required after handover. It is desirable that the unwarranted QoS states, if any, along the old path are released as quickly as possible at the time of handover. Note that, during handover, the MN may not always get a chance to send explicit tear down message along the old path because of the loss of link layer connectivity with the old access router.

QoS机制必须提供一些方法(显式或基于计时器)来释放旧数据包路径上的任何QoS状态,这在切换后是不需要的。希望在切换时尽快释放沿着旧路径的不必要的QoS状态(如果有的话)。注意,在切换期间,由于失去与旧接入路由器的链路层连接,MN可能并不总是有机会沿着旧路径发送明确的中断消息。

3.2. Interoperability requirements
3.2. 互操作性要求

1. Interoperability with mobility protocols:

1. 与移动协议的互操作性:

A number of mobility protocols that are complementary to Mobile IP are already defined or may be defined in future in IETF, particularly in Mobile IP and Seamoby working groups. Examples are fast handover [10, 11], localized mobility management [12, 13], context transfer [5] etc. The QoS mechanism for Mobile IP SHOULD take advantage of these mobility protocols for the optimized operation. However, the QoS scheme MUST have provisions to accomplish its tasks even if one or more of these mobility protocols are not used.

在IETF中,特别是在移动IP和Seamoby工作组中,已经定义或可能在将来定义了许多补充移动IP的移动协议。例如快速切换[10,11]、本地化移动性管理[12,13]、上下文传输[5]等。移动IP的QoS机制应利用这些移动性协议进行优化操作。然而,即使不使用一个或多个移动协议,QoS方案也必须具有完成其任务的规定。

2. Interoperability with heterogeneous packet paths as regards QoS paradigms:

2. 在QoS范例方面与异构数据包路径的互操作性:

The new path after handover, of the MN's packet stream, may traverse network domains employing different QoS paradigms compared to those along the old path. The QoS mechanism for

切换后的MN的分组流的新路径可以穿越采用与沿着旧路径的路径相比的不同QoS范式的网络域。网络的QoS机制

Mobile IP SHOULD be able to establish proper QoS forwarding treatment for the MN's packet stream along the packet paths deploying different QoS paradigms (best current practices), in a manner consistent with the QoS mechanism deployed along those paths.

移动IP应当能够以与沿那些路径部署的QoS机制一致的方式,沿着部署不同QoS范式(最佳当前实践)的分组路径为MN的分组流建立适当的QoS转发处理。

As an illustration, suppose that the MN is currently attached to an access router which is the edge router of a DiffServ network, and that the packet classifier and traffic policer for the MN's flows are presently programmed in this access router. Now, suppose that the MN needs to be handed over to the access router which is at the edge of an IntServ network. The new access network would expect the exchange of RSVP messages so that proper QoS forwarding treatment can be established for the MN's packet stream in that access network. QoS mechanism for Mobile IP SHOULD have provisions to handle such heterogeneity as regards the QoS mechanisms deployed along different packet paths.

作为说明,假设MN当前连接到作为DiffServ网络的边缘路由器的接入路由器,并且用于MN的流的分组分类器和业务策略当前被编程在该接入路由器中。现在,假设MN需要移交给位于IntServ网络边缘的接入路由器。新的接入网络将期望RSVP消息的交换,以便可以在该接入网络中为MN的分组流建立适当的QoS转发处理。移动IP的QoS机制应具有处理沿不同分组路径部署的QoS机制的这种异构性的规定。

3.3. Miscellaneous requirements
3.3. 杂项要求

1. QoS support along multiple packet paths:

1. 沿多个数据包路径提供QoS支持:

After MN undergoes handover from one access router to another, potentially, there could be multiple paths over which MN's packet may propagate. Examples of these path are: route-optimized path between the MN and its CN, triangle route via Home Agent (HA), temporary tunnel between old and new access routers, reverse tunnel from the new access router (Foreign Agent) to HA etc. A QoS mechanism SHOULD be able to support QoS along the different potential packet paths. However, whether all paths are supported or only a subset of them is supported will be determined by external mechanisms such as mobility management, policy, location privacy requirement and so on. Further, the same QoS mechanism may not be able to support all these paths.

在MN经历从一个接入路由器到另一个接入路由器的切换之后,可能存在多条路径,MN的数据包可以在这些路径上传播。这些路径的示例包括:MN与其CN之间的路由优化路径、通过归属代理(HA)的三角形路由、新旧接入路由器之间的临时隧道、从新接入路由器(外部代理)到HA的反向隧道等。QoS机制应能支持沿不同潜在分组路径的QoS。然而,是否支持所有路径或仅支持其中的一个子集将由外部机制(如移动性管理、策略、位置隐私要求等)确定。此外,相同的QoS机制可能无法支持所有这些路径。

2. Interactions with wireless link-layer support for QoS:

2. 与支持QoS的无线链路层的交互:

Since a vast number of devices using Mobile IP will be connected to the Internet via wireless links, the QoS mechanism for Mobile IP MAY provide some information to the wireless link layers for them to support the required QoS.

由于大量使用移动IP的设备将通过无线链路连接到因特网,因此移动IP的QoS机制可以向无线链路层提供一些信息,以支持所需的QoS。

An example scenario that may benefit from such information is that of the two UDP streams associated with the same media, but requiring different levels of error protection at the wireless link layer due to certain characteristics of their respective encoding schemes. The packets of these two streams are equally delay sensitive (so as to maintain playout synchronization at the

可能受益于此类信息的示例场景是与相同媒体相关联的两个UDP流的场景,但是由于其各自编码方案的某些特征,在无线链路层需要不同级别的错误保护。这两个流的数据包对延迟同样敏感(以便在同一时间保持播放同步)

receiver), and hence, may be treated equally (as regards queuing) by IP layer. But they may need to be transmitted on wireless channels of different error characteristics (say different FEC coding or power levels).

因此,IP层可以平等地对待(关于排队)。但它们可能需要在具有不同错误特征(例如不同的FEC编码或功率电平)的无线信道上传输。

The QoS information included for the benefit of wireless link layers SHOULD be such that it is meaningful both ways: to applications that reside over IP so that they can choose the IP service of certain QoS characteristics and to wireless link QoS managers so that they can then map this information to the details of lower layer mechanisms and their parameters.

为了无线链路层的利益而包括的QoS信息应该是这样的:对于驻留在IP上的应用程序(以便它们可以选择具有特定QoS特征的IP服务)和无线链路QoS管理器(以便它们可以随后将此信息映射到较低层机制和服务的细节)都有意义它们的参数。

In the example scenario described above, such a QoS information could be expressed as the acceptable loss rate of IP packets in the UDP stream. This parameter enables the UDP application to choose the IP service having QoS that matches its requirements, and it also enables the wireless link QoS managers to choose the right wireless channel to transmit the packets of this UDP stream.

在上述示例场景中,这样的QoS信息可以表示为UDP流中IP分组的可接受丢失率。此参数使UDP应用程序能够选择具有与其要求相匹配的QoS的IP服务,并使无线链路QoS管理器能够选择正确的无线信道来传输此UDP流的数据包。

3.4. Standard requirements
3.4. 标准要求

The QoS solution for Mobile IP SHOULD satisfy standard requirements such as scalability, security, conservation of wireless bandwidth, low processing overhead on mobile terminals, providing hooks for authorization and accounting, and robustness against failures of any Mobile IP-specific QoS components in the network. While it is not possible to set quantitative targets for these desirable properties, the QoS solution MUST be evaluated against these criteria.

移动IP的QoS解决方案应满足标准要求,例如可扩展性、安全性、无线带宽的节约、移动终端上的低处理开销、提供授权和记帐挂钩,以及对网络中任何移动IP特定QoS组件的故障的鲁棒性。虽然不可能为这些期望的属性设置定量目标,但必须根据这些标准评估QoS解决方案。

4. Security Considerations
4. 安全考虑

The QoS (re)establishment triggered by node mobility MUST be guarded against security attacks. Such attacks could be launched by malicious nodes that spoof the QoS signaling to make it appear to the intermediate nodes that the MN has undergone handover. Such an attack could disrupt the QoS offered to MN's ongoing sessions as the intermediate nodes may then tear down the QoS along some segments of the true packet paths between MN and CN. The malicious nodes may also request a reduced level of QoS or supply fake packet classifiers, thereby affecting QoS over some segments (e.g., that do not get affected by the spoofed handover) of the true packet paths between MN and CN. Further, network resources may be wasted or used in an unauthorized manner by the malicious nodes that spoof MN's handover. To prevent this, QoS mechanism MUST provide means for intermediate nodes to verify the authenticity of handover-induced QoS (re)establishment.

由节点移动性触发的QoS(重新)建立必须防范安全攻击。恶意节点可发起此类攻击,欺骗QoS信令,使中间节点觉得MN已经历切换。这种攻击可能会破坏提供给MN正在进行的会话的QoS,因为中间节点随后可能会沿着MN和CN之间的真实数据包路径的某些段破坏QoS。恶意节点还可以请求降低的QoS水平或提供假分组分类器,从而影响MN和CN之间的真实分组路径的某些分段(例如,不受欺骗切换影响的分段)上的QoS。此外,欺骗MN切换的恶意节点可能会以未经授权的方式浪费或使用网络资源。为了防止这种情况,QoS机制必须为中间节点提供验证切换诱导的QoS(重新)建立的真实性的手段。

5. Recommendation
5. 正式建议

In this document, we described the requirements for a QoS solution for its satisfactory operation with Mobile IP. The expectation is that the appropriate working group will use this requirements document to provide a QoS solution for Mobile IP.

在本文档中,我们描述了对QoS解决方案的要求,以使其能够在移动IP上满意地运行。期望适当的工作组将使用此需求文档为移动IP提供QoS解决方案。

6. Acknowledgment
6. 致谢

I would like to acknowledge the participants of the mailing list that was set up to discuss the above requirements. Their contributions and active participation in the discussion on the mailing list were very useful in the preparation of this document. Special thanks are due to, in alphabetical order, Brian Carpenter (IBM), Marc Greis (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael Thomas (Cisco) for their input during the preparation of this document.

我想感谢为讨论上述要求而建立的邮件列表的参与者。他们的贡献和积极参与关于邮寄名单的讨论对本文件的编写非常有用。特别感谢Brian Carpenter(IBM)、Marc Greis(诺基亚)、Glenn Morrow(北电)、Phil Roberts(Megisto)和Michael Thomas(思科)按字母顺序在编写本文档过程中提供的意见。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[1] Perkins, C., Ed., "IP mobility support for IPv4", RFC 3344, August 2002.

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

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

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

[3] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.

[3] Bernet,Y.,Ford,P.,Yavatkar,R.,Baker,F.,Zhang,L.,Speer,M.,Braden,R.,Davie,B.,Wroclawski,J.和E.Felstaine,“区分服务网络上的综合服务运营框架”,RFC 29982000年11月。

[4] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[4] Braden,R.,Ed.,Zhang,L.,Berson,S.,Herzog,S.和S.Jamin,“资源预留协议(RSVP)——第1版功能规范”,RFC 22052997年9月。

[5] Kempf, J., Ed., "Problem description: Reasons for performing context transfers between nodes in an IP Access Network", RFC 3374, September 2002.

[5] Kempf,J.,Ed.,“问题描述:在IP接入网络中的节点之间执行上下文传输的原因”,RFC 3374,2002年9月。

7.2. Informative References
7.2. 资料性引用

[6] Johnson, D., Perkins, C. and J. Arkko, "Mobility support in IPv6", Work in Progress, May 2003.

[6] Johnson,D.,Perkins,C.和J.Arkko,“IPv6中的移动支持”,正在进行的工作,2003年5月。

[7] Trossen, D., et al., "Issues in Candidate Access Router discovery for seamless IP handoffs", Work in Progress, October 2002.

[7] Trossen,D.等人,“无缝IP切换的候选接入路由器发现问题”,正在进行的工作,2002年10月。

[8] Chaskar, H. and R. Koodli, "QoS support in Mobile IP version 6", IEEE Broadband Wireless Summit (Networld+Interop), May 2001.

[8] Chaskar,H.和R.Koodli,“移动IP版本6中的QoS支持”,IEEE宽带无线峰会(Networld+Interop),2001年5月。

[9] Thomas, M., "Analysis of Mobile IP and RSVP interactions", Work in Progress, February 2001.

[9] Thomas,M.“移动IP和RSVP交互的分析”,正在进行的工作,2001年2月。

[10] MIPv4 Handoffs Design Team, "Low latency handoffs in Mobile IPv4", Work in Progress, June 2002.

[10] MIPv4切换设计团队,“移动IPv4中的低延迟切换”,正在进行的工作,2002年6月。

[11] Koodli, R., Ed., "Fast handovers for Mobile IPv6", Work in Progress, March 2003.

[11] Koodli,R.,Ed.,“移动IPv6的快速切换”,正在进行的工作,2003年3月。

[12] Williams, C., Ed., "Localized mobility management requirements", Work in Progress, March 2003.

[12] Williams,C.,Ed.“本地化移动性管理要求”,正在进行的工作,2003年3月。

[13] Soliman, H., et al., "Hierarchical MIPv6 mobility management (HMIPv6)", Work in Progress, October 2002.

[13] Soliman,H.等人,“分层MIPv6移动性管理(HMIPv6)”,进展中的工作,2002年10月。

8. Authors' Addresses
8. 作者地址

The working group can be contacted via the current chair:

可通过现任主席联系工作组:

John Loughney Nokia Research Center 11-13 Italahdenkatu 00180 Helsinki Finland

John Loughney诺基亚研究中心11-13 Italahdenkatu 00180芬兰赫尔辛基

   EMail: john.loughney@nokia.com
        
   EMail: john.loughney@nokia.com
        

Questions about this memo can be directed to the editor:

有关本备忘录的问题,请联系编辑:

Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA

美国马萨诸塞州伯灵顿路5号Hemant Chaskar诺基亚研究中心邮编01803

   Phone: +1 781-993-3785
   EMail: hemant.chaskar@nokia.com
        
   Phone: +1 781-993-3785
   EMail: hemant.chaskar@nokia.com
        
9. Full Copyright Statement
9. 完整版权声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

版权所有(C)互联网协会(2003年)。版权所有。

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

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

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编辑功能的资金目前由互联网协会提供。