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.
これらの要件への実質的な入力は、国際民間航空機関（ICAO）と他の航空通信の標準化団体のメンバーを含む、IETF外の航空通信の専門家によって与えられました。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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
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 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.
ベースNEMO標準[1]全体のモバイルネットワークをサポートするモバイルルータ（MRS）で使用するために特異モバイルホストのためにモバイルIPv6 [2]に延びています。 NEMOは、モバイルネットワークが効率的に固定のIPアドレスプレフィックスを経由して、彼らはネットワークトポロジでの移動に関係なく、到達可能なままにすることができます。これは、ネットワーク内のいくつかの比較的安定な点に配置NEMO MR及びNEMO支持ホームエージェント（HA）との間の双方向トンネルの維持によって達成されます。 NEMOは、モバイルIPv6のルート最適化（RO）はNEMO MR自体以外への移動ネットワーク・ノード（MNNs）に備えて用意されていません。ホームエージェント（MRHA）トンネル - MRの背後にあるMNNsは、HAおよび双方向モバイルルータを通じてそうと通信対応するノード（CNS）。このトンネルの使用は、[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に基づいて展開されているが、これらは、典型的には、IP使用していない（詳細については、付録Aと付録Bを参照）。航空機又は宇宙船は、一般的に多くの計算ノード、センサ、およびIPv6で個別に対処することが可能である他のデバイスを含んでいます。これは、ネットワーク中心の運用の概念をサポートすることが望ましいです。クラフトは、アクセスリンクのほんの数を持っていることを考えると、いくつかの動的なアクセスリンクを介して大規模なオンボードのネットワークの到達可能性を管理するために必要な機能をローカライズするNEMOのMRを使用することは非常に自然です。航空機上で、ノードは、その機能に基づいて、複数の独立したネットワークに配置されています。これらの複数のネットワークは、その空気地上交通のさまざまな治療法を持っているし、多くの場合、明確な空気アースリンクとサービス・プロバイダーを使用しなければならない規制上の理由のために必要とされます。
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.
航空宇宙環境の他の特性は、[6]さらにNEMO双方向MRHAトンネルに関する既知の問題を増幅します。
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 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].
遅延の増加や追加のインフラストラクチャの負荷につながる長い路線：航空ネットワークでは、（例えば、「旧来の」航空機の通信がアドレッシングとVHFデータリンク（VDL）モード2を介してシステム（ACARS）またはACARSの報告を使用して）キューイング遅延は、しばしば長いです自動再送要求（ARQ）メカニズムとunderprovisioned無線リンクへ。また、宇宙探査および静止衛星通過航空通信システムのために、伝播遅延も長いです。地上局および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]によるトンネリングのアーチファクトとしてカプセル化断片を識別する。航空宇宙のドメインで使用されるリンクは、エラープローンであり、初期/最終ホップ（S）上のフラグメントの損失を引き起こすかもしれないが、全体のトンネリング経路に沿って断片化するための考慮事項は、地上ドメインと同じです。
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の拡張子は、航空宇宙ネットワーキングにおける使用のための非常に望ましいです。いくつかのプランナーが真剣に自分の通信アーキテクチャ内での操作に使用する実験のデモンストレーションからNEMO技術の利用を進める検討する前に、実際には、標準のROメカニズムは、さらに必要になることがあります。 ROソリューションがなければ、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.
彼らは、使用可能なNEMOのROソリューションの特性に影響を与えるよう第2節では、我々は、航空宇宙探査での使用が想定されるアクセスと、オンボードネットワークの関連する高レベルの機能について説明します。セクション3は、その後しばらく部4つのリスト望ましいが、必ずしも必要ではないいくつかの追加の特性絶対、これらの環境のためのNEMO RO溶液に要求される技術的および機能的特徴を示しています。付録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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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ソリューションの要件および望ましい機能の開発を動機と駆動するには、このセクションでは、どのようにアクセスネットワークを説明するために、いくつかの動作特性を説明している、およびCNS設定され、航空と宇宙のネットワーク・アーキテクチャで、地理的および位相的に分散されています。これは、既知の解空間内のRO技術のクラスは、[8]に実現可能であるかを決定するのに有用であり得ます。
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）の変化率について一般にあまり言い難いです。 1つのデータポイントとして、VDLモード2つのデータリンクを使用するため、単一のアクセスチャネルに費やされた時間の長さは、飛行段階に応じて変化します。平面は、アンロードロード、給油している間、空港面に、VDLモード2のアクセス等、安定しているが、他の有線および無線LANリンク（ゲートでしばらく使用可能例えばローカルネットワーク）を行ったり来たりしてもよいです。離陸直後及び着陸前に、飛行機は約10分間端末操縦エリアにあり、安定して別のVDLモード2チャネルを使用します。ルート飛行EN中、2つのチャネルVDLモード間のハンドオーバは、サービスプロバイダによって使用される塔、細胞、およびセクタの正確な飛行計画及びレイアウトに応じて、すべての30〜60分起こり得ます。ローカルモビリティ管理の使用（例えば、[9]）異なるプロバイダまたはデータ・リンクのタイプとの間の唯一のハンドオーバにCoAの変化を制限することができるものの、これらのハンドオーバは、異なるアクセスルータと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との間のデータフローの特性は、データフローのドメインにドメイン内の特定のアプリケーションの両方に応じて変化します。でも以下の3つの航空ドメイン内で、（例えば、公称動作に対する緊急事態のために）異なる規制されているサービス種々のクラスが存在するが、このレベルの詳細は、本文書の目的のために抽象化されています。任意の実行可能な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）に関与MNNsは、ボード上のアビオニクスハードウェアの作品ナビゲーション、制御、および状況認識を提供するために使用されている航空機で構成されています。これらMNNsで実行されるアプリケーションは、乗客と乗組員の生命の安全性へのほとんどが重要です。 MNN機器は、典型的なラップトップコンピュータから非常に特殊なアビオニクス機器へのデバイスの範囲で構成することができます。これらのMNNsは、主に、たとえば、電子フライトバッグをサポートするために、いくつかのローカルモバイルノード（LMNs）を使用したローカル固定ノード（LFNs）、となります。訪問モバイルノード（VMNs）はATSのドメイン内で使用されることはありませんと仮定することができます。
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.
MRは、（少なくともVHFベース、衛星、HF系、および有線）、複数のデータリンクを使用することができるであろう、そしておそらくの場合につながる、故障の場合におけるバックアップユニットによってサポートされるATSのために使用少なくともマルチインターフェースおよびおそらくNEMO用語で、同様にマルチ接頭れるマルチホームMR。
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は、より高いデータレートをサポートし、将来のデータリンク基準を追求しています。問題の一部は、ICAO ACP-WG-F、「スペクトル管理」の下に追求し、限られたスペクトルであり、問題の一部は、ICAO ACP-WG-Tの下に追求し、データリンクプロトコル自体、「未来通信技術」です。 ACP-WG-Tは、B-AMC、AMACS、P34、LDL、WCDMA、及びその他を含む可能性のあるデータ・リンク・プロトコルの数の研究からの入力を受けました。異なるリンク・テクノロジーは、途中表面と端子部、P34又はLDLにインスタンス802.16、及び海洋飛行中SATCOMため、飛行のさまざまな段階で使用することができます。旅客情報エンターテイメントサービス（PIES）、および/または、そのような乗客のインターネット・アクセス・システムで採用さSATCOMリンクなど航空会社の運用サービス（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 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.
ATSのために、MRのとMNNsが調節制御下にあり、積極的にテストされ、維持されている、ので、特別なパッチやソフトウェアがNEMO ROを有効にするには、これらのデバイス上で実行することを想定して、完全に不合理ではありません。これらのデバイスは、熟練した技術者や専門家によってアクセスされているので、実際には、それはいくつかの特別な設定はNEMO ROのために必要とされている可能性があります。もちろん、セットアップおよび構成を簡単には、しかし、非常に好ましい、および「DES1」標識された望ましい特徴は、このドキュメントの下側の構成状態とオーバーヘッドとのソリューションを好みます。所有のコスト及び操作を最小限にするために、それは既製のオペレーティング・システムまたはネットワークスタックが必要であることが、唯一広く利用可能にも非常に望ましいが、これは完全な要件ではありません。
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ドメインから流れる主にクリアランスリクエストとグラントと短いトランザクション交換、から成ると仮定することができます。将来のATS通信は、長いメッセージと飛行中に30マイルの範囲内での位置認識と空港で動いているすべての車両の軌跡を意図し、すべての航空機の高いメッセージの周波数を含む可能性があります。これらの多くは、航空機の航空機であってもよいが、現在の交換の大部分はMNNs及び制御設備内のCNの非常に小さなセットの間であり、平面は全体移動するによる制御の完全な転送にいつでも起こります空域の部門。 CNのセットは、互いに位相的に近いものと仮定することができます。これらのCNは、他のデータに関与しているセクター内の他のフライトを管理し、MRが接続されている同じアクセスネットワーク上を流れます。これらのCNは、地理的および位相的に、多くの場合、単一の固定HAと比較して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.
MNNsおよびCNSは、IPは、ICAOによって規定されている新しい航空通信ネットワーク（ATN）アーキテクチャに基づいているとして、IPサービスをサポートするATSのために使用しました。いくつかの現在のATSの地上システムは、典型的なワークステーションコンピュータのハードウェア上で、Solaris、Linux、およびWindowsのような典型的なオペレーティングシステムを実行します。完全既製CNマシンとオペレーティング・システムを使用することができれば、それははるかに望ましいですが、これらのCNSへの軽微な変更を必要とするROソリューションのためのいくつかの可能性が、あります。このドキュメントでは、セキュリティ要件は、ROがCNS自分自身にではなく、直接よりも、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).
ATS CN（航空専門用語で「データリンクログオン」と呼ばれる）とO初期セッションの作成。
o Transfer of control between ATS CNs, resulting in regional differences in where the controlling CN is located.
制御CNが位置する場所の地域差が生じるATSのCNとの間の制御のO転送、。
o Aircraft-initiated contact with a non-controlling ATS CN, which may be located anywhere, without relation to the controlling CN.
O制御CNに関係なく、どこにでも配置することができる非制御ATS 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.
アシルCoAの変化をもたらす別のアクセスリンクとの間のO航空機遷移。
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）は、乗客や航空機の安全性にとって重要ではないですが、便を操作する航空会社の事業運営のために必要とされる、と航空会社のフライトの収益性に影響を与える可能性があるために流れています。これらのデータフローのほとんどは、航空機の飛行管理システムやセンサノードの一部であり、航空会社の本社や事業の中心近くに位置のCNで終端されているMNNsによって供給されています。 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 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.
これらMNNsを備えた機器およびCNSは、ATS・ドメインに使用される機器に類似の配慮を持っています。 AOSのCNは、おそらく航空会社の企業のデータセンターや本社に設置されるように、ATSとAOSの主な違いは、AOSのデータフローがはるかに地理的に離れたATSによって使用されるのCNより航空機にすることができることをCNSへルーティングされるようなことは、流れています。 AOSのCNもおそらくATSのCNのような飛行の寿命のために静的ではなく動的になります。 HAは、位相幾何学のCNにかなり近いかもしれAOSのために使用され、単純なイベントログは、タイムクリティカルなインタラクティブメッセージングよりも典型的なものであるため、ROは、AOSのための利益のように大きなではないかもしれません。彼らは直接、中央サーバまたは交換のメッセージを使用するかどうか - これは、アプリケーションが書かれているかにもよるが、メッセージング・フローの数が少ないために、しかし、CNSが、地理的に（必ずしも必要ではないが位相幾何学）航空機に非常に近いです。 AOSの通信をよりATSより本質的に顧問ではなく、安全性が重要であるので、さらに、AOSフローは、ATSの流れよりもトンネルの非効率性に敏感です。これらの理由から、このドキュメントでは、我々はROメカニズムと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 MNNsおよびCNSは、IPv6を実装し、ICAOが定義していることを新しいIPv6ベースのATN標準と推奨事項（SARPS）に適合することが期待できます。上記ATSについて記載したようにAOSのCNは、同様のハードウェアおよびソフトウェアの特性を有します。
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）ドメインに関与MNNsは、主に、任意の単一の権限の直接制御を超えています。これらMNNsの大半は、飛行の期間に乗客がボードに持ち込まVMNsと個人の財産であり、したがって特別なソフトウェアやオペレーティングシステムをプリロードすることを前提とするのは無理です。これらのMNNsは、多くの場合、VPNトンネルを通じて、Webブラウジング、電子メール、ファイル転送などの在庫インターネットアプリケーションを実行します。 MNNs自体は、ラップトップコンピュータ及び（例えば、802.11を使用して）オンボード無線アクセスネットワークに接続可能な携帯スマートフォンなどの携帯用電子機器です。これらのMNNデバイスやユーザーに、オンボードのネットワークに接続すると、他の地上波「ホットスポット」または一般的な無線LANへの接続と同じです。 MNNsは、このアクセスネットワークが世界中で移動飛行機、おそらく上のものであることを完全に忘れています。ユーザーは、常に技術的に熟練していないと、そのMNNsまたはアプリケーションのいずれかの特別な設定を行うことが可能ではないかもしれません。
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のCNの最大のクラスは、一般的なWebサーバや公共のインターネット上の他のノードから構成されています。これらはNEMO ROスキームをサポートするために特別に変更することができると仮定することは合理的ではありません。 IPv6のPIESのCNの増加が将来的に期待されているものの現在では、これらのCNは、ほとんどがIPv4ベースになります。この文書では、MNNsおよびCNSのいずれかがIPv6を実行しているか、移行メカニズムがどこかに、ネットワーク内に存在することを想定を超えて、IPv4に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 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.
PIES MNNs少数の格納LFNsことと、キャッシュされたメディアコンテンツ（例えば、映画や音楽）を配布したり、その乗客にゲームサービスを提供することができます。空対地利用可能な帯域幅に比べて貧血これらLFNsに格納されたデータの大きなサイズのため、これらのLFNsはおそらく飛行の途中で全てオフボードで通信しようとしないだろうが、彼らを更新するために待機します運航乗務員によって挿入された地面やリムーバブルメディア上で利用できる高速リンクのいずれかを介してコンテンツ。より高い帯域幅のリンクが手頃な価格で入手できた場合は、それは飛行中、これらの目的のために使用されるが、これをサポートすることは必須ではありません可能性があります。データは、コンテンツへのアクセスのために乗客を課金するために必要なフロー比較的低い帯域幅であり、現在飛行中に行われます。これらのデータフローの要件は、しかし、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 MNNsはそのパケットはATSのデータフローで使用されていない独立した高帯域幅のリンクを介してルーティングされる必要があります。例えば、いくつかのサービスプロバイダは、ボーイング社のシステムによって元Connexionのはやったとして、DSLのような速度で飛行中に乗客のインターネットアクセスを提供することを計画しています。いくつかの航空会社はまた、おそらく輸送のためのボイスオーバーIPを利用し、その乗客にオンボードの携帯電話サービスを提供する予定です。重要性の欠如と独立して処理される可能性に、このドキュメントでは、PIES MNNの懸念は、ROソリューションはATSとAOSのニーズに合わせて最適化し、二次懸念としてPIESを考慮しなければならない第3節の要求事項への入力として考えられていません。
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.
比較的少ない規制や官僚は、このドメインで新しい技術を導入に関与していると、IPベースのPIESシステム以来、以前に開発されているので、考慮してこれにより、PIESドメインは、また、短期的には通信のためのNEMOを利用する可能性が最も高いです展開[10]（NEMOを使用していないが）。これらの理由から、パイの懸念は必須要件の外、セクション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 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.
このセクションでは、適切なNEMO ROメカニズムを選択することに関連している宇宙探査で見つかったネットワーク環境の一部の機能について説明します。 IPv4ベースのモバイルルーティングが基板上UK-DMC衛星が実証されていることと、この上のドキュメントはNEMOの空間の使用、特定の種類の目標と構成の問題のいくつかを理解するのに有用な参考文献[11として機能することに留意すべきです]。このセクションでは、空間の「地球近傍」の範囲内にNEMOの空間の使用を想定している（すなわち、ない地球と火星または他の「深宇宙」位置との間の通信用）。 NEMOは現在、月の距離のうち、使用のために検討されていることに注意してください。強い区別は軍事利用、または地球観測や他のミッションの種類対探査ミッション対民間人の間で、ここで行われていません。我々の焦点は、民間の探査ミッションであるが、我々は同じ基本的な懸念の多くは、これらの他のミッションの種類に関連していると信じています。
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のオーバーヘッドは、ダウンリンク上では無視できるが、アップリンクのために重要であり得ることを意味します。これらのアップリンクは、（毎秒おそらくのみいくつかのキロビット）で開始するために低帯域幅であってもよいので、MNへのCNからのシグナリングの量を最小にするROスキームが、望ましいです。アップリンクは、コマンドを送信するために使用されているので、長いROシグナリングパケットをシリアル化しながら、それが長期間ブロックされるべきではありません。 MNNsにCNからのシグナリング任意の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.
無人宇宙飛行のために、ボード上のMNNs宇宙船はLFN-感知装置や工芸品を制御するために地面から指令された接地とアクチュエータデバイスでCNSへテレメトリ及び科学データを送信する処理装置のほぼ全体から成ります。ロボット月面探査車は、着陸船やオービターに位置MRの後ろVMNsとして働くことができるが、これらの探査車は、多くの独立した楽器が含まれていますし、おそらく、MR、代わりに単一VMNアドレスを使用してのLFNsとして構成することができます。
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].
有人宇宙飛行のために、少なくとも複数のMRは、高速フェイルオーバーのために同時に存在し、オンラインになると仮定することができます。これらは通常、多様な周波数帯域内のスペースリンク上でマルチホームされ、その複数のアクセスネットワークプレフィックスは、他の人がベントパイプのような中継衛星を通じて反復することができる一方で、いくつかのリンクが地上局に直接になります、特に以来、同時に使用中であることを期待することができます追跡データ中継衛星システム（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 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.
宇宙船の操作のいくつかのモードでは、すべての通信ではなく、直接自分MNNsに比べて、単一のオンボードコンピュータ（または国際宇宙ステーションのようなコマンドおよびデータ処理システム）を介して行くことが、これだけ今まで1 MNNはMRの後ろにあることをオフボードのCNと直接接触しています。この場合には、MRを除去し、NEMOが可能であるのではなく、単純なホストベースのモバイルIPv6を使用。それはバスオンボードブリッジとインテリジェントスペースリンクを管理するために複数の多様な任務に使用されるモジュール式通信アダプタの一部である可能性があるためしかし、MRがより望ましいです。これは安いですし、宇宙船の間で大きく異なる単一コマンドおよびデータ処理ノードでシンプルなモバイル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.
MRと基板上MNNs宇宙船は、高度にカスタマイズされたコンピューティングプラットフォームであり、コードまたは構成のメンテナンスの任意の量が打ち上げ後可能であると仮定すべきではないが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.
有人宇宙飛行のために、宇宙服や宇宙飛行士の追加MNNsが存在し、双方向の音声会話やビデオ、ダウンリンクのようなアプリケーションのために使用することができます。これらのMNNsは、再利用可能と当たりの飛行異なるクラフトやミッションネットワーク設計のための再構成かもしれないが、彼らは自分自身を自動設定することができることがまだ望ましい、と彼らはミッション中にネストされたまたは非ネストされたMRの間を移動することができます。宇宙飛行士が2つのドッキング宇宙船間を移動する場合たとえば、各クラフトはスーツMNNsがために再設定する必要があります独自のローカルMRと無線カバレッジを有することができます。 ROソリューションは地域の変化に適切に対応し、移行期間中にパケットロスの高いレベルを引き起こすことができない場合が望ましいです。これらのMNNsは、パーソナルエリアネットワーク（PAN）の一部となる可能性もあり、そのため、直接ボード上のメインMRの背後にあるMNNsとして表示されたり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.
航空機にIPサービスを提供するための実行可能なモビリティ技術を識別するために、国際民間航空機関（ICAO）によって行わ最近の研究では、技術的基準のセットを開発しました（[13]、[14]）。この文書に記載されている9つの要求される特性は、我々は彼らがはるかに具体的な作り、NEMO技術とNEMO内のROの問題のために焦点を当ててきたここ除き、として直接これらのICAOの基準から降りて見ることができます。
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.
オリジナルICAO基準は、より一般的と異なるモビリティソリューション（モバイルIPなどに対するトランスポートプロトコルに対するルーティングプロトコルに基づいて、例えば、モビリティ技術）の特徴を比較するために使用しました。このセクションの各要件を説明するテキスト内で、我々はそれが進化れた高レベルのICAO基準を提供します。
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.
異なるソリューションが異なるドメインをサポートするために必要とされてもよいことが理解されます。これは、異なるNEMO ROの溶液または異なるモビリティソリューション完全にどちらかを意味するかもしれません。ドメイン間で発散ソリューションが可能な場合、好ましくは避けるが、許容可能です。
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）を可能にし、PIESのが一般的、永続的なアプリケーション（例えば、ボイスオーバーIP（VoIP）のクライアント、VPNクライアントなど）ができるようになります飛行を通じて接続したまま。それらはむしろNEMO技術よりも、これを達成するためにドメイン間ルーティングプロトコル（IDRPとBGP）に頼ってもボーイングによって前OSIベースのATNとConnexionのような前航空ネットワークシステムは、固定されたモバイルネットワークプレフィックス（MNP）を維持するための先例を設定します。 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ポリシーデータベースによって設定をサポートしなければなりません。このデータベースのエントリは、特定のフローのためのバイパスまたは利用ROのいずれかを指定するために、IPsecのセキュリティポリシーデータベースで使用されるものと同様とすることができます。
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.
また、容易に中央サービスによって記録されるように、それらを可能にするために、かなりROを行うよりも、MRHA路を介して一定の流れをプッシュしたいという要望があってもよいです。
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.
また、いくつかのドメインに対して、別々のMRあるいは非NEMOのモビリティ技術が使用されている、ということも可能であるように、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."
この要件は、ICAOの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 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.
複数の要因がマルチホーミング機能の要件を駆動します。 ATS安全・オブ・ライフクリティカルなトラフィックのために、高可用性の必要性は、基本的なマルチホーミング要件を示唆しています。新しいシステムを導入し、古いものから離れての移行の規制及び業務難易度もアクセス技術の組み合わせは、任意の時点で使用中の可能性、および同時使用が必要な場合があることを意味します。もう一つの要因は、ボード上のアプリケーションの複数のドメインが実際に規制やポリシーに基づいて、それらが使用することを許可されているデータリンクに制限することができるということです。従って、特定の時間または場所で、パイのデータフローは、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ソリューションは、同時に複数のアクセスネットワークに接続して同時に使用複数のCoAを持つべきMRを考慮しなければなりません要件を駆動します。単位のパケットを使用するための適切なアシル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.
ROスキーム自体がマルチホーミングを提供することを、この要件の意図ではなく、単にその使用がマルチホームのシナリオでは不可能であるRO手法を除外します。
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."
この要件は、ICAOの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 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方式が設定するか、使用可能なアクセスリンクの設定が変更さMRのアクティブのCoAへの更新時に発生する基本的なNEMO MRHAトンネル保守よりも多くのシグナル伝達に関与する時間がかかる可能性があります。アプリケーションはすぐに特に変化に対処するためのリンク層およびNEMO手続きが発生している間の接続は、ある程度の期間のためにブロックされた可能性があることを考慮すると、地上ネットワークにパケットを取得できるようにするために、フラックスのこの期間中、それは重要であるかもしれません。アプリケーションを初めて起動したときにも、RO方式は、CNに関連する以前の知識を持っていない可能性と最適化されたパスが使用可能になる前に、いくつかのセットアップを実行する必要があるかもしれません。キューイングまたはそれ自体を構成している間に落としてどちらかの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."
この要件は、ICAOの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 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.
この要件は、ROソリューション自体はすべての偉大な新しい脆弱性を作成しないことを指定します。基本的なモバイルIPv6とNEMOの展開では、単一のHAの使用は、単一障害点を意味しているが、HASの冗長性を可能にする機構が存在する（例えば、[16]）。いくつかのHA-冗長化技術は航空設定で堅牢性を高めるために採用されることを想定しています。また、RO技術の使用は、インフラでおり、ROを使用して、その確立されたセッションにおけるHA障害に対するロバスト性の特定のレベルも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.
これは、そうであれば、ROメカニズムの仮定内の各コンポーネントの冗長フィットを作製するためのいくつかの合理的な方法としては、この要件が満たさ考えることができ、MRのための特定の冗長メカニズムを言及した、または他のネットワーク要素ありません。
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を含む、通信することを意図しているネットワークの大部分から完全に切断されると、それ自体によって管理されるモバイルネットワーク外の当事者が関与する任意の通信を維持できるようにするための必要はありません。
This requirement was derived from ICAO's TC-4 - "The approach should have high availability which includes not having a single point of failure."
この要件は、ICAOの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スキームはNEMOベーシックサポートの場合に生じることが、上記、ROパスの確立、使用、または遷移中のデータパケットの損失または複製のいずれかを引き起こすべきではありません。 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."
この要件は、ICAOの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.
ROスキームは地上ネットワーク又はルーティングシステムに過負荷をかけることなく、工芸品の数十万にMNNsによって同時に使用可能でなければなりません。これは、明示的に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.
数千機の航空機は、オンボード百、おそらくいくつかのMNNsでそれぞれ、いくつかの時間での動作であってもよいです。 IPを使用して、アクティブな宇宙船の数は、少なくとも今後10年間でこれより小さい大きさの複数の注文となりますので、航空需要は、MRの多数のスケーラビリティの面でより厳しいです。ネットワーク内のMRのすべてによって、RO法の併用がFAAの通信インフラ（FTI）やNASAのような（典型的な長距離のプライベート通信ネットワークの領域内でプロビジョニング地上ネットワークを起こした場合、それは非スターターだろう急速経路のROシグナリング負荷または量の下で過負荷または溶融ダウンする総合サービス網（NISN））は、複数のデータフローのために変化します。
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スキームは地上ネットワーク又はルーティングシステムに過負荷をかけることなく、工芸品の数十万にMNNsによって同時に使用可能でなければなりません。方式は、将来のインターネットルーティングおよびアドレス指定アーキテクチャ[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 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.
少なくとも1個のトラフィックドメイン（PIES）は、インターネットへの接続を必要とし、インターネットが将来のある遠くの点で他のドメインのための輸送を提供することができるので、この要件は明示的に不十分スケールすることが知られている技術の使用を禁止しますROの目的のためにBGP、のような彼らの世界的な影響の観点から、。前のOSIベースのATNシステムはIDRPとモバイルネットワークへの接続を維持するための「島」という概念を使用しますが、大規模な展開でテストされていませんでした。平面が接続[10]を維持するために、世界中の移動としてBGPを使用ボーイングシステムによってConnexionのは、発表と引き出し。これは多くの理由から望ましくないグローバルなインターネットルーティングテーブル内の解約、かなりの量に貢献することが見出された、将来的に避けなければなりません。
This requirement was derived from ICAO's TC-6 - "The approach should be scalable to accommodate anticipated levels of aircraft equipage."
この要件は、ICAOの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.
要件の私たちのバージョンで使用する航空機の数のための具体的なスケーリング係数は、ICAOドラフトレター・オブ・意図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 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.
航空および宇宙通信のために利用可能な帯域幅の量は、歴史的に、所望の帯域幅に比べて非常に小さいされている（例えば、VDLリンクの場合、帯域幅は、共有リソースの8 kbpsです）。この状況は、少なくとも数年以上持続することが期待されます。リンク（デマンドまたは使用中のアプリケーション自体のいずれかが期待に従わない場合も間違っていることを証明できます）と、追加のネットワーク・プロトコルのオーバーヘッドの余地を残していないアプリケーションのニーズの推定値に基づいてプロビジョニングされる傾向にあります。 NEMO ROのためのシグナリングで使用されている利用可能なエア・アースリンク容量のすべてのバイトは、アプリケーション・データのバイトを遅らせ、アプリケーションのスループットを削減する可能性があるので、はるかにゆっくりのスループットよりNEMO ROスキームのシグナリングオーバーヘッドがスケールアップすることが重要ですフローは、ROは、上の実行されています。高レートのデータリンクがより多くの帯域幅を大量に消費するアプリケーションと一緒に配備されているので、この方法では、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."
この要件は、ICAOのTC-7に由来した - 「アプローチは、航空機装備の予想レベルを収容スループットをもたらすはずです」。
For the ATS/AOS domains, there are three security sub-requirements:
ATS / AOSのドメインについては、3つのセキュリティサブ要件があります。
1. The RO scheme MUST NOT further expose MNPs on the wireless link than already is the case for NEMO basic support.
1. RO方式はさらに、すでにNEMO基本的なサポートの場合よりも無線リンク上でのMNPを公開してはなりません。
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スキームは、MRが主張のCoAのMRの所有権を検証するために、バインディング更新（BU）の受信を可能にしなければなりません。
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 ROのための同じ要件適用のそれ以外の追加要件はありません。
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ドメインとPIESの間で大きく異なります。 PIESの場合は、トラフィックフローは、地上のインターネット利用の典型であり、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 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.
最初のセキュリティ要件は、ATS通信エンジニアが表明した懸念によって駆動されます。懸念は、盗聴者が詳細に個々の便を追跡することができました、現在のエア・グラウンド・クラフトへのリンクとセキュリティの欠如によって駆動されます。 ROシステムのセキュリティはMNPの秘密に依存してはならないのに露出から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.
第2のセキュリティ要件は、いくつかのターゲット犠牲者のCoAにMNPのトラフィックをリダイレクトする攻撃者によって開始されたフラッド攻撃の危険性によって駆動されます。送信された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.
「ならず者」のMRや妥協MRの乱用を防ぐために、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のためのオンボードのネットワークの中で、LFNs夫妻は、いくつかの信頼関係を持っていると仮定することが合理的です。
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.
それは、このようなPKIが現在存在しないことで合意しているが、IPベースのATNは、生産使用に成長時間により、ATSのために使用可能なグローバルATN固有の公開鍵基盤（PKI）があることを多くの人が感じていますそして技術的にも政治的に開発に時間がかかります。このPKIは、前の段落で説明した信頼関係のより限定された量とは対照的に、証明書パスを介してATS MNNs夫人、または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.
「アプローチは安全でなければならない」と文部科学省のワーキンググループからの助けを借りて、より具体的な作られた - この要件は、ICAOのTC-8から外挿しました。
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."
この要件は、ICAOの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]に到達する可能性を増大させることが知られています。 ROは、MNNとCN間の通信コンテキストを変更するので、NEMO RO溶液が望ましくない状態に達した場合、自動的に無効にすることが可能とも容易に設定するように単純であることが望ましいです。
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.
大きな空港でのCNのために、バインディングキャッシュの状態管理機能は、同時に複数のサービスプロバイダとによる発着へのモビリティイベントのボリュームと飛行機の数百に対処することができます。これは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.
パイや宇宙飛行士の宇宙服のために、MRを持つのPANをサポートする必要がある、ということも可能であるため、ROメカニズムは、ネストされたMRのためにROをサポートしている場合、それは望ましいです。海洋飛行のため、ATSとAOSも地上地上局にではなく、低レートHFまたは衛星システムにのみ依存する「reachback」を提供するために、複数のプレーン間ネスティングMRの能力から利益を得ることができます。いずれの場合も、この動作モードは、現在の厳格な要件を超えて、単に望ましいです。また、ルーティングプロトコル又は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.
これらのローカルノードはATSとAOSドメイン内にあるように、少なくともLFNsは、航空機のための実行可能なRO溶液によってサポートされなければなりません。モバイルIPv6は、ポータブル民生機器で使用される人気のある技術になると、PIESドメイン内VMNsは、多くのことが予想されており、それらはRO技術によってサポートされますが、必須ではありませんされることが強く望まれます。 LMNsは、月および火星への有人探査ミッションなどの将来の宇宙探査シナリオに潜在的に存在します。
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.
それは航空宇宙探査の外の他の状況においても容易に使用可能であるという点で、「汎用」であるROメカニズムは、望ましいです。例えば車両用アドホックネットワーク（VANETにおける）内で使用可能であるROの溶液[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のREQ8で説明されています。
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 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）メーリングリストの参加者とのBoF努力が文書を形作るのを助け、そして早期のコンテンツは、要件文書をMPIの問題声明から借用し、提案された（[21]、[13]）。 NEMOとMONAMI6ワーキンググループの参加者は、この文書を完成に尽力しました。マドリードの2008年の文部科学省の暫定会議2月7日と8日の参加者は、これらの要件を固化させる上で重要でした。スティーブBretmersky、ティエリーエルンスト、トニー・リー、ヤリArkko、フィリップ・ワトソン、ロベルト・バルデッサリ、カルロスイエスBernardosカノ、Eivan Cerasi、マルセロBagnulo、セルカンAyaz、クリスチャンバウアー、フレッド・テンプリン、アレクサンドル・ペトレスク、トム・ヘンダーソン、そしてトニー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.
このドキュメントのウェズリー渦の仕事は主にNASAの高度な通信カーナビや監視アーキテクチャとシステムテクノロジー（ACAST）プロジェクト、および2005年と2006年にNASA宇宙通信アーキテクチャワーキンググループ（SCAWG）の支援で、NASAのグレンリサーチセンターで行われました。
[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.、ペトレスク、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]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[4]エルンスト、T.およびH-Y。 LACH、 "ネットワークモビリティサポート用語"、RFC 4885、2007年7月。
[5] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
[5]エルンスト、T.、 "ネットワークモビリティサポートの目標と要件"、RFC 4886、2007年7月。
[6] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
[6]呉、C.、Thubert、P.、亘理、M.、およびF.趙、 "ネットワークモビリティ経路最適化問題に関する声明"、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] ICAOアジア/太平洋地域事務所、「必要な通信性能（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]呉、C.、趙、F.、亘理、M.、およびP. Thubert、 "ネットワークモビリティルート最適化ソリューションスペース解析"、RFC 4889、2007年7月。
[9] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.
[9]ケンプ、J.、 "ネットワークベース局所モビリティ管理（NETLMM）の目標"、RFC 4831、2007年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.、ポールセン、P.、スチュワート、D.、シェル、D.、木材、L.、ジャクソン、C.、ホジソン、D.、ノーザム、J.、豆、N.、ミラー、 E.、グレイブス、M.、およびL. Kurisaki、「スペースベースの資産を安全に、ネットワークセントリックオペレーション：低軌道でのCiscoルータ（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]ン、C.、エルンスト、T.、パイク、E.、およびM. Bagnulo、 "ネットワークモビリティサポートにおけるマルチホーミングの分析"、RFC 4980、2007年10月。
[13] Davis, T., "Mobile Internet Platform Aviation Requirements", Work in Progress, September 2006.
[13]デイビス、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] ICAO WG-N SWG1、＃12会議 "候補ATN IPSモビリティソリューションの分析"、ワーキングペーパー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]デイビス、T.、 "航空グローバル・インターネットオペレーションズ要件"、ICAO WG-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]チャン、L.とS.つば、「新しいルーティングとアドレッシングアーキテクチャ設計のための分類学」、進歩、2008年3月での作業。
[18] ICAO, "Threat and Error Management (TEM) in Air Traffic Control", ICAO Preliminary Edition, October 2005.
[18] ICAO、 "航空交通管制における脅威とエラー管理（TEM）"、ICAO速報版、2005年10月。
[19] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route Optimization", Work in Progress, July 2007.
[19]バルデッサリ、R.、 "NEMO経路最適化のためのC2C-Cコンソーシアムの要件"、進歩、2007年7月の作業。
[20] Ng, C., "Consumer Electronics Requirements for Network Mobility Route Optimization", Work in Progress, February 2008.
[20]ン、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、 "Cislunarスペースインターネットワーキング：アーキテクチャ"、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宇宙通信アーキテクチャワーキンググループ、「2005年から2030年のためのNASA宇宙通信とナビゲーションアーキテクチャ勧告」、SCAWG最終報告書、2006年5月。
Appendix A. Basics of IP-Based Aeronautical Networking
IPベースの航空ネットワークの付録A.基本
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）は航空通信の標準規格を生産する国連の一部です。 ICAOは、OSIに基づくATNは新しい、より多くの帯域幅集約型ATNアプリケーションの展開を成功するために必要な広範囲の商用ネットワークのサポートを欠いていることを認識しており、最近ではATNの新しいIPv6ベースのバージョンに向けて取り組んできました。
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ベースのネットワーク内の移動性をサポートすることは、モバイルネットワークアタッチメントのトポロジカル点を変更するようにルーティングテーブルを再計算するドメイン間ルーティングプロトコル（IDRP）を使用OSIベースのATN、であるよりも、大幅に異なっていてもよいです。 ICAOは、これを認識し、リンク、ネットワーク、トランスポート、ルーティング、およびアプリケーションプロトコルに基づく各種のモビリティ技術を研究している[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.
ICAO以内に行われた作業はグローバル、IPベースのモバイルネットワークをサポートする際に使用するための有望な候補としてNEMO技術を特定しました。 NEMOの主な懸念は、ルート最適化サポートの現在の不足と同じインフラストラクチャを共有する複数のサービスプロバイダと25以上の航空会社を持つ大規模な空港環境におけるその潜在的に複雑な構成要件とされています。
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: 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.
このよう広帯域符号分割多元接続（WCDMA）規格またはIEEE 802.16標準として航空使用に適合させることができ、よく知られている商用のデータリンク、に加えて、いくつかのより専門的な技術が存在するいずれかまたは空気地面使用することが提案されています - かなり低いレートでデジタル音声及びデータの異なるミックスをサポートすることができる137 MHzの範囲VHFデータリンク（VDL）O 117.975での4つの動作モードを指定します。低金利は、国際航空用途のために割り当てられた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）は、基礎となるRFデータリンク（例えば、VHF、HF、及び衛星中継）のいくつかのタイプにわたって使用することができるメッセージングシステムです。 ACARSメッセージングは、飛行の過程で送信すると、イベント通知のいくつかの種類の処理を自動化します。より具体的な「プレインオールドACARS」（POA）は、ACARSシステムは、従来VDLおよび他のデータリンクの採用に使用される特定のレガシーRFインタフェースを指すのに対し、一般にACARSは、より高いレベルのメッセージングシステムです。 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.
ブロードバンド航空マルチキャリア通信（B-AMC）O空対地方向にグランド対空気からマルチキャリアCDMAを使用して直交周波数分割多重（OFDM）ハイブリッド細胞系です。 B-AMCは、スペクトルのLバンドで実行され、本来VHFスペクトルで動作するように開発された広帯域VHF（B-VHF）技術から適合されています。 Lバンドの使用は、以前はアナログ音声使用がサポートされ続けるVHF帯におけるより入手可能であるよりも大きな帯域幅を持つチャネルを使用して、距離測定装置（DME）のために割り当てられたスペースを占有することを意図しています。 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.
400 kHzのチャネルとVDLモード4のメディアアクセス技術を使用する - O万能マルチチャネル航空通信システム（AMACS）は、移動通信用グローバルシステム（GSM）50とLバンドで動作する物理層の適応です。 AMACSが展開され、特定のチャポリシーに応じて、数百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 exact performance will depend on the particular operating band, range (guard time), and channelization plan configured in deployment.
Oプロジェクト34（P34）は、Lバンドで使用可能な広帯域公衆安全無線システムです。 P34は、特にIPベースのパケットネットワークのための容量の数百kbpsのを提供するように設計されています。これは、50、100、または150 kHzのチャネルにOFDMを使用し、正確な性能は、特定の動作帯域範囲（ガードタイム）、および展開に構成チャプランに依存するであろう。
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アクセス技術を適応し、最大100 kbpsのできることが期待されます。
Appendix B. Basics of IP-based Space Networking
IPベースの宇宙ネットワーキングの付録B.基礎
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自体は、（例えば、サリーサテライトテクノロジー・リミテッド（SSTL）災害監視コンステレーション（DMC）衛星）は、現在の宇宙船と通信するための限られた操作上の使用です。将来の通信アーキテクチャは、しかし、基本的なビルディングブロックとしてIPベースのネットワークが含まれます。宇宙データシステム諮問委員会（CCSDS）は、有人及び無人の両方地球近傍ミッションにIPベースの通信を使用するためのネットワークアーキテクチャを生成しているワーキンググループを有しており、この目標[22]に向けて国際的な参加を有しています。 NASAの宇宙通信アーキテクチャワーキンググループ（SCAWG）も[23] IPベースのマルチミッションのネットワークアーキテクチャを開発しました。これらのどちらも、明示的に、モバイル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
ウェズリーM.エディベライゾン連邦ネットワークシステムNASAグレンリサーチセンター21000ブルックパークロード、MS 54-5クリーブランド、オハイオ州44135 USA
EMail: weddy@grc.nasa.gov
メールアドレス：weddy@grc.nasa.gov
Will Ivancic NASA Glenn Research Center 21000 Brookpark Road, MS 54-5 Cleveland, OH 44135 USA
ウィルIvancic NASAグレンリサーチセンター21000ブルックパークロード、MS 54-5クリーブランド、オハイオ州44135 USA
Phone: +1-216-433-3494 EMail: William.D.Ivancic@grc.nasa.gov
電話：+ 1-216-433-3494 Eメール：William.D.Ivancic@grc.nasa.gov
Terry Davis Boeing Commercial Airplanes P.O.Box 3707 MC 0Y-96 Seattle, WA 98124-2207 USA
テリー・デービスボーイング民間航空機P.O.Box 3707 MC 0Y-96シアトル、WA 98124から2207 USA
Phone: 206-280-3715 EMail: Terry.L.Davis@boeing.com
電話：206-280-3715 Eメール：Terry.L.Davis@boeing.com