Network Working Group W. Eddy
Request for Comments: 5522 Verizon
Category: Informational W. Ivancic
NASA
T. Davis
Boeing
October 2009
Network Working Group W. Eddy
Request for Comments: 5522 Verizon
Category: Informational W. Ivancic
NASA
T. Davis
Boeing
October 2009
Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks
航空和空间探索移动网络中操作使用的网络移动性路由优化要求
Abstract
摘要
This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.
本文件描述了用于航空和空间探索的全球网络通信系统的网络移动（NEMO）路由优化技术的要求和期望特性。
Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies.
IETF以外的航空通信专家，包括国际民用航空组织（ICAO）和其他航空通信标准机构的成员，为这些要求提供了大量投入。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................2
2. NEMO RO Scenarios ...............................................5
2.1. Aeronautical Communications Scenarios ......................5
2.1.1. Air Traffic Services Domain .........................6
2.1.2. Airline Operational Services Domain .................8
2.1.3. Passenger Services Domain ...........................9
2.2. Space Exploration Scenarios ...............................10
3. Required Characteristics .......................................12
3.1. Req1 - Separability .......................................13
3.2. Req2 - Multihoming ........................................14
3.3. Req3 - Latency ............................................15
3.4. Req4 - Availability .......................................16
3.5. Req5 - Packet Loss ........................................17
3.6. Req6 - Scalability ........................................18
3.7. Req7 - Efficient Signaling ................................19
3.8. Req8 - Security ...........................................20
3.9. Req9 - Adaptability .......................................22
4. Desirable Characteristics ......................................22
4.1. Des1 - Configuration ......................................22
4.2. Des2 - Nesting ............................................23
4.3. Des3 - System Impact ......................................23
4.4. Des4 - VMN Support ........................................23
4.5. Des5 - Generality .........................................24
5. Security Considerations ........................................24
6. Acknowledgments ................................................24
7. References .....................................................25
7.1. Normative References ......................................25
7.2. Informative References ....................................25
Appendix A. Basics of IP-Based Aeronautical Networking ........28
Appendix B. Basics of IP-based Space Networking ................30
1. Introduction ....................................................2
2. NEMO RO Scenarios ...............................................5
2.1. Aeronautical Communications Scenarios ......................5
2.1.1. Air Traffic Services Domain .........................6
2.1.2. Airline Operational Services Domain .................8
2.1.3. Passenger Services Domain ...........................9
2.2. Space Exploration Scenarios ...............................10
3. Required Characteristics .......................................12
3.1. Req1 - Separability .......................................13
3.2. Req2 - Multihoming ........................................14
3.3. Req3 - Latency ............................................15
3.4. Req4 - Availability .......................................16
3.5. Req5 - Packet Loss ........................................17
3.6. Req6 - Scalability ........................................18
3.7. Req7 - Efficient Signaling ................................19
3.8. Req8 - Security ...........................................20
3.9. Req9 - Adaptability .......................................22
4. Desirable Characteristics ......................................22
4.1. Des1 - Configuration ......................................22
4.2. Des2 - Nesting ............................................23
4.3. Des3 - System Impact ......................................23
4.4. Des4 - VMN Support ........................................23
4.5. Des5 - Generality .........................................24
5. Security Considerations ........................................24
6. Acknowledgments ................................................24
7. References .....................................................25
7.1. Normative References ......................................25
7.2. Informative References ....................................25
Appendix A. Basics of IP-Based Aeronautical Networking ........28
Appendix B. Basics of IP-based Space Networking ................30
As background, the Network Mobility (NEMO) terminology and NEMO goals and requirements documents are suggested reading ([4], [5]).
作为背景，建议阅读网络移动（NEMO）术语以及NEMO目标和要求文件（[4]，[5]）。
The base NEMO standard [1] extends Mobile IPv6 [2] for singular mobile hosts in order to be used by Mobile Routers (MRs) supporting entire mobile networks. NEMO allows mobile networks to efficiently remain reachable via fixed IP address prefixes no matter where they relocate within the network topology. This is accomplished through the maintenance of a bidirectional tunnel between a NEMO MR and a NEMO-supporting Home Agent (HA) placed at some relatively stable point in the network. NEMO does not provide Mobile IPv6's Route Optimization (RO) features to Mobile Network Nodes (MNNs) other than to the NEMO MR itself. Corresponding Nodes (CNs) that communicate
NEMO基本标准[1]为单个移动主机扩展了移动IPv6[2]，以供支持整个移动网络的移动路由器（MRs）使用。NEMO允许移动网络通过固定IP地址前缀有效地保持可访问性，无论它们在网络拓扑中的位置如何。这是通过维护位于网络中某个相对稳定点的NEMO MR和NEMO支持归属代理（HA）之间的双向隧道来实现的。除了NEMO MR本身，NEMO不向移动网络节点（MNN）提供移动IPv6的路由优化（RO）功能。通信的对应节点（CNs）
with MNNs behind an MR do so through the HA and the bidirectional Mobile Router - Home Agent (MRHA) tunnel. Since the use of this tunnel may have significant drawbacks [6], RO techniques that allow a more direct path between the CN and MR to be used are highly desirable.
在MR后面的MNN通过HA和双向移动路由器-归属代理（MRHA）隧道来实现。由于该隧道的使用可能有明显的缺点[6]，因此非常需要允许在CN和MR之间使用更直接路径的RO技术。
For decades, mobile networks of some form have been used for communications with people and avionics equipment on board aircraft and spacecraft. These have not typically used IP, although architectures are being devised and deployed based on IP in both the aeronautics and space exploration communities (see Appendix A and Appendix B for more information). An aircraft or spacecraft generally contains many computing nodes, sensors, and other devices that are possible to address individually with IPv6. This is desirable to support network-centric operations concepts. Given that a craft has only a small number of access links, it is very natural to use NEMO MRs to localize the functions needed to manage the large onboard network's reachability over the few dynamic access links. On an aircraft, the nodes are arranged in multiple, independent networks, based on their functions. These multiple networks are required for regulatory reasons to have different treatments of their air-ground traffic and must often use distinct air-ground links and service providers.
几十年来，某种形式的移动网络已用于与人以及飞机和航天器上的航空电子设备进行通信。虽然航空界和空间探索界正在设计和部署基于IP的体系结构（更多信息，请参见附录A和附录B），但这些体系结构通常未使用IP。飞机或航天器通常包含许多计算节点、传感器和其他设备，这些设备可以通过IPv6单独寻址。这有助于支持以网络为中心的作战概念。鉴于飞行器只有少量的接入链路，使用NEMO MRs将管理大型机载网络在少数动态接入链路上的可达性所需的功能本地化是非常自然的。在飞机上，节点根据其功能排列在多个独立的网络中。出于监管原因，这些多个网络需要对其空地通信进行不同的处理，并且必须经常使用不同的空地链路和服务提供商。
For aeronautics, the main disadvantage of using NEMO bidirectional tunnels is that airlines operate flights that traverse multiple continents, and a single plane may fly around the entire world over a span of a couple days. If a plane uses a static HA on a single continent, then for a large percentage of the time, when the plane is not on the same continent as the HA, a great amount of delay is imposed by using the MRHA tunnel. Avoiding the delay from unnecessarily forcing packets across multiple continents is the primary goal of pursuing NEMO RO for aeronautics.
就航空业而言，使用NEMO双向隧道的主要缺点是，航空公司运营的航班横跨多个大陆，一架飞机可能在几天内环绕整个世界飞行。如果飞机在单个大陆上使用静态HA，那么在大部分时间内，当飞机与HA不在同一大陆上时，使用MRHA隧道会造成大量延迟。避免由于不必要地强迫数据包跨越多个大陆而造成的延迟是追求NEMO RO航空的主要目标。
Other properties of the aeronautics and space environments amplify the known issues with NEMO bidirectional MRHA tunnels [6] even further.
航空和空间环境的其他特性进一步放大了NEMO双向MRHA隧道的已知问题[6]。
Longer routes leading to increased delay and additional infrastructure load: In aeronautical networks (e.g., using "Plain Old" Aircraft Communication Addressing and Reporting System (ACARS) or ACARS over VHF Data Link (VDL) mode 2) the queueing delays are often long due to Automatic Repeat Request (ARQ) mechanisms and underprovisioned radio links. Furthermore, for space exploration and for aeronautical communications systems that pass through geosynchronous satellites, the propagation delays are also long. These delays, combined with the additional need
较长的路由导致延迟增加和额外的基础设施负载：在航空网络中（例如，使用“普通旧”飞机通信寻址和报告系统（ACARS）或VHF数据链路（VDL）模式2上的ACARS），由于自动重复请求（ARQ），排队延迟通常较长机制和供应不足的无线电链路。此外，对于空间探索和通过地球同步卫星的航空通信系统，传播延迟也很长。这些延误，再加上额外的需求
to cross continents in order to transport packets between ground stations and CNs, mean that delays are already quite high in aeronautical and space networks without the addition of an MRHA tunnel. The increased delays caused by MRHA tunnels may be unacceptable in meeting Required Communication Performance [7].
为了在地面站和CNs之间传输数据包而跨越大陆，这意味着在不增加MRHA隧道的情况下，航空和航天网络中的延迟已经相当高了。MRHA隧道造成的延迟增加可能无法满足要求的通信性能[7]。
Increased packet overhead: Given the constrained link bandwidths available in even future communications systems for aeronautics and space exploration, planners are extremely adverse to header overhead. Since any amount of available link capacity can be utilized for extra situational awareness, science data, etc., every byte of header/tunnel overhead displaces a byte of useful data.
增加的数据包开销：考虑到未来航空和空间探索通信系统中可用的链路带宽有限，规划者对报头开销极为不利。由于任何数量的可用链路容量都可用于额外的态势感知、科学数据等，因此每个字节的报头/隧道开销将替换一个字节的有用数据。
Increased chances of packet fragmentation: RFC 4888 [6] identifies fragmentation due to encapsulation as an artifact of tunneling. While links used in the aeronautics and space domains are error-prone and may cause loss of fragments on the initial/final hop(s), considerations for fragmentation along the entire tunneled path are the same as for the terrestrial domain.
增加数据包碎片的机会：RFC 4888[6]将封装导致的碎片识别为隧道效应。虽然航空和航天领域中使用的链路容易出错，并可能导致初始/最终跳数上的碎片丢失，但整个隧道路径上碎片的考虑与地面领域相同。
Increased susceptibility to failure: The additional likelihood of either a single link failure disrupting all communications or an HA failure disrupting all communications is problematic when using MRHA tunnels for command and control applications that require high availability for safety-of-life or safety-of-mission.
故障敏感性增加：当使用MRHA隧道用于需要高可用性以确保生命安全或任务安全的指挥和控制应用程序时，单链路故障中断所有通信或HA故障中断所有通信的额外可能性是有问题的。
For these reasons, an RO extension to NEMO is highly desirable for use in aeronautical and space networking. In fact, a standard RO mechanism may even be necessary before some planners will seriously consider advancing use of the NEMO technology from experimental demonstrations to operational use within their communications architectures. Without an RO solution, NEMO is difficult to justify for realistic operational consideration.
由于这些原因，NEMO的RO扩展非常适合用于航空和航天网络。事实上，标准RO机制甚至可能是必要的，在一些规划者将认真考虑将NEMO技术的使用从实验演示到其通信架构内的操作使用。如果没有反渗透解决方案，NEMO很难从实际操作考虑。
In Section 2 we describe the relevant high-level features of the access and onboard networks envisioned for use in aeronautics and space exploration, as they influence the properties of usable NEMO RO solutions. Section 3 then lists the technical and functional characteristics that are absolutely required of a NEMO RO solution for these environments, while Section 4 lists some additional characteristics that are desired but not necessarily required. In Appendix A and Appendix B we provide brief primers on the specific operational concepts used in aeronautics and space exploration, respectively, for IP-based network architectures.
在第2节中，我们描述了用于航空和空间探索的接入和机载网络的相关高级功能，因为它们影响可用的NEMO RO解决方案的性能。第3节列出了这些环境下NEMO RO解决方案绝对需要的技术和功能特性，而第4节列出了一些需要但不一定需要的附加特性。在附录A和附录B中，我们分别为基于IP的网络体系结构提供了航空和空间探索中使用的具体操作概念的简要入门。
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 RFC 2119 [3]. Although this document does not specify an actual protocol, but rather specifies just the requirements for a protocol, it still uses the RFC 2119 language to make the requirements clear.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。尽管本文档没有指定实际的协议，而只是指定了协议的要求，但它仍然使用RFC 2119语言来明确要求。
To motivate and drive the development of the requirements and desirable features for NEMO RO solutions, this section describes some operational characteristics to explain how access networks, HAs, and CNs are configured and distributed geographically and topologically in aeronautical and space network architectures. This may be useful in determining which classes of RO techniques within the known solution space [8] are feasible.
为了激励和推动NEMO RO解决方案的需求和期望功能的开发，本节描述了一些操作特征，以解释如何在航空和航天网络体系结构中配置和分布接入网络、HAs和CNs。这可能有助于确定已知溶液空间[8]中哪类RO技术是可行的。
Since aircraft may be simultaneously connected to multiple ground access networks using diverse technologies with different coverage properties, it is difficult to say much in general about the rate of changes in active access links and care-of addresses (CoAs). As one data point, for using VDL mode 2 data links, the length of time spent on a single access channel varies depending on the stage of flight. On the airport surface, VDL mode 2 access is stable while a plane is unloaded, loaded, refueled, etc., but other wired and wireless LAN links (e.g. local networks available while on a gate) may come and go. Immediately after takeoff and before landing, planes are in the terminal maneuvering area for approximately 10 minutes and stably use another VDL mode 2 channel. During en route flight, handovers between VDL mode 2 channels may occur every 30 to 60 minutes, depending on the exact flight plan and layout of towers, cells, and sectors used by a service provider. These handovers may result in having a different access router and a change in CoA, though the use of local mobility management (e.g., [9]) may limit the changes in CoA to only handovers between different providers or types of data links.
由于飞机可能使用不同覆盖特性的不同技术同时连接到多个地面接入网络，因此很难对主动接入链路和转交地址（COA）的变化率进行一般性的描述。作为一个数据点，对于使用VDL模式2数据链路，在单个接入信道上花费的时间长度取决于飞行阶段。在机场地面，当飞机卸载、装载、加油等时，VDL模式2的访问是稳定的，但其他有线和无线LAN链路（例如，在登机口时可用的本地网络）可能会来来去去。起飞后和着陆前，飞机立即进入终端机动区约10分钟，并稳定使用另一个VDL模式2通道。在航路飞行期间，VDL模式2频道之间的切换可能每30到60分钟发生一次，具体取决于服务提供商使用的发射塔、信元和扇区的精确飞行计划和布局。这些切换可能导致具有不同的接入路由器和CoA中的变化，尽管使用本地移动性管理（例如，[9]）可能将CoA中的变化限制为仅在不同提供商或数据链路类型之间的切换。
The characteristics of a data flow between a CN and MNN varies both depending on the data flow's domain and on the particular application within the domain. Even within the three aeronautical domains described below, there are varying classes of service that are regulated differently (e.g., for emergencies versus nominal operations), but this level of detail has been abstracted out for the purposes of this document. It is assumed that any viable NEMO RO solution will be able to support a granularity of configuration with many sub-classes of traffic within each of the specific domains listed here.
CN和MNN之间的数据流的特征根据数据流的域和域内的特定应用而变化。即使在下面描述的三个航空领域内，也有不同类别的服务受到不同的监管（例如，紧急情况与正常运行），但为了本文件的目的，已抽象出这一详细级别。假设任何可行的NEMO RO解决方案都能够支持在此处列出的每个特定域内具有多个子类流量的配置粒度。
The MNNs involved in Air Traffic Services (ATS) consist of pieces of avionics hardware on board an aircraft that are used to provide navigation, control, and situational awareness. The applications run by these MNNs are mostly critical to the safety of the lives of the passengers and crew. The MNN equipment may consist of a range of devices from typical laptop computers to very specialized avionics devices. These MNNs will mostly be Local Fixed Nodes (LFNs), with a few Local Mobile Nodes (LMNs) to support Electronic Flight Bags, for instance. It can be assumed that Visiting Mobile Nodes (VMNs) are never used within the ATS domain.
空中交通服务（ATS）中涉及的MNN由飞机上用于提供导航、控制和态势感知的航空电子设备硬件组成。这些MNN运行的应用程序对乘客和机组人员的生命安全至关重要。MNN设备可能包括一系列设备，从典型的笔记本电脑到非常专业的航空电子设备。这些MNN大多是本地固定节点（LFN），例如，有几个本地移动节点（LMN）支持电子飞行包。可以假设，在ATS域内从未使用访问移动节点（VMN）。
An MR used for ATS will be capable of using multiple data links (at least VHF-based, satellite, HF-based, and wired), and will likely be supported by a backup unit in the case of failure, leading to a case of a multihomed MR that is at least multi-interfaced and possibly multi-prefixed as well, in NEMO terminology.
用于ATS的MR将能够使用多个数据链路（至少基于VHF、卫星、基于HF和有线），并可能在故障情况下由备份装置支持，从而导致多址MR的情况，在NEMO术语中，至少是多接口的，并且可能是多前缀的。
The existing ATS link technologies may be too anemic for a complete IP-based ATS communications architecture (link technologies and acronyms are briefly defined in Appendix A). At the time of this writing, the ICAO is pursuing future data link standards that support higher data rates. Part of the problem is limited spectrum, pursued under ICAO ACP-WG-F, "Spectrum Management", and part of the problem is the data link protocols themselves, pursued under ICAO ACP-WG-T, "Future Communications Technology". ACP-WG-T has received inputs from studies on a number of potential data link protocols, including B-AMC, AMACS, P34, LDL, WCDMA, and others. Different link technologies may be used in different stages of flight, for instance 802.16 in the surface and terminal area, P34 or LDL en route, and satcom in oceanic flight. Both current and planned data links used for Passenger Information and Entertainment Services (PIES) and/or Airline Operational Services (AOS), such as the satcom links employed by passenger Internet-access systems, support much higher data rates than current ATS links.
现有的ATS链路技术对于完整的基于IP的ATS通信体系结构来说可能太薄弱（链路技术和首字母缩略词在附录a中有简要定义）。在撰写本文时，国际民航组织正在追求支持更高数据速率的未来数据链路标准。部分问题是根据ICAO ACP-WG-F“频谱管理”实施的频谱有限，部分问题是根据ICAO ACP-WG-T“未来通信技术”实施的数据链路协议本身。ACP-WG-T已经收到了许多潜在数据链路协议研究的输入，包括B-AMC、AMAC、P34、LDL、WCDMA和其他协议。不同的链路技术可用于不同的飞行阶段，例如地面和终端区域的802.16、航路中的P34或LDL以及海洋飞行中的卫星通信。用于乘客信息和娱乐服务（PIES）和/或航空公司运营服务（AOS）的当前和计划中的数据链路，如乘客互联网接入系统使用的卫星通信链路，支持比当前ATS链路高得多的数据速率。
Since, for ATS, the MRs and MNNs are under regulatory control and are actively tested and maintained, it is not completely unreasonable to assume that special patches or software be run on these devices to enable NEMO RO. In fact, since these devices are accessed by skilled technicians and professionals, it may be that some special configuration is required for NEMO RO. Of course, simplicity in set up and configuration is highly preferable, however, and the desirable feature labeled "Des1" later in this document prefers solutions with lower configuration state and overhead. To minimize costs of
由于对于ATS而言，MRs和MNN处于监管控制之下，并进行了积极的测试和维护，因此假设在这些设备上运行特殊补丁或软件以启用NEMO RO并非完全不合理。事实上，由于这些设备由技术熟练的技术人员和专业人员使用，尼莫反渗透可能需要一些特殊配置。当然，设置和配置的简单性是非常可取的，但是，本文档后面标记为“Des1”的理想特性更倾向于配置状态和开销较低的解决方案。最大限度地降低成本
ownership and operations, it is also highly desirable for only widely available, off-the-shelf operating systems or network stacks to be required, but this is not a full requirement.
在所有权和操作方面，只需要广泛可用的现成操作系统或网络堆栈也是非常可取的，但这并不是全部要求。
Data flows from the ATS domain may be assumed to consist mainly of short transactional exchanges, such as clearance requests and grants. Future ATS communications are likely to include longer messages and higher message frequencies for positional awareness and trajectory intent of all vehicles in motion at the airport and all aircraft within a thirty-mile range during flight. Many of these may be aircraft-to-aircraft, but the majority of current exchanges are between the MNNs and a very small set of CNs within a control facility and take place at any time due to the full transfer of control as a plane moves across sectors of airspace. The set of CNs may be assumed to be topologically close to one another. These CNs are also involved in other data flows over the same access network that the MR is attached to, managing other flights within the sector. These CNs are often geographically and topologically much closer to the MR in comparison to a single fixed HA.
ATS域的数据流可能主要由短事务交换组成，如许可请求和授权。未来的自动测试系统通信可能包括更长的信息和更高的信息频率，以便在飞行期间，机场内所有行驶车辆和30英里范围内所有飞机的位置感知和轨迹意图。其中许多可能是飞机对飞机，但当前的大多数交换是在MNN和控制设施内的一组非常小的CNs之间进行的，并且由于飞机在空域各区移动时控制权的完全转移，因此可以随时进行。可假设CNs组在拓扑上彼此接近。这些CNs还参与MR所连接的同一接入网络上的其他数据流，管理扇区内的其他航班。与单个固定HA相比，这些CNs在地理和拓扑上通常更接近MR。
The MNNs and CNs used for ATS will support IP services, as IP is the basis of the new Aeronautical Telecommunications Network (ATN) architecture being defined by ICAO. Some current ATS ground systems run typical operating systems, like Solaris, Linux, and Windows, on typical workstation computer hardware. There is some possibility for an RO solution to require minor changes to these CNs, though it is much more desirable if completely off-the-shelf CN machines and operating systems can be used. Later in this document, the security requirements suggest that RO might be performed with mobility anchors that are topologically close to the CNs, rather than directly to CNs themselves. This could possibly mean that CN modifications are not required.
ATS使用的MNN和CNs将支持IP服务，因为IP是国际民航组织定义的新航空电信网络（ATN）架构的基础。一些当前的ATS地面系统在典型的工作站计算机硬件上运行典型的操作系统，如Solaris、Linux和Windows。RO解决方案可能需要对这些CNs进行微小更改，但如果可以使用完全现成的CN机器和操作系统，则更可取。在本文件的后面部分，安全要求表明，可以使用拓扑上靠近CNs的移动锚来执行RO，而不是直接到CNs本身。这可能意味着不需要对CN进行修改。
During the course of a flight, there are several events for which an RO solution should consider the performance implications:
在飞行过程中，有几个事件的RO解决方案应考虑性能的影响：
o Initial session creation with an ATS CN (called "Data Link Logon" in the aeronautical jargon).
o 使用ATS CN（航空术语中称为“数据链接登录”）创建初始会话。
o Transfer of control between ATS CNs, resulting in regional differences in where the controlling CN is located.
o ATS中枢神经系统之间的控制权转移，导致控制中枢神经系统所在地的区域差异。
o Aircraft-initiated contact with a non-controlling ATS CN, which may be located anywhere, without relation to the controlling CN.
o 飞机与非管制ATS CN开始接触，该CN可能位于任何位置，与管制CN无关。
o Non-controlling, ATS, CN-initiated contact with the aircraft.
o 非管制、ATS、CN发起与飞机的联系。
o Aircraft transition between one access link to another, resulting in change of CoA.
o 飞机在一条接入链路与另一条接入链路之间的过渡，导致CoA发生变化。
o Concurrent use of multiple access links with different care-of addresses.
o 同时使用具有不同转交地址的多个访问链路。
Data flows for Airline Operational Services (AOS) are not critical to the safety of the passengers or aircraft, but are needed for the business operations of airlines operating flights, and may affect the profitability of an airline's flights. Most of these data flows are sourced by MNNs that are part of the flight management system or sensor nodes on an aircraft, and are terminated at CNs located near an airline's headquarters or operations center. AOS traffic may include detailed electronic passenger manifests, passenger ticketing and rebooking traffic, and complete electronic baggage manifests. When suitable bandwidth is available (currently on the surface when connected to a wired link at a gate), "airplane health information" data transfers of between 10 and several hundred megabytes of data are likely, and in the future, it is expected that the In-Flight Entertainment (IFE) systems may receive movie refreshes of data (e.g., television programming or recent news updates) running into the multi-gigabyte range.
航空公司运营服务（AOS）的数据流对于乘客或飞机的安全并不重要，但对于运营航班的航空公司的业务运营来说是必需的，并且可能会影响航空公司航班的盈利能力。这些数据流大多由MNN提供，MNN是飞机上飞行管理系统或传感器节点的一部分，并在航空公司总部或运营中心附近的CNs处终止。AOS交通可能包括详细的电子乘客舱单、乘客票务和重新订票交通以及完整的电子行李舱单。当合适的带宽可用时（当连接到登机口的有线链路时，当前在地面上），“飞机健康信息”数据传输可能在10到数百兆字节之间，并且在未来，预计机上娱乐（IFE）系统可能会接收数据的电影刷新（例如，电视节目或最近的新闻更新）运行到数十亿字节的范围。
Currently, these flows are often short messages that record the timing of events of a flight, engine performance data, etc., but may be longer flows that upload weather or other supplementary data to an aircraft. In addition, email-like interactive messaging may be used at any time during a flight. For instance, messages can be exchanged before landing to arrange for arrival-gate services to be available for handicapped passengers, refueling, food and beverage stocking, and other needs. This messaging is not limited to landing preparation, though, and may occur at any stage of flight.
目前，这些流通常是记录飞行事件时间、发动机性能数据等的短消息，但也可能是向飞机上传天气或其他补充数据的较长流。此外，在飞行期间的任何时候都可以使用类似电子邮件的交互式消息传递。例如，可以在着陆前交换信息，为残疾乘客安排登机门服务、加油、食品和饮料储存以及其他需要。但是，该消息并不限于着陆准备，可能发生在飞行的任何阶段。
The equipment comprising these MNNs and CNs has similar considerations to the equipment used for the ATS domain. A key difference between ATS and AOS is that AOS data flows are routed to CNs that may be much more geographically remote to the aircraft than CNs used by ATS flows, as AOS CNs will probably be located at an airline's corporate data center or headquarters. The AOS CNs will also probably be static for the lifetime of the flight, rather than dynamic like the ATS CNs. An HA used for AOS may be fairly close topologically to the CNs, and RO may not be as big of a benefit for AOS since simple event logging is more typical than time-critical interactive messaging. For the small number of messaging flows, however, the CNs are geographically (but not necessarily topologically) very close to the aircraft, though this depends on how
由这些MNN和CNs组成的设备与ATS领域使用的设备具有类似的考虑因素。ATS和AOS之间的一个关键区别是，AOS数据流被路由到CNs，与ATS流使用的CNs相比，CNs在地理上可能更远离飞机，因为AOS CNs可能位于航空公司的公司数据中心或总部。AOS CNs在整个飞行期间也可能是静态的，而不像ATS CNs那样是动态的。用于AOS的HA在拓扑上可能与CNs相当接近，而RO对AOS的好处可能不大，因为简单的事件记录比时间关键型交互消息传递更为典型。然而，对于少量的消息流，CNs在地理上（但不一定在拓扑上）非常靠近飞机，尽管这取决于如何实现
applications are written -- whether they use centralized servers or exchange messages directly. Additionally, since AOS communication is more advisory in nature than ATS, rather than safety-critical, AOS flows are less sensitive to tunnel inefficiencies than ATS flows. For these reasons, in this document, we consider AOS data flow concerns with RO mechanisms to not be full requirements, but instead consider them desirable properties, which are discussed in Section 4.
应用程序是编写的——无论是使用集中式服务器还是直接交换消息。此外，由于AOS通信在本质上比ATS更具咨询性，而非安全关键性，因此AOS流对隧道效率低下的敏感性不如ATS流。由于这些原因，在本文中，我们考虑了ROS机制对AOS数据流的关注并不是完全的要求，而是考虑了它们所希望的特性，这在第4节中讨论过。
Future AOS MNNs and CNs can be expected to implement IPv6 and conform to the new IPv6-based ATN Standards and Recommended Practices (SARPS) that ICAO is defining. AOS CNs have similar hardware and software properties as described for ATS above.
未来的AOS MNN和CNs有望实施IPv6，并符合国际民航组织正在定义的新的基于IPv6的ATN标准和推荐做法（SARP）。AOS CNs具有与上述ATS类似的硬件和软件特性。
The MNNs involved in the Passenger Information and Entertainment Services (PIES) domain are mostly beyond the direct control of any single authority. The majority of these MNNs are VMNs and personal property brought on board by passengers for the duration of a flight, and thus it is unreasonable to assume that they be preloaded with special software or operating systems. These MNNs run stock Internet applications like web browsing, email, and file transfer, often through VPN tunnels. The MNNs themselves are portable electronics, such as laptop computers and mobile smartphones capable of connecting to an onboard wireless access network (e.g., using 802.11). To these MNN devices and users, connecting to the onboard network is identical to connecting to any other terrestrial "hotspot" or typical wireless LAN. The MNNs are completely oblivious to the fact that this access network is on an airplane and possibly moving around the globe. The users are not always technically proficient and may not be capable of performing any special configuration of their MNNs or applications.
涉及乘客信息和娱乐服务（PIES）领域的MNN大多不受任何单一机构的直接控制。这些MNN中的大多数是VMN和乘客在飞行期间随身携带的个人财产，因此，假设这些MNN预装有特殊软件或操作系统是不合理的。这些MNN通常通过VPN隧道运行股票互联网应用程序，如网页浏览、电子邮件和文件传输。MNN本身是便携式电子设备，例如能够连接到车载无线接入网络（例如，使用802.11）的笔记本电脑和移动智能手机。对于这些MNN设备和用户，连接到车载网络与连接到任何其他地面“热点”或典型的无线LAN是相同的。MNN完全忘记了这样一个事实，即该接入网络在飞机上，并且可能在全球移动。用户并非总是技术熟练，可能无法对其MNN或应用程序执行任何特殊配置。
The largest class of PIES CNs consists of typical web servers and other nodes on the public Internet. It is not reasonable to assume that these can be modified specifically to support a NEMO RO scheme. Presently, these CNs would be mostly IPv4-based, though an increasing number of IPv6 PIES CNs are expected in the future. This document does not consider the problem of IPv4-IPv6 transition, beyond the assumption that either MNNs and CNs are running IPv6 or a transition mechanism exists somewhere within the network.
最大的PIES CNs由典型的web服务器和公共互联网上的其他节点组成。不合理的假设是，可以专门对其进行修改以支持NEMO RO计划。目前，这些CNs将主要基于IPv4，但预计未来将有越来越多的IPv6 PIE CNs。该文档不考虑IPv4-IPv6过渡的问题，除了假设MNNs和CNS正在运行IPv6或在网络内某个地方存在转换机制之外。
A small number of PIES MNNs may be LFNs that store and distribute cached media content (e.g., movies and music) or that may provide gaming services to passengers. Due to the great size of the data stored on these LFNs compared to the anemic bandwidth available air-to-ground, these LFNs will probably not attempt to communicate off-board at all during the course of a flight, but will wait to update their content via either high-speed links available on the ground or
少数PIE MNN可能是LFN，用于存储和分发缓存的媒体内容（例如电影和音乐），或者为乘客提供游戏服务。由于这些LFN上存储的数据量很大，而空地可用带宽不足，因此这些LFN可能在飞行过程中根本不会尝试在机外通信，而是会等待通过地面或地面可用的高速链路更新其内容
removable media inserted by the flight crew. However, if a higher bandwidth link were affordably available, it might be used in-flight for these purposes, but supporting this is not a requirement. Data flows needed for billing passengers for access to content are relatively low bandwidth and are currently done in-flight. The requirements of these data flows are less stringent than those of ATS, however, so they are not specifically considered here.
由机组插入的可移动媒体。但是，如果可以负担得起更高带宽的链路，则可以在飞行中使用它来实现这些目的，但支持这一点并不是一项要求。向乘客收取内容访问费所需的数据流带宽相对较低，目前在飞行中完成。但是，这些数据流的要求不如ATS的要求严格，因此此处不特别考虑这些要求。
The PIES domain is not critical to safety-of-life, but is merely an added comfort or business service to passengers. Since PIES applications may consume much more bandwidth than the available links used in other domains, the PIES MNNs may have their packets routed through a separate high-bandwidth link that is not used by the ATS data flows. For instance, several service providers are planning to offer passenger Internet access during flight at DSL-like rates, just as the former Connexion by Boeing system did. Several airlines also plan to offer onboard cellular service to their passengers, possibly utilizing Voice-over-IP for transport. Due to the lack of criticality and the likelihood of being treated independently, in this document, PIES MNN concerns are not considered as input to requirements in Section 3. The RO solution should be optimized for ATS and AOS needs and consider PIES as a secondary concern.
PIES领域对生命安全不是至关重要的，而只是为乘客提供额外的舒适或商务服务。由于PIES应用程序可能比其他域中使用的可用链路消耗更多的带宽，因此PIES MNN可能通过ATS数据流不使用的单独高带宽链路路由其分组。例如，几家服务提供商正计划以类似DSL的费率向乘客提供飞行期间的互联网接入，就像波音系统的前Connexion一样。几家航空公司还计划为乘客提供车载蜂窝服务，可能利用IP语音进行运输。由于缺乏关键性和独立处理的可能性，在本文件中，PIES MNN问题不被视为第3节要求的输入。RO解决方案应优化ATS和AOS需要，并考虑馅饼作为次要关注。
With this in consideration, the PIES domain is also the most likely to utilize NEMO for communications in the near-term, since relatively little regulations and bureaucracy are involved in deploying new technology in this domain and since IP-based PIES systems have previously been developed and deployed (although not using NEMO) [10]. For these reasons, PIES concerns factor heavily into the desirable properties in Section 4, outside of the mandatory requirements.
考虑到这一点，PIES领域也是近期最有可能利用NEMO进行通信的领域，因为在该领域部署新技术涉及的法规和官僚机构相对较少，而且之前已经开发和部署了基于IP的PIES系统（尽管未使用NEMO）[10]。出于这些原因，PIES关注的因素在很大程度上与第4节中的期望属性有关，而非强制性要求。
Some PIES nodes are currently using 2.5G/3G links for mobile data services, and these may be able to migrate to an IP-based onboard mobile network, when available.
一些PIES节点目前正在使用2.5G/3G链路提供移动数据服务，如果可用，这些节点可能能够迁移到基于IP的车载移动网络。
This section describes some features of the network environments found in space exploration that are relevant to selecting an appropriate NEMO RO mechanism. It should be noted that IPv4-based mobile routing has been demonstrated on board the UK-DMC satellite and that the documentation on this serves as a useful reference for understanding some of the goals and configuration issues for certain types of space use of NEMO [11]. This section assumes space use of NEMO within the "near-Earth" range of space (i.e., not for communications between the Earth and Mars or other "deep space" locations). Note that NEMO is currently being considered for use out
本节介绍了在空间探索中发现的与选择适当的NEMO RO机制有关的网络环境的一些特征。应该注意的是，基于IPv4的移动路由已经在UK-DMC卫星上进行了演示，关于这一点的文档可作为了解NEMO某些空间使用类型的一些目标和配置问题的有用参考[11]。本节假设NEMO在“近地”空间范围内的空间使用（即，不用于地球与火星或其他“深空”位置之间的通信）。请注意，NEMO目前正在考虑使用
to lunar distances. No strong distinction is made here between civilian versus military use, or exploration mission versus Earth-observing or other mission types; our focus is on civilian exploration missions, but we believe that many of the same basic concerns are relevant to these other mission types.
到月球的距离。在这里，民用与军用、探索任务与地球观测或其他任务类型之间没有明显区别；我们的重点是民用探索任务，但我们认为，许多相同的基本关切与这些其他任务类型有关。
In space communications, a high degree of bandwidth asymmetry is often present, with the uplink from the ground to a craft typically being multiple orders of magnitude slower than the downlink from the craft to the ground. This means that the RO overhead may be negligible on the downlink but significant for the uplink. An RO scheme that minimizes the amount of signaling from CNs to an MN is desirable, since these uplinks may be low-bandwidth to begin with (possibly only several kilobits per second). Since the uplink is used for sending commands, it should not be blocked for long periods while serializing long RO signaling packets; any RO signaling from the CN to MNNs must not involve large packets.
在空间通信中，经常存在高度的带宽不对称，从地面到飞行器的上行链路通常比从飞行器到地面的下行链路慢多个数量级。这意味着RO开销在下行链路上可以忽略，但在上行链路上却非常重要。需要最小化从CNs到MN的信令量的RO方案，因为这些上行链路可能是低带宽的（可能仅为每秒几千比特）。由于上行链路用于发送命令，因此在序列化长RO信令包时，不应长时间阻塞上行链路；从CN到MNN的任何RO信令不得涉及大数据包。
For unmanned space flight, the MNNs on board a spacecraft consist almost entirely of LFN-sensing devices and processing devices that send telemetry and science data to CNs on the ground and actuator devices that are commanded from the ground in order to control the craft. Robotic lunar rovers may serve as VMNs behind an MR located on a lander or orbiter, but these rovers will contain many independent instruments and could probably be configured as an MR and LFNs instead of using a single VMN address.
对于无人空间飞行，航天器上的MNN几乎完全由LFN传感设备和处理设备组成，这些设备将遥测和科学数据发送到地面的CNs，以及从地面发出指令以控制航天器的执行器设备。机器人月球车可作为位于着陆器或轨道器上的MR后面的VMN，但这些月球车将包含许多独立的仪器，可能配置为MR和LFN，而不是使用单个VMN地址。
It can be assumed that for manned spaceflight, at least multiple MRs will be present and online simultaneously for fast failover. These will usually be multihomed over space links in diverse frequency bands, and so multiple access network prefixes can be expected to be in use simultaneously, especially since some links will be direct to ground stations while others may be bent-pipe repeated through satellite relays like the Tracking and Data Relay Satellite System (TDRSS). This conforms to the (n,1,1) or (n,n,1) NEMO multihoming scenarios [12]. For unmanned missions, if low weight and power are more critical, it is likely that only a single MR and single link/ prefix may be present, conforming to the (1,1,1) or (1,n,1) NEMO multihoming scenarios [12].
可以假设，对于载人航天飞行，至少会有多个MRs同时出现并在线，以实现快速故障切换。这些链路通常在不同频段的空间链路上进行多址连接，因此可以预期多址网络前缀将同时使用，特别是因为一些链路将直接连接到地面站，而另一些链路可能通过跟踪和数据中继卫星系统（TDRSS）等卫星中继重复。这符合（n，1，1）或（n，n，1）NEMO多址方案[12]。对于无人任务，如果低重量和功率更为关键，则可能只存在单个MR和单个链路/前缀，符合（1,1,1）或（1,n,1）NEMO多宿场景[12]。
In some modes of spacecraft operation, all communications may go through a single onboard computer (or a Command and Data Handling system as on the International Space Station) rather than directly to the MNNs themselves, so there is only ever one MNN behind an MR that is in direct contact with off-board CNs. In this case, removing the MR and using simple host-based Mobile IPv6 rather than NEMO is possible. However, an MR is more desirable because it could be part of a modular communications adapter that is used in multiple diverse
在航天器运行的某些模式下，所有通信可能通过单个机载计算机（或国际空间站上的命令和数据处理系统）进行，而不是直接发送到MNN本身，因此MR后面只有一个MNN与非机载CNs直接接触。在这种情况下，删除MR并使用简单的基于主机的移动IPv6而不是NEMO是可能的。然而，MR更可取，因为它可以是用于多种多样应用的模块化通信适配器的一部分
missions to bridge onboard buses and intelligently manage space links. This is cheaper and leads to faster development time than re-creating these capabilities per-mission if using simple Mobile IPv6 with a single Command and Data Handling node that varies widely between spacecraft. Also, all visions for the future involve network-centric operations where the direct addressability and accessibility of end devices and data is crucial. As network-centric operations become more prevalent, application of NEMO is likely to be needed to increase the flexibility of data flow.
连接车载总线和智能管理空间链路的任务。如果使用简单的移动IPv6和单个命令和数据处理节点（在航天器之间差异很大），这比每次任务重新创建这些功能更便宜，而且开发时间更快。此外，所有未来愿景都涉及以网络为中心的运营，终端设备和数据的直接寻址和可访问性至关重要。随着以网络为中心的操作越来越普遍，可能需要应用NEMO来增加数据流的灵活性。
The MRs and MNNs on board a spacecraft are highly customized computing platforms, and adding custom code or complex configurations in order to obtain NEMO RO capabilities is feasible, although it should not be assumed that any amount of code or configuration maintenance is possible after launch. The RO scheme as it is initially configured should continue to function throughout the lifetime of an asset.
航天器上的MRs和MNN是高度定制的计算平台，添加定制代码或复杂配置以获得NEMO RO能力是可行的，但不应假设在发射后可以进行任何数量的代码或配置维护。初始配置的RO方案应在资产的整个生命周期内继续运行。
For manned space flight, additional MNNs on spacesuits and astronauts may be present and used for applications like two-way voice conversation or video-downlink. These MNNs could be reusable and reconfigured per-flight for different craft or mission network designs, but it is still desirable for them to be able to autoconfigure themselves, and they may move between nested or non-nested MRs during a mission. For instance, if astronauts move between two docked spacecrafts, each craft may have its own local MR and wireless coverage that the suit MNNs will have to reconfigure for. It is desirable if an RO solution can respond appropriately to this change in locality and not cause high levels of packet loss during the transitional period. It is also likely that these MNNs will be part of Personal Area Networks (PANs), and so may appear either directly as MNNs behind the main MR on board or have their own MR within the PAN and thus create a nested (or even multi-level nested) NEMO configuration.
对于载人航天飞行，宇航服和宇航员上的附加MNN可能会出现，并用于双向语音对话或视频下行链路等应用。这些MNN可以根据不同的飞行器或任务网络设计在每次飞行中重复使用和重新配置，但它们仍然需要能够自动配置自己，并且在任务期间可以在嵌套或非嵌套MRs之间移动。例如，如果宇航员在两个对接的航天器之间移动，那么每一个航天器可能都有自己的本地MR和无线覆盖，而宇航服MNN必须重新配置。如果RO解决方案能够适当地响应本地的这种变化，并且在过渡期间不会导致高水平的分组丢失，则这是可取的。这些MNN也可能是个人区域网络（PAN）的一部分，因此可能直接作为MNN出现在船上主MR的后面，或者在PAN内有自己的MR，从而创建嵌套（甚至多层嵌套）NEMO配置。
This section lists requirements that specify the absolute minimal technical and/or functional properties that a NEMO RO mechanism must possess to be usable for aeronautical and space communications.
本节列出了规定NEMO-RO机构必须具备的用于航空和空间通信的绝对最低技术和/或功能特性的要求。
In the recent work done by the International Civil Aviation Organization (ICAO) to identify viable mobility technologies for providing IP services to aircraft, a set of technical criteria was developed ([13], [14]). The nine required characteristics listed in this document can be seen as directly descended from these ICAO criteria, except here we have made them much more specific and focused for the NEMO technology and the problem of RO within NEMO.
在国际民用航空组织（ICAO）最近为确定向飞机提供IP服务的可行移动技术所做的工作中，制定了一套技术标准（[13]，[14]）。本文件中列出的九个要求特征可被视为是这些国际民航组织标准的直接继承，但我们在此对NEMO技术和NEMO内部反渗透问题进行了更具体和重点的阐述。
The original ICAO criteria were more general and used for comparing the features of different mobility solutions (e.g., mobility techniques based on routing protocols versus transport protocols versus Mobile IP, etc.). Within the text describing each requirement in this section, we provide the high-level ICAO criteria from which it evolved.
最初的国际民航组织标准更为通用，用于比较不同移动解决方案的特点（例如，基于路由协议的移动技术与基于传输协议的移动技术与基于移动IP的移动技术等）。在本节描述每项要求的文本中，我们提供了国际民航组织的高级标准。
These requirements for aeronautics are generally similar to or in excess of the requirements for space exploration, so we do not add any additional requirements specifically for space exploration. In addition, the lack of a standards body regulating performance and safety requirements for space exploration means that the requirements for aviation are much easier to agree upon and base within existing requirements frameworks. After consideration, we believe that the set of aviation-based requirements outlined here also fully suffices for space exploration.
航空方面的这些要求通常与空间探索的要求类似或超过，因此我们不增加任何专门用于空间探索的额外要求。此外，由于缺乏一个规范空间探索性能和安全要求的标准机构，航空方面的要求更容易达成一致意见，并以现有的要求框架为基础。经过考虑，我们认为，这里概述的一套基于航空的要求也完全足以用于空间探索。
It is understood that different solutions may be needed for supporting different domains. This may mean either different NEMO RO solutions or different mobility solutions entirely. Divergent solutions amongst the domains are acceptable, though preferably avoided if possible.
可以理解，可能需要不同的解决方案来支持不同的领域。这可能意味着不同的尼莫反渗透解决方案或完全不同的移动性解决方案。各领域之间的分歧解决方案是可以接受的，但最好尽可能避免。
An underlying requirement that would be assumed by the use of Mobile IP technology for managing mobility (rather than a higher-layer approach) is that IP addresses used both within the mobile network and by CNs to start new sessions with nodes within the mobile network remain constant throughout the course of flights and operations. For ATS and AOS, this allows the Home Addresses (HoAs) to serve as node identifiers, rather than just locators, and for PIES it allows common persistent applications (e.g., Voice over IP (VoIP) clients, VPN clients, etc.) to remain connected throughout a flight. Prior aeronautical network systems like the prior OSI-based ATN and Connexion by Boeing set a precedent for keeping a fixed Mobile Network Prefix (MNP), though they relied on interdomain routing protocols (IDRP and BGP) to accomplish this, rather than NEMO technology. This requirement applies to the selection in general of a mobility management technology, and not specifically to an RO solution once NEMO has been decided on for mobility management.
通过使用移动IP技术来管理移动性（而不是更高层次的方法）所假定的一个基本要求是，在整个飞行和运行过程中，移动网络内和CNs用于启动与移动网络内节点的新会话的IP地址保持不变。对于ATS和AOS，这允许家庭地址（HOA）用作节点标识符，而不仅仅是定位器，对于PIE，它允许公共持久应用程序（例如IP语音（VoIP）客户端、VPN客户端等）在整个飞行过程中保持连接。以前的航空网络系统，如波音公司先前基于OSI的ATN和Connexion，开创了保留固定移动网络前缀（MNP）的先例，尽管它们依靠域间路由协议（IDRP和BGP）而不是NEMO技术来实现这一点。该要求适用于移动管理技术的总体选择，而不是在NEMO决定用于移动管理后的RO解决方案。
Since RO may be inappropriate for some flows, an RO scheme MUST support configuration by a per-domain, dynamic RO policy database. Entries in this database can be similar to those used in IPsec security policy databases in order to specify either bypassing or utilizing RO for specific flows.
由于RO可能不适合某些流，因此RO方案必须支持通过每个域的动态RO策略数据库进行配置。此数据库中的条目可以类似于IPsec安全策略数据库中使用的条目，以便为特定流指定绕过或使用RO。
Even if RO is available to increase the performance of a mobile network's traffic, it may not be appropriate for all flows.
即使RO可用于提高移动网络流量的性能，它也可能不适用于所有流量。
There may also be a desire to push certain flows through the MRHA path, rather than performing RO, to enable them to be easily recorded by a central service.
还可能希望通过MRHA路径推送某些流，而不是执行RO，以便中央服务能够轻松记录这些流。
For these reasons, an RO scheme must have the ability to be bypassed by applications that desire to use bidirectional tunnels through an HA. This desire could be expressed through a policy database similar to the security policy database used by IPsec, for instance, but the specific means of signaling or configuring the expression of this desire by applications is left as a detail for the specific RO specifications.
出于这些原因，RO方案必须能够被希望通过HA使用双向隧道的应用程序绕过。例如，可以通过类似于IPsec所使用的安全策略数据库的策略数据库来表达该愿望，但是通过应用程序发送信号或配置该愿望的表达的具体方式留作特定RO规范的细节。
In addition, it is expected that the use of NEMO technology be decided on a per-domain basis, so that it is possible that, for some domains, separate MRs or even non-NEMO mobility techniques are used. This requirement for an RO policy database only applies to domains that utilize NEMO.
此外，预计NEMO技术的使用将在每个域的基础上决定，因此，对于某些域，可能使用单独的MRs或甚至非NEMO移动技术。RO策略数据库的这一要求仅适用于使用NEMO的域。
This requirement was derived from ICAO's TC-1 [15] - "The approach should provide a means to define data communications that can be carried only over authorized paths for the traffic type and category specified by the user."
该要求源自国际民航组织的TC-1[15]-“该方法应提供一种方法，以定义只能通过用户指定的通信类型和类别的授权路径进行的数据通信。”
One suggested approach to traffic separation is multi-addressing of the onboard networks, with treatment of a traffic domain determined by the packet addresses used. However, there are other techniques possible for meeting this requirement, and so multi-addressing is not itself a requirement. The Req1 requirement we describe above is intended for separating the traffic within a domain that makes use of NEMO based on flow properties (e.g., short messaging flows vs. longer file transfers or voice flows).
一种建议的流量分离方法是车载网络的多重寻址，处理由所使用的分组地址确定的流量域。然而，还有其他技术可以满足这一要求，因此多重寻址本身并不是一项要求。我们上面描述的Req1要求旨在根据流量属性（例如，短消息流与较长的文件传输或语音流）分离使用NEMO的域内的流量。
An RO solution MUST support an MR having multiple interfaces and MUST allow a given domain to be bound to a specific interface. It MUST be possible to use different MNPs for different domains.
RO解决方案必须支持具有多个接口的MR，并且必须允许将给定域绑定到特定接口。必须能够为不同的域使用不同的MNP。
Multiple factors drive a requirement for multihoming capabilities. For ATS safety-of-life critical traffic, the need for high availability suggests a basic multihoming requirement. The
多个因素推动了对多宿能力的需求。对于生命关键交通的ATS安全，对高可用性的需求表明了基本的多宿要求。这个
regulatory and operational difficulty in deploying new systems and transitioning away from old ones also implies that a mix of access technologies may be in use at any given time, and may require simultaneous use. Another factor is that the multiple domains of applications on board may actually be restricted in what data links they are allowed to use, based on regulations and policy; thus, at certain times or locations, PIES data flows may have to use distinct access links from those used by ATS data flows.
部署新系统和从旧系统过渡的监管和操作困难也意味着在任何给定时间都可能使用多种接入技术，并且可能需要同时使用。另一个因素是，基于法规和政策，板上应用程序的多个域实际上可能在允许使用的数据链路方面受到限制；因此，在某些时间或位置，PIES数据流可能必须使用与ATS数据流不同的访问链路。
This drives the requirement that an RO solution MUST allow for an MR to be connected to multiple access networks simultaneously and have multiple CoAs in use simultaneously. The selection of a proper CoA and access link to use per-packet may be either within or outside the scope of the RO solution. As a minimum, if an RO solution is integrable with the MONAMI6 basic extensions (i.e., registration of multiple CoAs and flow bindings) and does not preclude their use, then this requirement can be considered to be satisfied.
这就要求RO解决方案必须允许MR同时连接到多个接入网络，并同时使用多个COA。每个数据包使用的正确CoA和接入链路的选择可能在RO解决方案的范围之内或之外。至少，如果RO解决方案可与MONAMI6基本扩展（即多个CoA和流绑定的注册）集成，并且不排除其使用，则可以认为满足了该要求。
It is not this requirement's intention that an RO scheme itself provide multihoming, but rather simply to exclude RO techniques whose use is not possible in multihomed scenarios.
本要求的目的不是让反渗透方案本身提供多宿主，而是简单地排除在多宿主场景中无法使用的反渗透技术。
In terms of NEMO multihoming scenarios [12], it MUST be possible to support at least the (n,1,n) and (n,n,n) scenarios.
就NEMO多址方案而言[12]，必须能够至少支持（n，1，n）和（n，n，n）方案。
This requirement was derived from ICAO's TC-2 - "The approach should enable an aircraft to both roam between and to be simultaneously connected to multiple independent air-ground networks."
这一要求源自国际民航组织的TC-2——“该方法应使飞机能够在多个独立的空地网络之间漫游，并同时连接到多个独立的空地网络。”
While an RO solution is in the process of setting up or reconfiguring, packets of specified flows MUST be capable of using the MRHA tunnel.
当RO解决方案处于设置或重新配置过程中时，指定流的数据包必须能够使用MRHA隧道。
It is possible that an RO scheme may take longer to set up or involve more signaling than the basic NEMO MRHA tunnel maintenance that occurs during an update to the MR's active CoAs when the set of usable access links changes. During this period of flux, it may be important for applications to be able to immediately get packets onto the ground network, especially considering that connectivity may have been blocked for some period of time while link-layer and NEMO procedures for dealing with the transition occurred. Also, when an application starts for the first time, the RO scheme may not have previous knowledge related to the CN and may need to perform some set
当可用接入链路组发生变化时，RO方案可能需要更长的时间来建立或涉及比基本NEMO MRHA隧道维护更多的信令，基本NEMO MRHA隧道维护在MR的活动CoA更新期间发生。在这段时间内，应用程序能够立即将数据包发送到地面网络可能很重要，特别是考虑到在链路层和NEMO程序处理过渡期间，连接可能已被阻塞一段时间。此外，当应用程序第一次启动时，RO方案可能没有与CN相关的先前知识，并且可能需要执行一些设置
up before an optimized path is available. If the RO scheme blocks packets either through queueing or dropping while it is configuring itself, this could result in unacceptable delays.
在优化路径可用之前，请先将其打开。如果RO方案在配置自身时通过排队或丢弃阻止数据包，这可能会导致不可接受的延迟。
Thus, when transitions in the MR's set of active access links occurs, the RO scheme MUST NOT block packets from using the MRHA tunnel if the RO scheme requires more time to set up or configure itself than the basic NEMO tunnel maintenance. Additionally, when an application flow is started, the RO scheme MUST allow packets to immediately be sent, perhaps without the full benefit of RO, if the RO scheme requires additional time to configure a more optimal path to the CN.
因此，当MR的一组活动接入链路发生转换时，如果RO方案需要比基本NEMO隧道维护更多的时间来设置或配置自身，则RO方案不得阻止数据包使用MRHA隧道。此外，当应用程序流启动时，如果RO方案需要额外的时间来配置到CN的更优化路径，则RO方案必须允许立即发送分组，可能没有RO的全部好处。
This requirement was derived from ICAO's TC-3 - "The approach should minimize latency during establishment of initial paths to an aircraft, during handoff, and during transfer of individual data packets."
这一要求源自国际民航组织的TC-3——“该方法应尽量减少飞机初始路径建立期间、切换期间和单个数据包传输期间的延迟。”
An RO solution MUST be compatible with network redundancy mechanisms and MUST NOT prevent fallback to the MRHA tunnel if an element in an optimized path fails.
RO解决方案必须与网络冗余机制兼容，并且在优化路径中的某个元素出现故障时，不得防止回退到MRHA隧道。
An RO mechanism MUST NOT add any new single point of failure for communications in general.
一般而言，RO机构不得为通信增加任何新的单点故障。
A need for high availability of connectivity to ground networks arises from the use of IP networking for carrying safety-of-life critical traffic. For this reason, single points of failure need to be avoided. If an RO solution assumes either a single onboard MR, a single HA, or some similar vulnerable point, and is not usable when the network includes standard reliability mechanisms for routers, then the RO technique will not be acceptable. An RO solution also MUST NOT itself imply a single point of failure.
由于使用IP网络来承载生命关键流量的安全性，因此需要高可用性的地面网络连接。因此，需要避免单点故障。如果RO解决方案假设单个板载MR、单个HA或某些类似的脆弱点，并且在网络包括路由器的标准可靠性机制时不可用，则RO技术将不可接受。RO解决方案本身也不得意味着单点故障。
This requirement specifies that the RO solution itself does not create any great new fragility. Although in basic Mobile IPv6 and NEMO deployments, the use of a single HA implies a single point of failure, there are mechanisms enabling the redundancy of HAs (e.g., [16]). It is assumed that some HA-redundancy techniques would be employed to increase robustness in an aeronautical setting. It should also be understood that the use of RO techniques decreases dependence on HAs in the infrastructure and allows a certain level of robustness to HA failures in that established sessions using RO may
该要求规定RO解决方案本身不会产生任何新的巨大脆弱性。尽管在基本的移动IPv6和NEMO部署中，使用单个HA意味着单点故障，但存在实现HA冗余的机制（例如，[16]）。假设将采用一些HA冗余技术来提高航空环境中的鲁棒性。还应理解，RO技术的使用减少了对基础设施中HA的依赖，并允许在使用RO的已建立会话中对HA故障具有一定程度的鲁棒性
be able to operate based on Binding Cache entries even after an HA failure. With RO, an HA failure primarily impacts the ability to connect new application flows to a mobile network.
即使在HA故障后，也能够基于绑定缓存项进行操作。对于RO，HA故障主要影响将新应用程序流连接到移动网络的能力。
If a failure occurs in a path selected by an RO technique, then that RO technique MUST NOT prevent fallback to the MRHA path for affected traffic.
如果故障发生在RO技术选择的路径中，则RO技术不得阻止受影响流量回退到MRHA路径。
This does not mention specific redundancy mechanisms for MRs, HAs, or other networking elements, so as long as some reasonable method for making each component redundant fits within the assumptions of the RO mechanism, this requirement can be considered satisfied.
这并未提及MRs、HAs或其他网络元件的具体冗余机制，因此，只要使每个组件冗余的合理方法符合RO机制的假设，就可以认为满足该要求。
There is no intention to support "Internet-less" operation through this requirement. When an MR is completely disconnected from the majority of the network with which it is intended to communicate, including its HA, there is no requirement for it to be able to retain any communications involving parties outside the mobile networks managed by itself.
我们无意通过此要求支持“无互联网”运营。当MR完全断开与其计划通信的大部分网络（包括其HA）的连接时，不要求MR能够保留涉及自身管理的移动网络以外各方的任何通信。
This requirement was derived from ICAO's TC-4 - "The approach should have high availability which includes not having a single point of failure."
该要求源自国际民航组织的TC-4——“该方法应具有高可用性，包括不存在单点故障。”
An RO scheme SHOULD NOT cause either loss or duplication of data packets during RO path establishment, usage, or transition, above that caused in the NEMO basic support case. An RO scheme MUST NOT itself create non-transient losses and duplications within a packet stream.
RO方案不应在RO路径建立、使用或转换过程中造成数据包丢失或重复，而不是在NEMO基本支持案例中造成的数据包丢失或重复。RO方案本身不得在数据包流中造成非暂时性丢失和重复。
It is possible that some RO schemes could cause data packets to be lost during transitions in RO state or due to unforeseen packet filters along the RO-selected path. This could be difficult for an application to detect and respond to in time. For this reason, an RO scheme SHOULD NOT cause packets to be dropped at any point in operation, when they would not normally have been dropped in a non-RO configuration.
一些RO方案可能会导致数据包在RO状态的转换期间丢失，或者由于RO选择路径上未预见的包过滤器而丢失。这对于应用程序来说可能很难及时检测和响应。因此，当数据包在非RO配置中通常不会被丢弃时，RO方案不应导致数据包在运行中的任何点被丢弃。
As an attempt at optimizing against packet loss, some techniques may, for some time, duplicate packets sent over both the MRHA tunnel and the optimized path. If this results in duplicate packets being delivered to the application, this is also unacceptable.
作为针对分组丢失进行优化的尝试，一些技术可能在一段时间内重复通过MRHA隧道和优化路径发送的分组。如果这导致向应用程序发送重复的数据包，这也是不可接受的。
This requirement does not necessarily imply make-before-break in transitioning between links. The intention is that during the handoff period, the RO scheme itself should not produce losses (or duplicates) that would not have occurred if RO had been disabled.
这一要求并不一定意味着链接之间的先接通后接通转换。其目的是在切换期间，RO方案本身不应产生在RO被禁用时不会发生的损失（或重复）。
This requirement was derived from ICAO's TC-5 - "The approach should not negatively impact end-to-end data integrity, for example, by introducing packet loss during path establishment, handoff, or data transfer."
该要求源自国际民航组织的TC-5——“该方法不应对端到端数据完整性产生负面影响，例如，在路径建立、切换或数据传输过程中引入数据包丢失。”
It is understood that this may be a requirement that is not easily implementable with regards to RO. Furthermore Req1, Separability, may be sufficient in allowing loss-sensitive and duplicate-sensitive flows to take the MRHA path.
据了解，这可能是一项关于RO的要求，不容易实现。此外，Req1（可分性）可能足以允许损失敏感和重复敏感流采用MRHA路径。
An RO scheme MUST be simultaneously usable by the MNNs on hundreds of thousands of craft without overloading the ground network or routing system. This explicitly forbids injection of BGP routes into the global Internet for purposes of RO.
反渗透方案必须能同时由MNN在几十万艘飞船上使用，而不会使地面网络或路由系统过载。这明确禁止出于RO目的将BGP路由注入全球互联网。
Several thousand aircraft may be in operation at some time, each with perhaps several hundred MNNs onboard. The number of active spacecraft using IP will be multiple orders of magnitude smaller than this over at least the next decade, so the aeronautical needs are more stringent in terms of scalability to large numbers of MRs. It would be a non-starter if the combined use of an RO technique by all of the MRs in the network caused ground networks provisioned within the realm of typical long-haul private telecommunications networks (like the FAA's Telecommunications Infrastructure (FTI) or the NASA Integrated Services Network (NISN)) to be overloaded or melt-down under the RO signaling load or amount of rapid path changes for multiple data flows.
数千架飞机可能在某一时间投入运行，每架飞机上可能有数百架MNN。至少在未来十年内，使用IP的主动航天器数量将比这少几个数量级，因此，航空需求在可扩展到大量MRs方面更为严格。如果网络中所有MRs联合使用RO技术导致在典型的长途专用电信网络范围内提供地面网络，则这将是不可能的（如美国联邦航空局的电信基础设施（FTI）或美国宇航局综合服务网络（NISN））在RO信令负载或多个数据流的快速路径变化量下过载或崩溃。
Thus, an RO scheme MUST be simultaneously usable by the MNNs on hundreds of thousands of craft without overloading the ground network or routing system. The scheme must also be tolerant to the delay and/or loss of initial packets, which may become more pervasive in future Internet routing and addressing architectures [17].
因此，一个RO方案必须能同时被MNN在几十万艘飞船上使用，而不会使地面网络或路由系统过载。该方案还必须能够容忍初始数据包的延迟和/或丢失，这可能在未来的互联网路由和寻址架构中变得更加普遍[17]。
Since at least one traffic domain (PIES) requires connectivity to the Internet and it is possible that the Internet would provide transport for other domains at some distant point in the future, this requirement explicitly forbids the use of techniques that are known to scale poorly in terms of their global effects, like BGP, for the
由于至少有一个流量域（PIE）需要连接到Internet，并且将来Internet可能会在某个遥远的地点为其他域提供传输，因此该要求明确禁止使用已知在其全球影响方面伸缩性较差的技术，如BGP，用于
purposes of RO. The previous OSI-based ATN system used IDRP and an "island" concept for maintaining connectivity to the mobile network but was not tested on a large scale deployment. The Connexion by Boeing system used BGP announces and withdrawals as a plane moved across the globe in order to maintain connectivity [10]. This was found to contribute to a significant amount of churn in the global Internet routing tables, which is undesirable for a number of reasons, and must be avoided in the future.
反洗钱的目的。以前基于OSI的ATN系统使用IDRP和“孤岛”概念来维持与移动网络的连接，但没有在大规模部署中进行测试。波音系统使用BGP进行连接，当飞机在全球移动以保持连接时，BGP进行宣布和撤回[10]。人们发现，这导致了全球互联网路由表中大量的搅动，由于许多原因，这是不可取的，今后必须避免。
This requirement was derived from ICAO's TC-6 - "The approach should be scalable to accommodate anticipated levels of aircraft equipage."
该要求源自国际民航组织的TC-6——“该方法应可扩展，以适应飞机装备的预期水平。”
The specific scaling factor for the number of aircraft used in our version of the requirement is an order of magnitude larger than the estimated equipage cited in an ICAO draft letter-of-intent to ARIN for an IPv6 prefix allocation request. There were several other estimates that different groups had made, and it was felt in the IETF that using a larger estimate was more conservative. It should be noted that even with this difference of an order of magnitude, the raw number is still several orders of magnitude lower than that of estimated cellular telephone users, which might use the same protocol enhancements as the cellular industry has also adopted Mobile IP standards.
我们版本的要求中使用的飞机数量的具体比例因子比国际民航组织向ARIN提交的IPv6前缀分配请求意向书草案中引用的估计设备数量大一个数量级。不同的团体还做出了一些其他的估计，IETF认为使用更大的估计更保守。应该注意的是，即使存在一个数量级的差异，原始数字仍然比估计的蜂窝电话用户低几个数量级，因为蜂窝电话用户可能使用与蜂窝行业也采用移动IP标准相同的协议增强功能。
An RO scheme MUST be capable of efficient signaling in terms of both size and number of individual signaling messages and the ensemble of signaling messages that may simultaneously be triggered by concurrent flows.
RO方案必须能够在单个信令消息的大小和数量以及可由并发流同时触发的信令消息的集合方面进行有效信令。
The amount of bandwidth available for aeronautical and space communications has historically been quite small in comparison to the desired bandwidth (e.g., in the case of VDL links, the bandwidth is 8 kbps of shared resources). This situation is expected to persist for at least several more years. Links tend to be provisioned based on estimates of application needs (which could well prove wrong if either demand or the applications in use themselves do not follow expectations) and do not leave much room for additional networking protocol overhead. Since every byte of available air-ground link capacity that is used by signaling for NEMO RO is likely to delay bytes of application data and reduce application throughput, it is important that the NEMO RO scheme's signaling overhead scales up much more slowly than the throughput of the flows RO is being performed
与期望带宽相比，航空和空间通信的可用带宽量在历史上一直非常小（例如，在VDL链路的情况下，共享资源的带宽为8 kbps）。这种情况预计至少还会持续几年。链路往往是根据应用程序需求的估计来配置的（如果需求或使用中的应用程序本身不符合预期，则很可能证明这是错误的），并且不会为额外的网络协议开销留下太多空间。由于NEMO RO信令使用的可用空地链路容量的每个字节都可能延迟应用数据的字节并降低应用吞吐量，因此，NEMO RO方案的信令开销比正在执行的RO流的吞吐量增长得慢得多是很重要的
on. This way, as higher-rate data links are deployed along with more bandwidth-hungry applications, the NEMO RO scheme will be able to safely be discounted in capacity planning.
在…上通过这种方式，随着更高速率数据链路的部署以及更高带宽需求的应用，NEMO RO方案将能够在容量规划中安全地折扣。
Note that in meeting this requirement, an RO technique must be efficient in both the size and number of individual messages that it sends, as well in the ensemble of messages sent at one time (for instance, to give RO to multiple ongoing flows following a handover), in order to prevent storms of packets related to RO.
请注意，在满足这一要求时，RO技术必须在其发送的单个消息的大小和数量以及在一次发送的消息集合（例如，在切换后向多个正在进行的流提供RO）方面有效，以防止与RO相关的包风暴。
This requirement was derived from ICAO's TC-7 - "The approach should result in throughput which accommodates anticipated levels of aircraft equipage."
这一要求源于国际民航组织的TC-7——“该方法的吞吐量应满足飞机装备的预期水平。”
For the ATS/AOS domains, there are three security sub-requirements:
对于ATS/AOS域，有三个安全子要求：
1. The RO scheme MUST NOT further expose MNPs on the wireless link than already is the case for NEMO basic support.
1. RO方案不得在无线链路上进一步公开MNP，而非NEMO基本支持的情况。
2. The RO scheme MUST permit the receiver of a binding update (BU) to validate an MR's ownership of the CoAs claimed by an MR.
2. RO方案必须允许绑定更新（BU）的接收者验证MR对MR声称的COA的所有权。
3. The RO scheme MUST ensure that only explicitly authorized MRs are able to perform a binding update for a specific MNP.
3. RO方案必须确保只有明确授权的MR才能对特定MNP执行绑定更新。
For the PIES domain, there are no additional requirements beyond those of normal Internet services and the same requirements for normal Mobile IPv6 RO apply.
对于PIES域，除正常互联网服务的要求外，没有其他要求，正常移动IPv6的要求也适用。
The security needs are fairly similar between ATS and AOS, but vary widely between the ATS/AOS domains and PIES. For PIES, the traffic flows are typical of terrestrial Internet use and the security requirements for RO are identical to those of conventional Mobile IPv6 RO. For ATS/AOS, however, there are somewhat more strict requirements, along with some safe assumptions that designers of RO schemes can make. Below, we describe each of these ATS/AOS issues, but do not further discuss PIES RO security.
ATS和AOS之间的安全需求相当相似，但在ATS/AOS域和PIE之间差异很大。对于PIE，流量流是典型的地面互联网使用，RO的安全要求与传统移动IPv6 RO相同。然而，对于ATS/AOS，有一些更严格的要求，以及RO方案设计者可以做出的一些安全假设。下面，我们将描述这些ATS/AOS问题，但不进一步讨论PIES RO安全。
The first security requirement is driven by concerns expressed by ATS communications engineers. The concern is driven by current air-ground links to a craft and their lack of security, which has allowed eavesdroppers to track individual flights in detail. Protecting the MNP from exposure has been expressed as a requirement by this community, though the security of the RO system should not depend on
第一个安全要求是由ATS通信工程师表达的担忧驱动的。这一担忧是由目前与飞机的空地连接以及缺乏安全性引起的，这使得窃听者能够详细追踪个别航班。尽管反渗透系统的安全性不应取决于
secrecy of the MNP. The RO scheme should use some reasonable security mechanisms in order to both protect RO signaling via strong authentication and encrypt the MNP from being visible over air-ground links.
MNP的保密性。RO方案应使用一些合理的安全机制，以便通过强身份验证保护RO信令，并加密MNP，使其在空地链路上不可见。
The second security requirement is driven by the risk of flooding attacks that are started by an attacker redirecting an MNP's traffic to some target victim CoA. To protect bindings to bogus CoAs from being sent, the RO scheme must somehow validate that an MR actually possesses any CoAs that it claims. For the purposes of aeronautics, it is safe to assume ingress filtering is in place in the access networks.
第二个安全需求是由攻击者将MNP的流量重定向到某个目标受害者CoA时发起的洪水攻击风险驱动的。为了防止发送到伪造CoA的绑定，RO方案必须以某种方式验证MR是否实际拥有其声称的任何CoA。出于航空目的，可以安全地假设接入网络中存在入口过滤。
To protect against "rogue" MRs or abuse of compromised MRs, the RO scheme MUST be capable of checking that an MR is actually authorized to perform a binding update for a specific MNP. To meet this requirement, it can be assumed that some aeronautical organization authority exists who can provide the required authorization, possibly in the form of a certificate that the MR possesses, signed by the aeronautical authority.
为了防止“流氓”MRs或滥用受损MRs，RO方案必须能够检查MR是否实际被授权为特定MNP执行绑定更新。为了满足这一要求，可以假设存在能够提供所需授权的航空组织机构，可能以MR拥有的证书的形式，由航空机构签署。
It is also reasonable to assume trust relationships between each MR and a number of mobility anchor points topologically near to its CNs (these anchor points may be owned by the service providers), but it is not reasonable to assume that trust relationships can be established between an MR and any given CN itself. Within the onboard networks for ATS and AOS, it is reasonable to assume that the LFNs and MRs have some trust relationship.
假设每个MR和拓扑上靠近其CNs的多个移动锚定点之间存在信任关系也是合理的（这些锚定点可能由服务提供商拥有），但假设MR和任何给定CN本身之间可以建立信任关系是不合理的。在ATS和AOS的车载网络中，可以合理地假设LFN和MRs具有某种信任关系。
It is felt by many individuals that by the time the IP-based ATN grows into production use, there will be a global ATN-specific Public Key Infrastructure (PKI) usable for ATS, though it is agreed that such a PKI does not currently exist and will take time to develop both technically and politically. This PKI could permit the establishment of trust relationships among any pair of ATS MNNs, MRs, or CNs through certificate paths, in contrast to the more limited amount of trust relationships described in the previous paragraph. While it has been suggested that early test and demonstration deployments with a more limited-scale PKI deployment can be used in the near-term, as a global PKI is developed, some parties still feel that assuming a global PKI may be overly bold in comparison to assuming trust relationships with anchor points. It is always possible to scale the anchor point assumption up if a PKI develops that allows the CNs themselves to become the anchor points. It is not possible to go back down in the other direction if a global PKI never emerges.
许多人认为，当基于IP的ATN发展成为生产使用时，将有一个全球特定于ATN的公钥基础设施（PKI）可用于ATS，尽管人们一致认为目前不存在这样的PKI，并且需要时间来开发技术和政治。此PKI可允许通过证书路径在任何一对ATS MNN、MRs或CNs之间建立信任关系，这与上一段中描述的数量有限的信任关系不同。虽然有人建议，短期内可以使用规模更有限的PKI部署的早期测试和演示部署，但随着全球PKI的发展，一些缔约方仍然认为，与假设与锚定点的信任关系相比，假设全球PKI可能过于大胆。如果PKI的发展允许CNs本身成为锚定点，则始终可以扩大锚定点假设。如果全球PKI从未出现，那么就不可能回到另一个方向。
This requirement was extrapolated from ICAO's TC-8 - "The approach should be secure" and made more specific with help from the MEXT working group.
这一要求是根据国际民航组织的TC-8“方法应安全”推断出来的，并在MEXT工作组的帮助下变得更加具体。
Applications using new transport protocols, IPsec, or new IP options MUST be possible within an RO scheme.
使用新传输协议、IPsec或新IP选项的应用程序必须能够在RO方案中使用。
The concepts of operations are not fully developed for network-centric command and control and other uses of IP-based networks in aeronautical and space environments. The exact application protocols, data flow characteristics, and even transport protocols that will be used in either transitional or final operational concepts are not completely defined yet, and may even change with deployment experience. The RO solution itself should allow all higher-layer protocols, ports, and options to be used.
作战概念尚未完全针对以网络为中心的指挥和控制以及航空和航天环境中基于IP的网络的其他用途而制定。过渡或最终作战概念中使用的确切应用程序协议、数据流特征甚至传输协议尚未完全定义，甚至可能随着部署经验而改变。RO解决方案本身应允许使用所有高层协议、端口和选项。
This requirement was derived from ICAO's TC-9 - "The approach should be scalable to accommodate anticipated transition to new IP-based communication protocols."
这一要求源自国际民航组织的TC-9——“该方法应具有可扩展性，以适应向基于IP的新通信协议的预期过渡。”
In this section, we identify some of the properties of the system that are not strict requirements due to either being difficult to quantify or to being features that are not immediately needed, but that may provide additional benefits that would help encourage adoption.
在本节中，我们确定了系统的一些特性，这些特性不是严格的要求，因为它们要么难以量化，要么是不立即需要的特性，但可能提供额外的好处，有助于鼓励采用。
For ATS systems, complex configurations are known to increase uncertainty in context, human error, and the potential for reaching undesirable (unsafe) states [18]. Since RO alters the communications context between an MNN and CN, it is desirable that a NEMO RO solution be as simple to configure as possible and also easy to automatically disable if an undesirable state is reached.
对于ATS系统，已知复杂的配置会增加上下文的不确定性、人为错误以及达到不期望（不安全）状态的可能性[18]。由于反渗透改变了MNN和CN之间的通信环境，因此NEMO反渗透解决方案应尽可能简单地配置，并且在达到不希望的状态时也易于自动禁用。
For CNs at large airports, the Binding Cache state management functions may be simultaneously dealing with hundreds of airplanes with multiple service providers and a volume of mobility events due to arrivals and departures. The ability to have simple interfaces for humans to access the Binding Cache configuration and alter it in case of errors is desirable, if this does not interfere with the RO protocol mechanisms themselves.
对于大型机场的CNs，绑定缓存状态管理功能可能会同时处理数百架具有多个服务提供商的飞机以及因到达和离开而发生的大量机动性事件。如果不影响RO协议机制本身的话，那么人们可以使用简单的接口来访问绑定缓存配置，并在出现错误时对其进行更改。
It is desirable if the RO mechanism supports RO for nested MRs, since it is possible that, for PIES and astronaut spacesuits, PANs with MRs will need to be supported. For oceanic flight, ATS and AOS may also benefit from the capability of nesting MRs between multiple planes to provide a "reachback" to terrestrial ground stations rather than relying solely on lower rate HF or satellite systems. In either case, this mode of operation is beyond current strict requirements and is merely desirable. It is also noted that there are other ways to support these communications scenarios using routing protocols or other means outside of NEMO.
如果RO机构支持嵌套MRs的RO，这是可取的，因为对于PIE和宇航员宇航服，可能需要支持带有MRs的PAN。对于远洋飞行，ATS和AOS也可能受益于在多架飞机之间嵌套MRs的能力，从而为地面地面站提供“回程”，而不是仅仅依靠低速率HF或卫星系统。无论哪种情况，这种操作模式都超出了当前的严格要求，只是可取的。还需要注意的是，使用路由协议或NEMO以外的其他方式，还有其他方式来支持这些通信场景。
Loop-detection, in support of nesting, is specifically not a requirement at this stage of ATN and space network designs, due to both the expectation that the operational environments are carefully controlled and inherently avoid loops and the understanding that scenarios involving nesting are not envisioned in the near future.
在ATN和空间网络设计的这一阶段，支持嵌套的环路检测并不是一项具体要求，这是因为人们期望操作环境得到仔细控制，并从本质上避免环路，同时也认识到在不久的将来不会设想涉及嵌套的场景。
Low complexity in systems engineering and configuration management is desirable in building and maintaining systems using the RO mechanism. This property may be difficult to quantify, judge, and compare between different RO techniques, but a mechanism that is perceived to have lower impact on the complexity of the network communications system should be favored over an otherwise equivalent mechanism (with regards to the requirements listed above). This is somewhat different than Des1 (Configuration), in that Des1 refers to operation and maintenance of the system once deployed, whereas Des3 is concerned with the initial design, deployment, transition, and later upgrade path of the system.
在使用RO机制构建和维护系统时，需要系统工程和配置管理的低复杂性。该特性可能难以在不同RO技术之间进行量化、判断和比较，但认为对网络通信系统复杂性影响较小的机制应优于其他等效机制（关于上述要求）。这与Des1（配置）有些不同，因为Des1指的是部署后系统的操作和维护，而Des3则涉及系统的初始设计、部署、转换和后续升级路径。
At least LFNs MUST be supported by a viable RO solution for aeronautics, as these local nodes are within the ATS and AOS domains. If Mobile IPv6 becomes a popular technology used by portable consumer devices, VMNs within the PIES domain are expected to be numerous, and it is strongly desirable for them to be supported by the RO technique, but not strictly required. LMNs are potentially present in future space exploration scenarios, such as manned exploration missions to the moon and Mars.
至少LFN必须由可行的航空RO解决方案支持，因为这些本地节点位于ATS和AOS域内。如果移动IPv6成为便携式消费设备使用的一种流行技术，那么PIES域中的虚拟机网络将是众多的，并且强烈希望它们能够得到RO技术的支持，但不是严格要求。LMN可能出现在未来的空间探索场景中，例如载人月球和火星探测任务。
An RO mechanism that is "general purpose", in that it is also readily usable in other contexts outside of aeronautics and space exploration, is desirable. For instance, an RO solution that is usable within Vehicular ad hoc Networks (VANETs) [19] or consumer electronics equipment [20] could satisfy this. The goal is for the technology to be more widely used and maintained outside the relatively small aeronautical networking community and its vendors, in order to make acquisitions and training faster, easier, and cheaper. This could also allow aeronautical networking to possibly benefit from future RO scheme optimizations and developments whose research and development is funded and performed externally by the broader industry and academic communities.
一种“通用”的反渗透机制是可取的，因为它在航空和空间探索以外的其他环境中也很容易使用。例如，可在车辆自组织网络（VANET）[19]或消费电子设备[20]中使用的RO解决方案可以满足这一要求。目标是在相对较小的航空网络社区及其供应商之外更广泛地使用和维护该技术，以便更快、更容易和更便宜地进行收购和培训。这也可能使航空网络可能受益于未来反渗透方案的优化和开发，其研发由更广泛的行业和学术界外部资助和执行。
This document does not create any security concerns in and of itself. The security properties of any NEMO RO scheme that is to be used in aeronautics and space exploration are probably much more stringent than for more general NEMO use, due to the safety-of-life and/or national security issues involved. The required security properties are described under Req8 of Section 3 within this document.
本文件本身不存在任何安全问题。由于涉及生命安全和/或国家安全问题，航空和空间探索中使用的任何NEMO RO方案的安全性能可能比更一般的NEMO使用要严格得多。本文件第3节要求8中描述了所需的安全属性。
Under an assumption of closed and secure backbone networks, the air-ground link is the weakest portion of the network and most susceptible to injection of packets, flooding, and other attacks. Future air-ground data links that will use IP are being developed with link-layer security as a concern. This development can assist in meeting one of this document's listed security requirements (that MNPs not be exposed on the wireless link), but the other requirements affect the RO technology more directly without regard to the presence or absence of air-ground link-layer security.
在封闭且安全的主干网络的假设下，空地链路是网络中最薄弱的部分，最容易受到数据包注入、洪水和其他攻击。未来将使用IP的空地数据链路正在开发中，链路层安全是一个考虑因素。此项开发有助于满足本文件列出的安全要求之一（MNP不得暴露在无线链路上），但其他要求更直接地影响RO技术，而不考虑是否存在空地链路层安全。
When deploying in operational networks where network-layer security may be mandated (e.g., virtual private networks), the interaction between this and NEMO RO techniques should be carefully considered to ensure that the security mechanisms do not undo the route optimization by forcing packets through a less optimal overlay or underlay. For instance, when IPsec tunnel use is required, the locations of the tunnel endpoints can force sub-optimal end-to-end paths to be taken.
在可能要求网络层安全的运营网络（例如，虚拟专用网络）中部署时，应仔细考虑此技术与NEMO RO技术之间的交互作用，以确保安全机制不会通过强制数据包通过不太理想的覆盖层或底层来撤销路由优化。例如，当需要使用IPsec隧道时，隧道端点的位置可以强制采用次优的端到端路径。
Input from several parties is indirectly included in this document. Participants in the Mobile Platform Internet (MPI) mailing list and BoF efforts helped to shape the document, and the early content was
本文件间接包含了多方的意见。移动平台互联网（MPI）邮件列表和BoF工作的参与者帮助形成了该文档，早期内容是
borrowed from MPI problem statement and proposed requirements documents ([21], [13]). The NEMO and MONAMI6 working group participants were instrumental in completing this document. The participants in the MEXT interim meeting February 7th and 8th of 2008 in Madrid were critical in solidifying these requirements. Specific suggestions from Steve Bretmersky, Thierry Ernst, Tony Li, Jari Arkko, Phillip Watson, Roberto Baldessari, Carlos Jesus Bernardos Cano, Eivan Cerasi, Marcelo Bagnulo, Serkan Ayaz, Christian Bauer, Fred Templin, Alexandru Petrescu, Tom Henderson, and Tony Whyman were incorporated into this document.
借用MPI问题陈述和建议要求文件（[21]，[13]）。NEMO和MONAMI6工作组的参与者在完成本文件方面发挥了重要作用。2008年2月7日和8日在马德里举行的MEXT临时会议的与会者对于巩固这些要求至关重要。Steve Bretmersky、Thierry Ernst、Tony Li、Jari Arkko、Phillip Watson、Roberto Baldessari、Carlos Jesus Bernardos Cano、Eivan Cerasi、Marcelo Bagnulo、Serkan Ayaz、Christian Bauer、Fred Templin、Alexandru Petrescu、Tom Henderson和Tony Whyman提出的具体建议已纳入本文件。
Wesley Eddy's work on this document was performed at NASA's Glenn Research Center, primarily in support of NASA's Advanced Communications Navigations and Surveillance Architectures and System Technologies (ACAST) project, and the NASA Space Communications Architecture Working Group (SCAWG) in 2005 and 2006.
Wesley Eddy在美国宇航局格伦研究中心完成了关于本文件的工作，主要是为了支持美国宇航局先进通信导航和监视体系结构与系统技术（ACAST）项目，以及2005年和2006年的美国宇航局空间通信体系结构工作组（SCAWG）。
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[1] Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[4] Ernst，T.和H-Y.Lach，“网络移动支持术语”，RFC 48852007年7月。
[5] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
[5] Ernst，T.，“网络移动性支持目标和要求”，RFC 48862007年7月。
[6] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
[6] Ng，C.，Thubert，P.，Watari，M.，和F.Zhao，“网络移动路径优化问题声明”，RFC 4888，2007年7月。
[7] ICAO Asia/Pacific Regional Office, "Required Communication Performance (RCP) Concepts - An Introduction", Informal South Pacific ATS Coordinating Group 20th meeting, Agenda Item 7, January 2006.
[7] 国际民航组织亚太区域办事处，“所需通信性能（RCP）概念——介绍”，南太平洋ATS协调小组第20次非正式会议，议程项目7，2006年1月。
[8] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007.
[8] Ng，C.，Zhao，F.，Watari，M.，和P.Thubert，“网络移动路径优化解决方案空间分析”，RFC 4889，2007年7月。
[9] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.
[9] Kempf，J.，“基于网络的本地化移动性管理（NETLMM）的目标”，RFC 48312007年4月。
[10] Dul, A., "Global IP Network Mobility", Presentation at IETF 62 Plenary, March 2005.
[10] Dul，A.，“全球IP网络移动性”，在IETF 62全体会议上的演讲，2005年3月。
[11] Ivancic, W., Paulsen, P., Stewart, D., Shell, D., Wood, L., Jackson, C., Hodgson, D., Northam, J., Bean, N., Miller, E., Graves, M., and L. Kurisaki, "Secure, Network-centric Operations of a Space-based Asset: Cisco Router in Low Earth Orbit (CLEO) and Virtual Mission Operations Center (VMOC)", NASA Technical Memorandum TM-2005-213556, May 2005.
[11] Ivancic，W.，Paulsen，P.，Stewart，D.，Shell，D.，Wood，L.，Jackson，C.，Hodgson，D.，Northam，J.，Bean，N.，Miller，E.，Graves，M.，和L.Kurisaki，“天基资产的安全、以网络为中心的操作：近地轨道思科路由器（CLEO）和虚拟任务操作中心（VMOC）”，NASA技术备忘录TM-2005-213556，2005年5月。
[12] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007.
[12] Ng，C.，Ernst，T.，Paik，E.，和M.Bagnulo，“网络移动性支持中的多宿分析”，RFC 49802007年10月。
[13] Davis, T., "Mobile Internet Platform Aviation Requirements", Work in Progress, September 2006.
[13] Davis，T.，“移动互联网平台航空要求”，正在进行的工作，2006年9月。
[14] ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, January 2007.
[14] 国际民航组织工作组N SWG1，“候选ATN IPS移动解决方案分析”，第12次会议，工作文件6，泰国曼谷，2007年1月。
[15] Davis, T., "Aviation Global Internet Operations Requirements", ICAO WG-N, Sub-Working-Group N1, Information Paper #4 (IP4), September 2006.
[15] Davis，T.，“航空全球互联网运营要求”，国际民航组织工作组N，N1小组，信息文件4（IP4），2006年9月。
[16] Wakikawa, R., "Home Agent Reliability Protocol", Work in Progress, July 2009.
[16] Wakikawa，R.，“家庭代理可靠性协议”，正在进行的工作，2009年7月。
[17] Zhang, L. and S. Brim, "A Taxonomy for New Routing and Addressing Architecture Designs", Work in Progress, March 2008.
[17] Zhang，L.和S.Brim，“新路由和寻址架构设计的分类法”，正在进行的工作，2008年3月。
[18] ICAO, "Threat and Error Management (TEM) in Air Traffic Control", ICAO Preliminary Edition, October 2005.
[18] 国际民航组织，“空中交通管制中的威胁和错误管理”，国际民航组织初版，2005年10月。
[19] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route Optimization", Work in Progress, July 2007.
[19] Baldessari，R.，“C2C-C财团对NEMO路线优化的要求”，正在进行的工作，2007年7月。
[20] Ng, C., "Consumer Electronics Requirements for Network Mobility Route Optimization", Work in Progress, February 2008.
[20] Ng，C.，“网络移动性路由优化的消费电子要求”，正在进行的工作，2008年2月。
[21] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", Work in Progress, September 2006.
[21] Ivancic，W.，“多域、多宿移动网络”，进展中的工作，2006年9月。
[22] CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 000.0-G-1 Draft Green Book, December 2006.
[22] CCSDS，“中环月球空间互联：架构”，CCCSDS 000.0-G-1绿皮书草案，2006年12月。
[23] NASA Space Communication Architecture Working Group, "NASA Space Communication and Navigation Architecture Recommendations for 2005-2030", SCAWG Final Report, May 2006.
[23] NASA空间通信架构工作组，“NASA 2005-2030年空间通信和导航架构建议”，SCAWG最终报告，2006年5月。
The current standards for aeronautical networking are based on the ISO OSI networking stack and are referred to as the Aeronautical Telecommunications Network (ATN). While standardized, the ATN has not been fully deployed and seems to be in only limited use compared to its full vision and potential. The International Civil Aviation Organization (ICAO) is a part of the United Nations that produces standards for aeronautical communications. The ICAO has recognized that an ATN based on OSI lacks the widespread commercial network support required for the successful deployment of new, more bandwidth-intensive ATN applications, and has recently been working towards a new IPv6-based version of the ATN.
当前的航空网络标准基于ISO OSI网络栈，称为航空电信网络（ATN）。虽然标准化，但ATN尚未完全部署，与其全部愿景和潜力相比，其使用似乎有限。国际民用航空组织（ICAO）是联合国的一部分，负责制定航空通信标准。国际民航组织已经认识到，基于OSI的ATN缺乏成功部署新的、带宽更密集的ATN应用所需的广泛商业网络支持，并且最近一直在努力开发新的基于IPv6的ATN版本。
Supporting mobility in an IP-based network may be vastly different than it is in the OSI-based ATN, which uses the Inter-Domain Routing Protocol (IDRP) to recompute routing tables as mobile networks change topological points of attachment. ICAO recognizes this and has studied various mobility techniques based on link, network, transport, routing, and application protocols [14].
在基于IP的网络中支持移动性可能与在基于OSI的ATN中支持移动性大不相同，后者使用域间路由协议（IDRP）在移动网络改变拓扑连接点时重新计算路由表。国际民航组织认识到这一点，并研究了基于链路、网络、传输、路由和应用协议的各种移动技术[14]。
Work done within ICAO has identified the NEMO technology as a promising candidate for use in supporting global, IP-based mobile networking. The main concerns with NEMO have been with its current lack of route optimization support and its potentially complex configuration requirements in a large airport environment with multiple service providers and 25 or more airlines sharing the same infrastructure.
国际民航组织内部所做的工作表明，NEMO技术是支持基于IP的全球移动网络的一个有希望的候选技术。NEMO的主要关注点在于，在多个服务提供商和25家或更多航空公司共享同一基础设施的大型机场环境中，NEMO目前缺乏航线优化支持，其配置要求可能很复杂。
A significant challenge to the deployment of networking technologies to aeronautical users is the low capability of existing air-ground data links for carrying IP-based (or other) network traffic. Due to barriers of spectrum and certification, production of new standards and equipment for the lower layers below IP is slow. Currently operating technologies may have data rates measured in the several kbps range, and it is clear that supporting advanced IP-based applications will require new link technologies to be developed simultaneously with the development of networking technologies appropriate for aeronautics.
向航空用户部署网络技术的一个重大挑战是现有空地数据链路承载基于IP（或其他）网络流量的能力较低。由于频谱和认证的障碍，IP以下较低层的新标准和设备的生产缓慢。目前运行的技术可能在数kbps范围内测量数据速率，很明显，支持基于IP的高级应用程序将需要在开发适用于航空的网络技术的同时开发新的链路技术。
In addition to well-known commercial data links that can be adapted for aeronautical use, such as Wideband Code-Division Multiple Access (WCDMA) standards or the IEEE 802.16 standard, several more specialized technologies either exist or have been proposed for air-ground use:
除了可适用于航空用途的众所周知的商业数据链路，例如宽带码分多址（WCDMA）标准或IEEE 802.16标准，还存在或已提出了几种更专门的技术用于空地使用：
o VHF Data Link (VDL) specifies four modes of operation in the 117.975 - 137 MHz range that are capable of supporting different mixes of digital voice and data at fairly low rates. The low rates are driven by the need to operate within 25 kHz channels internationally allocated for aeronautical use. VDL mode 2 is somewhat widely deployed on aircraft and two global service providers support VDL access networks. Experiences with VDL mode 2 indicate that several kbps of capacity delivered to a craft can be expected in practice, and the use of long timers and a collision avoidance algorithm over a large physical space (designed to operate at 200 nautical miles) limit the performance of IP-based transport protocols and applications.
o VHF数据链路（VDL）规定了117.975-137 MHz范围内的四种操作模式，能够以相当低的速率支持数字语音和数据的不同混合。低速率的驱动因素是需要在国际上分配用于航空用途的25 kHz信道内工作。VDL模式2在飞机上广泛部署，两个全球服务提供商支持VDL接入网络。VDL模式2的经验表明，在实践中可以预期交付给飞行器的容量为数kbps，并且在大物理空间（设计为在200海里运行）上使用长定时器和防撞算法限制了基于IP的传输协议和应用程序的性能。
o Aircraft Communications and Reporting System (ACARS) is a messaging system that can be used over several types of underlying RF data links (e.g., VHF, HF, and satellite relay). ACARS messaging automates the sending and processing of several types of event notifications over the course of a flight. ACARS in general is a higher-level messaging system, whereas the more specific "Plain Old ACARS" (POA) refers to a particular legacy RF interface that the ACARS system employed prior to the adoption of VDL and other data links. Support for IP-based networking and advanced applications over POA is not feasible.
o 飞机通信和报告系统（ACARS）是一种信息系统，可通过多种类型的底层射频数据链路（如VHF、HF和卫星中继）使用。ACARS消息传递可在飞行过程中自动发送和处理多种类型的事件通知。ACARS通常是一个更高级别的消息传递系统，而更具体的“普通旧ACARS”（POA）是指ACARS系统在采用VDL和其他数据链路之前使用的特定传统射频接口。通过POA支持基于IP的网络和高级应用程序是不可行的。
o Broadband Aeronautical Multi-carrier Communications (B-AMC) is a hybrid cellular system that uses multi-carrier CDMA from ground-to-air and Orthogonal Frequency Division Multiplexing (OFDM) in the air-to-ground direction. B-AMC runs in the L-band of spectrum and is adapted from the Broadband-VHF (B-VHF) technology originally developed to operate in the VHF spectrum. L-band use is intended to occupy the space formerly allocated for Distance Measuring Equipment (DME) using channels with greater bandwidth than are available than in the VHF band, where analog voice use will continue to be supported. B-AMC may permit substantially higher data rates than existing deployed air-ground links.
o 宽带航空多载波通信（B-AMC）是一种混合蜂窝系统，它使用地对空的多载波CDMA和空对地方向的正交频分复用（OFDM）。B-AMC在L波段频谱中运行，并根据最初开发用于在VHF频谱中运行的宽带VHF（B-VHF）技术进行调整。L波段的使用旨在占用以前分配给测距设备（DME）的空间，该设备使用的信道的带宽大于VHF波段的可用带宽，VHF波段将继续支持模拟语音使用。B-AMC可能允许比现有部署的空地链路更高的数据速率。
o All-Purpose Multi-Channel Aviation Communications System (AMACS) is an adaptation of the Global System for Mobile Communications (GSM) physical layer to operate in the L-band with 50 - 400 kHz channels and use VDL mode 4's media access technique. AMACS may permit data rates in the several hundred kbps range, depending on specific channelization policies deployed.
o 通用多信道航空通信系统（AMACS）是全球移动通信系统（GSM）物理层的一种改编，可在L波段50-400 kHz信道中运行，并使用VDL模式4的媒体接入技术。根据部署的特定信道化策略，AMAC可能允许几百kbps范围内的数据速率。
o Project 34 (P34) is a wideband public-safety radio system capable of being used in the L-band. P34 is designed to offer several hundred kbps of capacity specifically for IP-based packet networking. It uses OFDM in 50, 100, or 150 kHz channels and
o 项目34（P34）是一个能够在L波段使用的宽带公共安全无线电系统。P34专门为基于IP的数据包网络提供数百kbps的容量。它在50、100或150 kHz信道中使用OFDM，并且
exact performance will depend on the particular operating band, range (guard time), and channelization plan configured in deployment.
准确的性能将取决于部署中配置的特定工作频段、范围（保护时间）和信道化计划。
o L-Band Data Link (LDL) is another proposal using the L-band based on existing technologies. LDL adapts the VDL mode 3 access technique and is expected to be capable of up to 100 kbps.
o L波段数据链路（LDL）是另一个基于现有技术使用L波段的方案。LDL采用VDL模式3访问技术，预计能够达到100Kbps。
IP itself is only in limited operational use for communicating with spacecraft currently (e.g., the Surry Satellite Technology Limited (SSTL) Disaster Monitoring Constellation (DMC) satellites). Future communications architectures include IP-based networking as an essential building block, however. The Consultative Committee for Space Data Systems (CCSDS) has a working group that is producing a network architecture for using IP-based communications in both manned and unmanned near-Earth missions, and has international participation towards this goal [22]. NASA's Space Communications Architecture Working Group (SCAWG) also has developed an IP-based multi-mission networking architecture [23]. Neither of these is explicitly based on Mobile IP technologies, but NEMO is usable within these architectures and they may be extended to include NEMO when/if the need becomes apparent.
IP本身目前仅用于与航天器通信的有限操作用途（例如，Surry卫星技术有限公司（SSTL）灾害监测星座（DMC）卫星）。然而，未来的通信体系结构将基于IP的网络作为一个基本构建块。空间数据系统协商委员会（CCSDS）有一个工作组，该工作组正在为载人和无人近地飞行任务中使用基于IP的通信制定一个网络架构，并在国际上参与实现这一目标[22]。NASA的空间通信体系结构工作组（SCAWG）还开发了一种基于IP的多任务网络体系结构[23]。这两种技术都没有明确基于移动IP技术，但NEMO在这些体系结构中是可用的，并且当/如果需求变得明显时，可以将其扩展到包括NEMO。
Authors' Addresses
作者地址
Wesley M. Eddy Verizon Federal Network Systems NASA Glenn Research Center 21000 Brookpark Road, MS 54-5 Cleveland, OH 44135 USA
美国俄亥俄州克利夫兰市布鲁克帕克路21000号韦斯利·M·埃迪·威瑞森联邦网络系统NASA格伦研究中心，邮编：44135
EMail: weddy@grc.nasa.gov
EMail: weddy@grc.nasa.gov
Will Ivancic NASA Glenn Research Center 21000 Brookpark Road, MS 54-5 Cleveland, OH 44135 USA
美国俄亥俄州克利夫兰布鲁克帕克路21000号伊万西奇NASA格伦研究中心，邮编：44135
Phone: +1-216-433-3494
EMail: William.D.Ivancic@grc.nasa.gov
Phone: +1-216-433-3494
EMail: William.D.Ivancic@grc.nasa.gov
Terry Davis Boeing Commercial Airplanes P.O.Box 3707 MC 0Y-96 Seattle, WA 98124-2207 USA
Terry Davis波音商用飞机美国华盛顿州西雅图3707 MC 0Y-96邮政信箱98124-2207
Phone: 206-280-3715 EMail: Terry.L.Davis@boeing.com
电话：206-280-3715电子邮件：Terry.L。Davis@boeing.com