[要約] 要約：RFC 5522は、航空宇宙探査モバイルネットワークでのネットワークモビリティルート最適化の要件について説明しています。 目的：このRFCの目的は、航空宇宙探査モバイルネットワークにおけるネットワークモビリティの問題を解決し、効率的な通信を実現するための要件を提供することです。
Network Working Group W. Eddy
Request for Comments: 5522 Verizon
Category: Informational W. Ivancic
NASA
T. Davis
Boeing
October 2009
Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks
ネットワークモビリティルート最適化要件航空および宇宙探査モバイルネットワークでの運用上の使用
Abstract
概要
This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.
このドキュメントでは、航空および宇宙探査用のグローバルネットワーク通信システムで使用するためのネットワークモビリティ（NEMO）ルート最適化技術の要件と望ましいプロパティについて説明します。
Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies.
これらの要件への実質的な情報は、IETF以外の航空通信専門家によって与えられました。これには、国際民間航空機関（ICAO）やその他の航空通信基準団体のメンバーが含まれます。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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アドレスプレフィックスを介してモバイルネットワークを効率的に維持できます。これは、ネットの比較的安定したポイントに配置されたネモMRとネモサポートホームエージェント（HA）の間の双方向トンネルの維持によって達成されます。NEMOは、Nemo MR自体以外のモバイルネットワークノード（MNNS）にモバイルIPv6のルート最適化（RO）機能を提供しません。MRの背後にあるMNNと通信する対応するノード（CNS）は、HAおよび双方向モバイルルーター - ホームエージェント（MRHA）トンネルを介してそうします。このトンネルの使用には重要な欠点がある可能性があるため[6]、CNとMRの間のより直接的なパスを使用できるRO技術は非常に望ましいものです。
For decades, mobile networks of some form have been used for communications with people and avionics equipment on board aircraft and spacecraft. These have not typically used IP, although architectures are being devised and deployed based on IP in both the aeronautics and space exploration communities (see Appendix A and Appendix B for more information). An aircraft or spacecraft generally contains many computing nodes, sensors, and other devices that are possible to address individually with IPv6. This is desirable to support network-centric operations concepts. Given that a craft has only a small number of access links, it is very natural to use NEMO MRs to localize the functions needed to manage the large onboard network's reachability over the few dynamic access links. On an aircraft, the nodes are arranged in multiple, independent networks, based on their functions. These multiple networks are required for regulatory reasons to have different treatments of their air-ground traffic and must often use distinct air-ground links and service providers.
何十年もの間、何らかの形のモバイルネットワークは、ボード航空機や宇宙船の人々やアビオニクス機器との通信に使用されてきました。これらは通常使用されていませんが、アーキテクチャは航空と宇宙探査コミュニティの両方でIPに基づいて考案および展開されています（詳細については、付録Aと付録Bを参照）。航空機または宇宙船には、一般に、IPv6で個別に対処できる多くのコンピューティングノード、センサー、およびその他のデバイスが含まれています。これは、ネットワーク中心の操作の概念をサポートするために望ましいです。クラフトには少数のアクセスリンクしかないことを考えると、Nemo MRSを使用して、少数の動的アクセスリンクで大きなオンボードネットワークの到達可能性を管理するために必要な関数をローカライズするのは非常に自然です。航空機では、ノードは機能に基づいて複数の独立したネットワークに配置されます。これらの複数のネットワークは、規制上の理由で空軍の交通の異なる治療を行うために必要であり、しばしば異なる空軍リンクとサービスプロバイダーを使用する必要があります。
For aeronautics, the main disadvantage of using NEMO bidirectional tunnels is that airlines operate flights that traverse multiple continents, and a single plane may fly around the entire world over a span of a couple days. If a plane uses a static HA on a single continent, then for a large percentage of the time, when the plane is not on the same continent as the HA, a great amount of delay is imposed by using the MRHA tunnel. Avoiding the delay from unnecessarily forcing packets across multiple continents is the primary goal of pursuing NEMO RO for aeronautics.
航空の場合、ネモ双方向トンネルを使用することの主な欠点は、航空会社が複数の大陸を横断するフライトを運営しており、単一の飛行機が数日間で全世界を飛び回ることができることです。飛行機が単一の大陸で静的HAを使用している場合、その後、平面がHAと同じ大陸にない場合、MRHAトンネルを使用することで大きな遅延が課されます。複数の大陸にわたって不必要に強制的にパケットを強制することによる遅延を避けることは、航空のためにNemo ROを追求することの主な目標です。
Other properties of the aeronautics and space environments amplify the known issues with NEMO bidirectional MRHA tunnels [6] even further.
航空環境と空間環境の他の特性は、Nemo双方向Mrha Tunnels [6]の既知の問題をさらに増幅します。
Longer routes leading to increased delay and additional infrastructure load: In aeronautical networks (e.g., using "Plain Old" Aircraft Communication Addressing and Reporting System (ACARS) or ACARS over VHF Data Link (VDL) mode 2) the queueing delays are often long due to Automatic Repeat Request (ARQ) mechanisms and underprovisioned radio links. Furthermore, for space exploration and for aeronautical communications systems that pass through geosynchronous satellites, the propagation delays are also long. These delays, combined with the additional need 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].
遅延の増加と追加のインフラストラクチャ負荷につながる長いルート：航空ネットワーク（例えば、「プレーンオールド」航空機通信アドレス指定およびレポートシステム（ACAR）またはACARを使用するVHFデータリンク（VDL）モード2）では、キューイングの遅延が長いことがよくあります。自動繰り返し要求（ARQ）メカニズムと不十分な無線リンクへ。さらに、宇宙探査や地理的衛星を通過する航空通信システムの場合、伝播の遅延も長いです。これらの遅延は、地上ステーションとCNS間でパケットを輸送するために大陸を横断する必要性と組み合わせることで、MRHAトンネルを追加せずに航空ネットワークと宇宙ネットワークで既に遅延が非常に高いことを意味します。Mrha Tunnelsによって引き起こされる遅延の増加は、必要なコミュニケーションパフォーマンスを満たす際に受け入れられない可能性があります[7]。
Increased packet overhead: Given the constrained link bandwidths available in even future communications systems for aeronautics and space exploration, planners are extremely adverse to header overhead. Since any amount of available link capacity can be utilized for extra situational awareness, science data, etc., every byte of header/tunnel overhead displaces a byte of useful data.
パケットオーバーヘッドの増加：航空と宇宙探査用の将来の通信システムで利用可能な制約されたリンク帯域幅を考えると、プランナーはヘッダーの頭上に非常に不利です。利用可能なリンク容量の量は、余分な状況認識、科学データなどに利用できるため、ヘッダー/トンネルのオーバーヘッドのすべてのバイトが有用なデータのバイトを置き換えます。
Increased chances of packet fragmentation: RFC 4888 [6] identifies fragmentation due to encapsulation as an artifact of tunneling. While links used in the aeronautics and space domains are error-prone and may cause loss of fragments on the initial/final hop(s), considerations for fragmentation along the entire tunneled path are the same as for the terrestrial domain.
パケットの断片化の可能性の増加：RFC 4888 [6]は、カプセル化による断片化をトンネリングのアーティファクトとして識別します。航空および空間ドメインで使用されるリンクはエラーが発生しやすく、初期/最終ホップでフラグメントの損失を引き起こす可能性がありますが、トンネルパス全体に沿った断片化の考慮事項は、陸生ドメインと同じです。
Increased susceptibility to failure: The additional likelihood of either a single link failure disrupting all communications or an HA failure disrupting all communications is problematic when using MRHA tunnels for command and control applications that require high availability for safety-of-life or safety-of-mission.
障害に対する感受性の向上：すべての通信を混乱させる単一のリンク障害またはすべての通信を混乱させるHA障害のいずれかの追加の可能性は、MRHAトンネルを使用するためにMRHAトンネルを使用して、生活の安全性または安全性のために高可用性を必要とする場合に問題があります。ミッション。
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.
セクション2では、使用可能なNemo ROソリューションの特性に影響を与えるため、航空と宇宙探査で使用するために想定されるアクセスおよびオンボードネットワークの関連する高レベルの機能について説明します。次に、セクション3には、これらの環境のNemo ROソリューションに絶対に必要な技術的および機能的特性をリストしますが、セクション4には、必要なが必ずしも必要ではない追加の特性をリストします。付録Aおよび付録Bでは、IPベースのネットワークアーキテクチャのために、それぞれ航空と宇宙探査で使用される特定の運用概念に関する簡単なプライマーを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Although this document does not specify an actual protocol, but rather specifies just the requirements for a protocol, it still uses the RFC 2119 language to make the requirements clear.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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チャネルを安定して使用します。途中の飛行中、VDLモード2チャネルの間の携帯電話は、サービスプロバイダーが使用するタワー、セル、およびセクターの正確な飛行計画とレイアウトに応じて、30〜60分ごとに発生する場合があります。これらの拳オーバーは、異なるアクセスルーターとCOAの変更をもたらす可能性がありますが、ローカルモビリティ管理（[9]）の使用により、COAの変更が異なるプロバイダーまたはデータリンクのタイプ間の拳銃のみに制限される場合があります。
The characteristics of a data flow between a CN and MNN varies both depending on the data flow's domain and on the particular application within the domain. Even within the three aeronautical domains described below, there are varying classes of service that are regulated differently (e.g., for emergencies versus nominal operations), but this level of detail has been abstracted out for the purposes of this document. It is assumed that any viable NEMO RO solution will be able to support a granularity of configuration with many sub-classes of traffic within each of the specific domains listed here.
CNとMNNの間のデータフローの特性は、データフローのドメインとドメイン内の特定のアプリケーションによって異なります。以下で説明する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は、ナビゲーション、制御、状況認識を提供するために使用される航空機のアビオニクスハードウェアの断片で構成されています。これらのMNNが実行するアプリケーションは、乗客と乗組員の生活の安全にほとんど重要です。MNN機器は、典型的なラップトップコンピューターから非常に特殊なアビオニクスデバイスまで、さまざまなデバイスで構成されている場合があります。これらのMNNは、ほとんどがローカル固定ノード（LFN）であり、たとえば電子フライトバッグをサポートするためのいくつかのローカルモバイルノード（LMN）を備えています。アクセスモバイルノード（VMN）は、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.
ATSに使用されるMRは、複数のデータリンク（少なくともVHFベース、衛星、HFベース、有線）を使用でき、障害の場合はバックアップユニットによってサポートされ、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、「Spectrum Management」の下で追求され、問題の一部は、ICAO ACP-WG-T「Future Communications Technology」の下で追求されるデータリンクプロトコル自体です。ACP-WG-Tは、B-AMC、AMACS、P34、LDL、WCDMAなどを含む多くの潜在的なデータリンクプロトコルに関する研究から入力を受けています。さまざまなリンクテクノロジーは、飛行のさまざまな段階で使用できます。たとえば、表面および端子エリア、途中のP34またはLDL、および海洋飛行ではSATCOMなど、さまざまなリンクテクノロジーを使用できます。乗客情報およびエンターテイメントサービス（PIE）および/または航空会社の運用サービス（AOS）に使用される現在および計画されたデータリンクは、乗客のインターネットアクセスシステムで採用されているSATCOMリンクなど、現在の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の場合、MRSとMNNは規制管理下にあり、積極的にテストおよび維持されているため、これらのデバイスで特別なパッチまたはソフトウェアを実行して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と制御施設内の非常に小さなCNSの間にあり、平面が移動するときに完全に制御されるため、いつでも行われます。空域のセクター。CNSのセットは、トポロジカルに互いに近いと想定される場合があります。これらのCNSは、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.
IPはICAOによって定義されている新しい航空通信ネットワーク（ATN）アーキテクチャの基礎であるため、ATSに使用されるMNNとCNSはIPサービスをサポートします。一部の現在のATSグラウンドシステムは、典型的なワークステーションコンピューターハードウェアで、Solaris、Linux、Windowsなどの典型的なオペレーティングシステムを実行しています。ROソリューションがこれらのCNに軽微な変更を必要とする可能性がありますが、完全に既製のCNマシンとオペレーティングシステムを使用できれば、はるかに望ましいです。このドキュメントの後半では、セキュリティ要件は、CNS自体に直接ではなく、CNSにトポロジカルに近いモビリティアンカーでROが実行される可能性があることを示唆しています。これは、CNの変更が必要ないことを意味する可能性があります。
During the course of a flight, there are several events for which an RO solution should consider the performance implications:
フライト中に、ROソリューションがパフォーマンスへの影響を考慮する必要があるいくつかのイベントがあります。
o Initial session creation with an ATS CN (called "Data Link Logon" in the aeronautical jargon).
o ATS CNを使用した初期セッション作成（航空専門用語の「データリンクログオン」と呼ばれる）。
o Transfer of control between ATS CNs, resulting in regional differences in where the controlling CN is located.
o ATS CNS間の制御の移動により、制御CNが位置する場所に地域の違いが生じます。
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.
o あるアクセスリンク間の別のアクセスリンク間の航空機の移行により、COAが変更されます。
o Concurrent use of multiple access links with different care-of addresses.
o さまざまなケアアドレスを使用した複数のアクセスリンクの同時使用。
Data flows for Airline Operational Services (AOS) are not critical to the safety of the passengers or aircraft, but are needed for the business operations of airlines operating flights, and may affect the profitability of an airline's flights. Most of these data flows are sourced by MNNs that are part of the flight management system or sensor nodes on an aircraft, and are terminated at CNs located near an airline's headquarters or operations center. AOS traffic may include detailed electronic passenger manifests, passenger ticketing and rebooking traffic, and complete electronic baggage manifests. When suitable bandwidth is available (currently on the surface when connected to a wired link at a gate), "airplane health information" data transfers of between 10 and several hundred megabytes of data are likely, and in the future, it is expected that the In-Flight Entertainment (IFE) systems may receive movie refreshes of data (e.g., television programming or recent news updates) running into the multi-gigabyte range.
航空会社の運用サービス（AOS）のデータフローは、乗客や航空機の安全性にとって重要ではありませんが、航空会社の運営便に必要であり、航空会社のフライトの収益性に影響を与える可能性があります。これらのデータフローのほとんどは、航空機の飛行管理システムまたはセンサーノードの一部であるMNNによって供給され、航空会社の本部またはオペレーションセンターの近くにあるCNSで終了します。AOSトラフィックには、詳細な電子乗客マニフェスト、乗客のチケットと再予約トラフィック、および完全な電子手荷物マニフェストが含まれる場合があります。適切な帯域幅が利用可能である場合（現在はゲートの有線リンクに接続すると表面上）、10〜100メガバイトのデータ転送が可能性が高く、将来的には、将来的には、In-Flight Entertainment（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.
これらのMNNとCNSを含む機器は、ATSドメインに使用される機器と同様の考慮事項を持っています。ATSとAOSの重要な違いは、AOSデータフローは、AOS CNSがおそらく航空会社の企業データセンターまたは本社にあるため、ATSフローで使用されるCNSよりもはるかに地理的に航空機に限定されるCNSにルーティングされることです。AOS CNSは、ATS CNSのように動的ではなく、フライトの寿命の静的である可能性があります。AOSに使用されるHAは、CNSにかなり近い場合があります。また、単純なイベントロギングは時間型のインタラクティブなメッセージよりも典型的であるため、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標準と推奨プラクティス（SARP）に準拠することが期待できます。AOS CNSには、上記のATSについて説明されているように、同様のハードウェアとソフトウェアのプロパティがあります。
The MNNs involved in the Passenger Information and Entertainment Services (PIES) domain are mostly beyond the direct control of any single authority. The majority of these MNNs are VMNs and personal property brought on board by passengers for the duration of a flight, and thus it is unreasonable to assume that they be preloaded with special software or operating systems. These MNNs run stock Internet applications like web browsing, email, and file transfer, often through VPN tunnels. The MNNs themselves are portable electronics, such as laptop computers and mobile smartphones capable of connecting to an onboard wireless access network (e.g., using 802.11). To these MNN devices and users, connecting to the onboard network is identical to connecting to any other terrestrial "hotspot" or typical wireless LAN. The MNNs are completely oblivious to the fact that this access network is on an airplane and possibly moving around the globe. The users are not always technically proficient and may not be capable of performing any special configuration of their MNNs or applications.
乗客情報およびエンターテイメントサービス（PIE）ドメインに関与するMNNは、ほとんどの当局の直接的な制御を超えています。これらのMNNの大部分は、フライトの期間中、乗客が乗客に搭載したVMNと個人財産であるため、特別なソフトウェアまたはオペレーティングシステムでプリロードされていると仮定するのは不合理です。これらのMNNは、多くの場合VPNトンネルを介して、Webブラウジング、電子メール、ファイル転送などのストックインターネットアプリケーションを実行します。MNN自体は、オンボードワイヤレスアクセスネットワークに接続できるラップトップコンピューターやモバイルスマートフォンなどのポータブル電子機器です（802.11を使用するなど）。これらのMNNデバイスとユーザーにとって、オンボードネットワークに接続することは、他の地上の「ホットスポット」または典型的なワイヤレスLANに接続するのと同じです。MNNは、このアクセスネットワークが飛行機にあり、おそらく世界中を移動しているという事実を完全に忘れています。ユーザーは常に技術的に熟練しているわけではなく、MNNまたはアプリケーションの特別な構成を実行できない場合があります。
The largest class of PIES CNs consists of typical web servers and other nodes on the public Internet. It is not reasonable to assume that these can be modified specifically to support a NEMO RO scheme. Presently, these CNs would be mostly IPv4-based, though an increasing number of IPv6 PIES CNs are expected in the future. This document does not consider the problem of IPv4-IPv6 transition, beyond the assumption that either MNNs and CNs are running IPv6 or a transition mechanism exists somewhere within the network.
パイCNSの最大のクラスは、一般的なインターネット上の典型的なWebサーバーとその他のノードで構成されています。Nemo ROスキームをサポートするためにこれらを特別に変更できると仮定することは合理的ではありません。現在、これらのCNSはほとんどIPv4ベースですが、将来的にはIPv6 PIES CNSの数が増えています。このドキュメントでは、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.
少数のパイMNNは、キャッシュされたメディアコンテンツ（映画や音楽など）を保存および配布するLFNであるか、乗客にゲームサービスを提供する可能性があります。利用可能な空気への貧血帯域幅と比較して、これらのLFNに保存されているデータのサイズが大きいため、これらのLFNはおそらくフライト中にオフボードをまったく通信しようとはしませんが、更新するのを待ちます。地上で利用可能な高速リンクまたはフライトクルーによって挿入された取り外し可能なメディアを介したコンテンツ。ただし、より高い帯域幅リンクが手頃な価格で利用可能である場合、これらの目的で飛行中に使用される可能性がありますが、これをサポートすることは要件ではありません。コンテンツへのアクセスのために乗客に請求するために必要なデータフローは、帯域幅が比較的低く、現在飛行中に行われています。ただし、これらのデータフローの要件は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データフローでは使用されていない個別の高帯域幅リンクを介してパケットをルーティングする場合があります。たとえば、いくつかのサービスプロバイダーは、ボーイングシステムによる以前の接続と同様に、DSLのようなレートでのフライト中に乗客のインターネットアクセスを提供することを計画しています。また、いくつかの航空会社は、乗客にオンボードセルラーサービスを提供する予定であり、おそらく輸送にボイスオーバーIPを利用することを計画しています。批判性の欠如と独立して扱われる可能性のため、この文書では、PIES MNNの懸念はセクション3の要件への入力とは見なされません。ROソリューションはATSおよびAOSニーズに最適化され、PIESを二次的な懸念と見なす必要があります。。
With this in consideration, the PIES domain is also the most likely to utilize NEMO for communications in the near-term, since relatively little regulations and bureaucracy are involved in deploying new technology in this domain and since IP-based PIES systems have previously been developed and deployed (although not using NEMO) [10]. For these reasons, PIES concerns factor heavily into the desirable properties in Section 4, outside of the mandatory requirements.
これを考慮して、PIESドメインは、比較的少ない規制と官僚機構がこのドメインに新しいテクノロジーの展開に関与しており、IPベースのPIESシステムが以前に開発されているため、短期的にコミュニケーションにNEMOを利用する可能性が最も高いです。展開（NEMOを使用していませんが）[10]。これらの理由により、PIESは、必須要件以外のセクション4の望ましいプロパティに大きく影響を及ぼします。
Some PIES nodes are currently using 2.5G/3G links for mobile data services, and these may be able to migrate to an IP-based onboard mobile network, when available.
一部のPIESノードは現在、モバイルデータサービスに2.5G/3Gリンクを使用しており、これらは利用可能な場合はIPベースのオンボードモバイルネットワークに移行できる可能性があります。
This section describes some features of the network environments found in space exploration that are relevant to selecting an appropriate NEMO RO mechanism. It should be noted that IPv4-based mobile routing has been demonstrated on board the UK-DMC satellite and that the documentation on this serves as a useful reference for understanding some of the goals and configuration issues for certain types of space use of NEMO [11]. This section assumes space use of NEMO within the "near-Earth" range of space (i.e., not for communications between the Earth and Mars or other "deep space" locations). Note that NEMO is currently being considered for use out 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オーバーヘッドがダウンリンクでは無視できるが、アップリンクでは重要である可能性があることを意味します。CNSからMNへのシグナリングの量を最小化するROスキームは望ましいです。これらのアップリンクは、帯域幅が低くなる可能性があるためです（おそらく1秒あたり数キロビットのみ）。アップリンクはコマンドを送信するために使用されるため、長いROシグナリングパケットをシリアル化している間、長期間ブロックされるべきではありません。CNからMNNへのROシグナリングは、大きなパケットを含めてはなりません。
For unmanned space flight, the MNNs on board a spacecraft consist almost entirely of LFN-sensing devices and processing devices that send telemetry and science data to CNs on the ground and actuator devices that are commanded from the ground in order to control the craft. Robotic lunar rovers may serve as VMNs behind an MR located on a lander or orbiter, but these rovers will contain many independent instruments and could probably be configured as an MR and LFNs instead of using a single VMN address.
無人の宇宙飛行の場合、宇宙船のMNNSは、船を制御するために地面から命じられている地上のCNSおよびアクチュエータデバイスにテレメトリーと科学データを送信するLFNセンシングデバイスと処理デバイスからほぼ完全に構成されています。ロボット月のローバーは、ランダーまたはオービターにあるMRの背後にあるVMNとして機能する可能性がありますが、これらのローバーには多くの独立した楽器が含まれており、おそらく単一のVMNアドレスを使用する代わりにMRおよびLFNとして構成できます。
It can be assumed that for manned spaceflight, at least multiple MRs will be present and online simultaneously for fast failover. These will usually be multihomed over space links in diverse frequency bands, and so multiple access network prefixes can be expected to be in use simultaneously, especially since some links will be direct to ground stations while others may be bent-pipe repeated through satellite relays like the Tracking and Data Relay Satellite System (TDRSS). This conforms to the (n,1,1) or (n,n,1) NEMO multihoming scenarios [12]. For unmanned missions, if low weight and power are more critical, it is likely that only a single MR and single link/ prefix may be present, conforming to the (1,1,1) or (1,n,1) NEMO multihoming scenarios [12].
有人の宇宙飛行の場合、少なくとも複数のMRSが迅速にフェールオーバーのために同時に存在し、オンラインで存在すると想定できます。これらは通常、多様な周波数帯域のスペースリンクを介してマルチホームされます。そのため、特に一部のリンクは地上ステーションに直接向上するため、複数のアクセスネットワークプレフィックスが同時に使用されると予想されます。追跡およびデータリレー衛星システム（TDRSS）。これは（n、1,1）または（n、n、1）nemoマルチホームシナリオ[12]に適合します。無人ミッションの場合、重量と電力がより重要である場合、（1,1,1）または（1、n、1）Nemo Multihomingに準拠して、単一のMRと単一のリンク/プレフィックスのみが存在する可能性があります。シナリオ[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.
宇宙船の操作のモードによっては、すべての通信がMNN自体に直接ではなく、単一のオンボードコンピューター（または国際宇宙ステーションのようなコマンドおよびデータ処理システム）を通過する可能性があるため、MRの背後には1つのMNNしかありません。オフボードCNSと直接接触しています。この場合、NEMOではなくMRを削除し、シンプルなホストベースのモバイル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.
宇宙船に乗っているMRSと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.
有人の宇宙飛行の場合、宇宙服や宇宙飛行士の追加のMNNが存在し、双方向の音声会話やビデオダウンリンクなどのアプリケーションに使用される場合があります。これらのMNNは、さまざまなクラフトまたはミッションネットワークのデザインに対して再利用可能で再構成される可能性がありますが、ミッション中にネストされたMRSまたは非ネストのMRを自動化することができることが依然として望ましいです。たとえば、宇宙飛行士が2つのドッキングされた宇宙船の間を移動した場合、各クラフトには、MNNSが再構成する必要があるスーツのMRとワイヤレスのカバレッジがあります。ROソリューションがこの地域の変化に適切に応答し、移行期に高いレベルのパケット損失を引き起こさない場合、それは望ましいです。また、これらのMNNSは個人エリアネットワーク（PAN）の一部である可能性が高いため、船上のメインMRの後ろにMNNとして直接表示されるか、パン内に独自のMRを持っているため、ネストされた（または多数）Nemo構成）レベルネスト）。
This section lists requirements that specify the absolute minimal technical and/or functional properties that a NEMO RO mechanism must possess to be usable for aeronautical and space communications.
このセクションには、NEMO ROメカニズムが航空通信および宇宙通信に使用できるようにしなければならない絶対的な最小技術的および/または機能的特性を指定する要件をリストします。
In the recent work done by the International Civil Aviation Organization (ICAO) to identify viable mobility technologies for providing IP services to aircraft, a set of technical criteria was developed ([13], [14]). The nine required characteristics listed in this document can be seen as directly descended from these ICAO criteria, except here we have made them much more specific and focused for the NEMO technology and the problem of RO within NEMO.
国際民間航空機関（ICAO）が行った最近の研究では、航空機にIPサービスを提供するための実行可能なモビリティテクノロジーを特定するために、一連の技術的基準が開発されました（[13]、[14]）。このドキュメントにリストされている9つの必要な特性は、これらのICAOの基準から直接派生していると見ることができますが、ここでは、NemoテクノロジーとNemo内のROの問題にはるかに具体的かつ焦点を合わせています。
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.
モバイルネットワーク内とCNSの両方で使用されるIPアドレスがモバイルネットワーク内のノードで新しいセッションを開始するために使用されるIPアドレスが残っていることです。フライトとオペレーションの過程を通して一定。ATSおよびAOSの場合、これにより、ホームアドレス（HOAS）がロケーターではなくノード識別子として機能することができます。Pieの場合、一般的な永続的なアプリケーション（例：Voice over IP（VoIP）クライアント、VPNクライアントなど）を許可します。飛行中に接続されたままです。以前のOSIベースのATNやボーイングによる接続のような以前の航空ネットワークシステムは、固定モバイルネットワークプレフィックス（MNP）を維持するための先例を設定しましたが、NEMOテクノロジーではなく、これを達成するためにドメイン間ルーティングプロトコル（IDRPおよびBGP）に依存していました。この要件は、モビリティ管理技術の一般的な選択に適用されますが、モビリティ管理のために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.
さらに、NEMOテクノロジーの使用はドメインごとに決定されることが予想されているため、一部のドメインでは、MRSまたは非ネモのモビリティ技術が使用される可能性があります。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).
交通分離への提案されたアプローチの1つは、使用されたパケットアドレスによって決定されるトラフィックドメインの処理を伴う、オンボードネットワークのマルチアドレスです。ただし、この要件を満たすために可能な他の手法があるため、マルチアドレス自体が要件ではありません。上記で説明する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の生活の安全性の重要なトラフィックの場合、高可用性の必要性は、基本的なマルチホームの要件を示唆しています。また、新しいシステムを展開し、古いシステムから移行することにおける規制および運用上の困難は、アクセステクノロジーの組み合わせがいつでも使用されており、同時に使用する必要があることを意味します。もう1つの要因は、搭乗中のアプリケーションの複数のドメインが、規制とポリシーに基づいて使用できるデータリンクに実際に制限される可能性があることです。したがって、特定の時間または場所で、PIESデータフローは、ATSデータフローで使用されているものとは異なるアクセスリンクを使用する必要がある場合があります。
This drives the requirement that an RO solution MUST allow for an MR to be connected to multiple access networks simultaneously and have multiple CoAs in use simultaneously. The selection of a proper CoA and access link to use per-packet may be either within or outside the scope of the RO solution. As a minimum, if an RO solution is integrable with the MONAMI6 basic extensions (i.e., registration of multiple CoAs and flow bindings) and does not preclude their use, then this requirement can be considered to be satisfied.
これにより、ROソリューションがMRを複数のアクセスネットワークに同時に接続し、複数のCOAを同時に使用する必要があるという要件が促進されます。パケットごとに使用する適切なCOAとアクセスリンクの選択は、ROソリューションの範囲内または外側のいずれかです。少なくとも、ROソリューションがMonami6 Basic Extensions（つまり、複数の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 Multihomingシナリオ[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.
したがって、Active Accessリンクの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]）。いくつかのaeronautical環境での堅牢性を高めるために、いくつかのHA冗長技術が採用されると想定されています。また、RO技術の使用は、インフラストラクチャに依存することを減らし、ROを使用した確立されたセッションで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.
これには、MR、HAS、またはその他のネットワーク要素の特定の冗長メカニズムについては言及していません。そのため、各コンポーネントをROメカニズムの仮定に適合させる合理的な方法がある限り、この要件は満たされると見なすことができます。
There is no intention to support "Internet-less" operation through this requirement. When an MR is completely disconnected from the majority of the network with which it is intended to communicate, including its HA, there is no requirement for it to be able to retain any communications involving parties outside the mobile networks managed by itself.
この要件を通じて「インターネットのない」操作をサポートするつもりはありません。MRがHAを含む通信を目的としているネットワークの大部分から完全に切断されている場合、それ自体が管理するモバイルネットワークの外側の関係者が関与するコミュニケーションを保持できることは要件がありません。
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.
数千の航空機がいつか稼働している可能性があり、それぞれがおそらく数百MNNを搭載しています。IPを使用するアクティブな宇宙船の数は、少なくとも今後10年間でこれよりも数桁少ないため、多数のMRSにとってスケーラビリティの点で航空のニーズがより厳しくなります。ネットワーク内のすべてのMRSによるROテクニックの複合使用が、典型的な長距離プライベートテレコミュニケーションネットワークの領域内でプロビジョニングされた地上ネットワークを引き起こした場合、それは非スターターになります（FAAの電気通信インフラストラクチャ（FTI）またはNASAIntegrated Services Network（NISN））は、複数のデータフローのROシグナル伝達負荷または迅速なパス変更の下で過負荷または溶けたままになります。
Thus, an RO scheme MUST be simultaneously usable by the MNNs on hundreds of thousands of craft without overloading the ground network or routing system. The scheme must also be tolerant to the delay and/or loss of initial packets, which may become more pervasive in future Internet routing and addressing architectures [17].
したがって、ROスキームは、地上ネットワークやルーティングシステムを過負荷にすることなく、数十万のクラフトのMNNによって同時に使用可能でなければなりません。また、スキームは、初期パケットの遅延および/または損失に耐性がなければなりません。これは、将来のインターネットルーティングとアドレス指定のアーキテクチャでより広範になる可能性があります[17]。
Since at least one traffic domain (PIES) requires connectivity to the Internet and it is possible that the Internet would provide transport for other domains at some distant point in the future, this requirement explicitly forbids the use of techniques that are known to scale poorly in terms of their global effects, like BGP, for the 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つのトラフィックドメイン（PIE）にはインターネットへの接続が必要であり、インターネットが将来のいくつかの遠い時点で他のドメインに輸送を提供する可能性があるため、この要件は、スケーリングが不十分であることが知られている技術の使用を明示的に禁止しています。ROの目的のために、BGPなどのグローバルな影響の条件。以前のOSIベースのATNシステムでは、モバイルネットワークへの接続を維持するためのIDRPと「アイランド」コンセプトを使用しましたが、大規模な展開ではテストされていませんでした。BGPを使用したボーイングシステムによる接続は、接続性を維持するために世界中を移動する飛行機が発表され、引き出しが発表されます[10]。これは、グローバルなインターネットルーティングテーブルのかなりの量の解約に貢献することがわかったため、多くの理由で望ましくないため、将来回避する必要があります。
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.
要件のバージョンで使用されている航空機の数の特定のスケーリング係数は、IPv6プレフィックス割り当てリクエストのために、ICAOドラフトのARINの手紙で引用された推定機器よりも大きい桁大きなものです。異なるグループが作成した他のいくつかの推定があり、IETFでは、より大きな推定値を使用することはより保守的であると感じられました。この桁の違いがある場合でも、生の数は推定された携帯電話ユーザーの数よりも数桁低いことに注意してください。。
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スキームのシグナリングオーバーヘッドがスループットよりもはるかにゆっくりと上昇することが重要です。Flows 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に関連するパケットの嵐を防ぐため。
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スキームは、バインディングアップデート（BU）の受信者が、MRが請求されたCOASのMRの所有権を検証することを許可する必要があります。
3. The RO scheme MUST ensure that only explicitly authorized MRs are able to perform a binding update for a specific MNP.
3. ROスキームは、明示的に承認されたMRSのみが特定の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ドメインとPIEによって大きく異なります。PIEの場合、トラフィックフローは陸生インターネットの使用に典型的であり、ROのセキュリティ要件は従来のモバイルIPv6 ROのセキュリティ要件と同じです。ただし、ATS/AOの場合、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番目のセキュリティ要件は、MNPのトラフィックを対象の被害者COAにリダイレクトする攻撃者によって開始される攻撃の洪水攻撃のリスクによって推進されます。BindingsへのBindingsが送信されないようにするために、ROスキームは、MRが実際に主張するCOAを所有していることを何らかの形で検証する必要があります。Aeronauticsの目的のために、アクセスネットワークでイングレスフィルタリングが整っていると想定しても安全です。
To protect against "rogue" MRs or abuse of compromised MRs, the RO scheme MUST be capable of checking that an MR is actually authorized to perform a binding update for a specific MNP. To meet this requirement, it can be assumed that some aeronautical organization authority exists who can provide the required authorization, possibly in the form of a certificate that the MR possesses, signed by the aeronautical authority.
「不正な」MRSまたは妥協したMRSの乱用から保護するために、ROスキームは、MRが実際に特定のMNPの拘束力のある更新を実行することを許可されていることを確認できる必要があります。この要件を満たすために、おそらく航空機関によって署名されたMRが所有する証明書の形で、必要な承認を提供できる航空組織当局が存在すると想定できます。
It is also reasonable to assume trust relationships between each MR and a number of mobility anchor points topologically near to its CNs (these anchor points may be owned by the service providers), but it is not reasonable to assume that trust relationships can be established between an MR and any given CN itself. Within the onboard networks for ATS and AOS, it is reasonable to assume that the LFNs and MRs have some trust relationship.
また、各MRと多くのモビリティアンカー間の信頼関係をCNSに近いトポロジカルに想定することも合理的です（これらのアンカーポイントはサービスプロバイダーが所有する場合があります）が、信頼関係を確立できると仮定することは合理的ではありません。MRおよび特定のCN自体。ATSおよびAOSのオンボードネットワーク内では、LFNとMRSが何らかの信頼関係があると仮定することは合理的です。
It is felt by many individuals that by the time the IP-based ATN grows into production use, there will be a global ATN-specific Public Key Infrastructure (PKI) usable for ATS, though it is agreed that such a PKI does not currently exist and will take time to develop both technically and politically. This PKI could permit the establishment of trust relationships among any pair of ATS MNNs, MRs, or CNs through certificate paths, in contrast to the more limited amount of trust relationships described in the previous paragraph. While it has been suggested that early test and demonstration deployments with a more limited-scale PKI deployment can be used in the near-term, as a global PKI is developed, some parties still feel that assuming a global PKI may be overly bold in comparison to assuming trust relationships with anchor points. It is always possible to scale the anchor point assumption up if a PKI develops that allows the CNs themselves to become the anchor points. It is not possible to go back down in the other direction if a global PKI never emerges.
多くの個人が、IPベースのATNが生産の使用に成長する頃には、ATSに使用可能なグローバルなATN固有の公開キーインフラストラクチャ（PKI）が使用できると感じていますが、そのようなPKIは現在存在していないことが合意されています。そして、技術的にも政治的にも開発するのに時間がかかります。このPKIは、前の段落で説明されているより限られた量の信頼関係とは対照的に、証明書パスを介してATS MNN、MRS、またはCNSのペア間の信頼関係の確立を許可する可能性があります。グローバルなPKIが開発されているため、より限られた規模のPKI展開を備えた早期のテストとデモンストレーションの展開を短期的に使用できることが示唆されていますが、一部の当事者は、グローバルPKIが比較して過度に太字であると仮定すると依然として感じています。アンカーポイントとの信頼関係を想定すること。CNS自体がアンカーポイントになることを可能にするPKIが開発された場合、アンカーポイントの仮定を拡大することが常に可能です。グローバルな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から外挿されました - 「アプローチは安全である必要があります」と、MEXTワーキンググループの助けを借りてより具体的にしました。
Applications using new transport protocols, IPsec, or new IP options MUST be possible within an RO scheme.
ROスキーム内では、新しいトランスポートプロトコル、IPSEC、または新しいIPオプションを使用したアプリケーションが可能です。
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.
大規模な空港のCNSの場合、拘束力のあるキャッシュ状態管理機能は、到着と出発により、複数のサービスプロバイダーとモビリティイベントの量を備えた数百の飛行機を同時に扱うことができます。これがROプロトコルメカニズム自体に干渉しない場合、人間が結合キャッシュ構成にアクセスしてエラーの場合にそれを変更するための単純なインターフェイスを持つ機能が望ましいです。
It is desirable if the RO mechanism supports RO for nested MRs, since it is possible that, for PIES and astronaut spacesuits, PANs with MRs will need to be supported. For oceanic flight, ATS and AOS may also benefit from the capability of nesting MRs between multiple planes to provide a "reachback" to terrestrial ground stations rather than relying solely on lower rate HF or satellite systems. In either case, this mode of operation is beyond current strict requirements and is merely desirable. It is also noted that there are other ways to support these communications scenarios using routing protocols or other means outside of NEMO.
パイや宇宙飛行士の宇宙服については、MRSとのパンをサポートする必要がある可能性があるため、ROメカニズムがネストされたMRSのROをサポートする場合、それは望ましいです。海洋飛行の場合、ATSとAOSは、より低いレートのHFまたは衛星システムのみに依存するのではなく、地上の地上ステーションに「手のットルバック」を提供するためにMRSを営巣させる能力の恩恵を受ける可能性があります。どちらの場合でも、この動作モードは現在の厳格な要件を超えており、単に望ましいものです。また、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ドメイン内にあるため、少なくともLFNは航空の実行可能なROソリューションによってサポートされる必要があります。モバイルIPv6がポータブルコンシューマデバイスで使用される一般的なテクノロジーになると、PIESドメイン内のVMNは多数あると予想され、RO技術によってサポートされることが強く望まれますが、厳密には必要ありません。LMNは、月と火星への有人探査ミッションなど、将来の宇宙探査シナリオに潜在的に存在します。
An RO mechanism that is "general purpose", in that it is also readily usable in other contexts outside of aeronautics and space exploration, is desirable. For instance, an RO solution that is usable within Vehicular ad hoc Networks (VANETs) [19] or consumer electronics equipment [20] could satisfy this. The goal is for the technology to be more widely used and maintained outside the relatively small aeronautical networking community and its vendors, in order to make acquisitions and training faster, easier, and cheaper. This could also allow aeronautical networking to possibly benefit from future RO scheme optimizations and developments whose research and development is funded and performed externally by the broader industry and academic communities.
「汎用」であるROメカニズムは、航空や宇宙探査以外の他のコンテキストでも容易に使用できるという点で、望ましいものです。たとえば、車両のアドホックネットワーク（Vanets）[19]またはConsumer Electronics機器[20]で使用できるROソリューション[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を使用する将来の空中データリンクは、懸念事項としてリンク層セキュリティで開発されています。この開発は、このドキュメントのリストされたセキュリティ要件の1つを満たすのに役立ちます（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日、マドリードでのMEXT暫定会議の参加者は、これらの要件を固める上で重要でした。スティーブ・ブレットマーススキー、ティエリー・エルンスト、トニー・リー、ジャリ・アークコ、フィリップ・ワトソン、ロベルト・バルデッサリ、カルロス・ジーザス・バーナルド・カノ、マルセロ・バグヌロ、セルカン・エアズ、クリスチャン・バウアー、フレッド・テンプリン、アレクサンドルー・ペトレソー、トム・ハンダン、トム・ペトレズー、このドキュメントに組み込まれました。
Wesley Eddy's work on this document was performed at NASA's Glenn Research Center, primarily in support of NASA's Advanced Communications Navigations and Surveillance Architectures and System Technologies (ACAST) project, and the NASA Space Communications Architecture Working Group (SCAWG) in 2005 and 2006.
このドキュメントに関するWesley Eddyの作業は、主に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.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、2005年1月。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[4] エルンスト、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] Ng、C.、Thubert、P.、Watari、M。、およびF. Zhao、「ネットワークモビリティルート最適化問題ステートメント」、RFC 4888、2007年7月。
[7] ICAO Asia/Pacific Regional Office, "Required Communication Performance (RCP) Concepts - An Introduction", Informal South Pacific ATS Coordinating Group 20th meeting, Agenda Item 7, January 2006.
[7] 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] Ng、C.、Zhao、F.、Watari、M。、およびP. Thubert、「ネットワークモビリティルート最適化ソリューションスペース分析」、RFC 4889、2007年7月。
[9] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.
[9] Kempf、J。、「ネットワークベースのローカライズされたモビリティ管理（NetLMM）の目標」、RFC 4831、2007年4月。
[10] Dul, A., "Global IP Network Mobility", Presentation at IETF 62 Plenary, March 2005.
[10] Dul、A。、「グローバルIPネットワークモビリティ」、IETF 62 Plernary、2005年3月でのプレゼンテーション。
[11] Ivancic, W., Paulsen, P., Stewart, D., Shell, D., Wood, L., Jackson, C., Hodgson, D., Northam, J., Bean, N., Miller, E., Graves, M., and L. Kurisaki, "Secure, Network-centric Operations of a Space-based Asset: Cisco Router in Low Earth Orbit (CLEO) and Virtual Mission Operations Center (VMOC)", NASA Technical Memorandum TM-2005-213556, May 2005.
[11] Ivancic、W.、Paulsen、P.、Stewart、D.、Shell、D.、Wood、L.、Jackson、C.、Hodgson、D.、Northam、J.、Bean、N.、Miller、E。、Graves、M.、およびL. kurisaki、「宇宙ベースの資産の安全なネットワーク中心の運用：ローアース軌道（CLEO）および仮想ミッションオペレーションセンター（VMOC）のシスコルーター」、NASAテクニカルメモTM-2005-213556、2005年5月。
[12] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007.
[12] Ng、C.、Ernst、T.、Paik、E。、およびM. Bagnulo、「ネットワークモビリティサポートにおけるマルチホミングの分析」、RFC 4980、2007年10月。
[13] Davis, T., "Mobile Internet Platform Aviation Requirements", Work in Progress, September 2006.
[13] Davis、T。、「モバイルインターネットプラットフォーム航空要件」、2006年9月、進行中の作業。
[14] ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, January 2007.
[14] ICAO WG-N SWG1、「候補ATN IPS Mobility Solutionsの分析」、2007年1月、タイ、バンコク、ワーキングペーパー6の会議。
[15] Davis, T., "Aviation Global Internet Operations Requirements", ICAO WG-N, Sub-Working-Group N1, Information Paper #4 (IP4), September 2006.
[15] Davis、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] Zhang、L。およびS. Brim、「新しいルーティングとアドレス指定の建築設計のための分類法」、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] Baldessari、R。、「NEMOルート最適化のためのC2C-Cコンソーシアム要件」、2007年7月、進行中の作業。
[20] Ng, C., "Consumer Electronics Requirements for Network Mobility Route Optimization", Work in Progress, February 2008.
[20] Ng、C。、「ネットワークモビリティルートの最適化のための家電要件」、2008年2月、進行中の作業。
[21] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", Work in Progress, September 2006.
[21] IVANCIC、W。、「マルチドミー、マルチホームモバイルネットワーク」、2006年9月、進行中の作業。
[22] CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 000.0-G-1 Draft Green Book, December 2006.
[22] CCSDS、「Cislunar Space InternetWorking：Architecture」、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 Space Communication Architecture Working Group、「2005-2030のNASAスペースコミュニケーションおよびナビゲーションアーキテクチャの推奨」、SCAWG最終レポート、2006年5月。
The current standards for aeronautical networking are based on the ISO OSI networking stack and are referred to as the Aeronautical Telecommunications Network (ATN). While standardized, the ATN has not been fully deployed and seems to be in only limited use compared to its full vision and potential. The International Civil Aviation Organization (ICAO) is a part of the United Nations that produces standards for aeronautical communications. The ICAO has recognized that an ATN based on OSI lacks the widespread commercial network support required for the successful deployment of new, more bandwidth-intensive ATN applications, and has recently been working towards a new IPv6-based version of the ATN.
航空ネットワーキングの現在の基準は、ISO OSIネットワーキングスタックに基づいており、航空通信ネットワーク（ATN）と呼ばれています。標準化されていますが、ATNは完全に展開されておらず、その完全なビジョンと潜在能力と比較して使用されているようです。国際民間航空機関（ICAO）は、航空通信の基準を生み出す国連の一部です。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内で行われた作業により、NEMOテクノロジーは、グローバルなIPベースのモバイルネットワーキングをサポートするための使用の有望な候補として特定されました。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標準など、航空使用に適応できる有名な商用データリンクに加えて、空中使用のためにさらにいくつかの専門的なテクノロジーが存在するか提案されています：o VHFデータリンク（VDL）は、デジタル音声とデータのさまざまなミックスをかなり低いレートでサポートできる117.975-137 MHz範囲で4つの動作モードを指定します。低料金は、航空使用のために国際的に割り当てられた25 kHzチャネル内で動作する必要性によって駆動されます。VDLモード2は航空機に多少広く展開されており、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メッセージングは、フライト中にいくつかのタイプのイベント通知の送信と処理を自動化します。ACARは一般に高レベルのメッセージングシステムですが、より具体的な「プレーン古いACAR」（POA）は、VDLおよびその他のデータリンクの採用前にACARSシステムが使用した特定のレガシーRFインターフェイスを指します。IPベースのネットワーキングとPOAを介した高度なアプリケーションのサポートは実行可能ではありません。
o Broadband Aeronautical Multi-carrier Communications (B-AMC) is a hybrid cellular system that uses multi-carrier CDMA from ground-to-air and Orthogonal Frequency Division Multiplexing (OFDM) in the air-to-ground direction. B-AMC runs in the L-band of spectrum and is adapted from the Broadband-VHF (B-VHF) technology originally developed to operate in the VHF spectrum. L-band use is intended to occupy the space formerly allocated for Distance Measuring Equipment (DME) using channels with greater bandwidth than are available than in the VHF band, where analog voice use will continue to be supported. B-AMC may permit substantially higher data rates than existing deployed air-ground links.
o Broadband Aeronautical Multi-Carrier Communications（B-AMC）は、空対空および直交周波数分裂（OFDM）から地上方向のマルチキャリアCDMAを使用するハイブリッドセルラーシステムです。B-AMCは、スペクトルのLバンドで実行され、VHFスペクトルで動作するために元々開発されたBroadband-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.
o 万能マルチチャネル航空通信システム（AMACS）は、50〜400 kHzチャネルでLバンドで動作し、VDLモード4のメディアアクセス技術を使用するためのモバイル通信（GSM）の物理層のグローバルシステムの適応です。AMACは、展開された特定のチャネル化ポリシーに応じて、数百kbps範囲のデータレートを許可する場合があります。
o Project 34 (P34) is a wideband public-safety radio system capable of being used in the L-band. P34 is designed to offer several hundred kbps of capacity specifically for IP-based packet networking. It uses OFDM in 50, 100, or 150 kHz channels and 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ができると予想されます。
IP itself is only in limited operational use for communicating with spacecraft currently (e.g., the Surry Satellite Technology Limited (SSTL) Disaster Monitoring Constellation (DMC) satellites). Future communications architectures include IP-based networking as an essential building block, however. The Consultative Committee for Space Data Systems (CCSDS) has a working group that is producing a network architecture for using IP-based communications in both manned and unmanned near-Earth missions, and has international participation towards this goal [22]. NASA's Space Communications Architecture Working Group (SCAWG) also has developed an IP-based multi-mission networking architecture [23]. Neither of these is explicitly based on Mobile IP technologies, but NEMO is usable within these architectures and they may be extended to include NEMO when/if the need becomes apparent.
IP自体は、現在宇宙船との通信に限られた運用上の使用のみです（例：Surry Satellite Technology Limited（SSTL）災害監視星座（DMC）衛星）。ただし、将来のコミュニケーションアーキテクチャには、IPベースのネットワーキングが必須ビルディングブロックとして含まれています。宇宙データシステム協議委員会（CCSDS）には、有人および無人の近い地球ミッションの両方でIPベースのコミュニケーションを使用するためのネットワークアーキテクチャを作成しているワーキンググループがあり、この目標に向けて国際参加を持っています[22]。NASAのSpace Communications Architecture Working Group（SCAWG）も、IPベースのマルチミッションネットワーキングアーキテクチャを開発しました[23]。これらはどちらもモバイルIPテクノロジーに明示的に基づいていませんが、NEMOはこれらのアーキテクチャ内で使用可能であり、必要性が明らかになった場合//場合にNEMOを含むように拡張される場合があります。
Authors' Addresses
著者のアドレス
Wesley M. Eddy Verizon Federal Network Systems NASA Glenn Research Center 21000 Brookpark Road, MS 54-5 Cleveland, OH 44135 USA
Wesley M. Eddy Verizon Federal Network Systems NASA Glenn Research Center 21000 Brookpark Road、MS 54-5 Cleveland、OH 44135 USA
EMail: weddy@grc.nasa.gov
Will Ivancic NASA Glenn Research Center 21000 Brookpark Road, MS 54-5 Cleveland, OH 44135 USA
ウィルIVANCIC NASAグレンリサーチセンター21000 Brookpark Road、MS 54-5クリーブランド、OH 44135 USA
Phone: +1-216-433-3494
EMail: William.D.Ivancic@grc.nasa.gov
Terry Davis Boeing Commercial Airplanes P.O.Box 3707 MC 0Y-96 Seattle, WA 98124-2207 USA
テリーデイビスボーイングコマーシャル飛行機P.O.ボックス3707 MC 0Y-96シアトル、ワシントン
Phone: 206-280-3715 EMail: Terry.L.Davis@boeing.com
電話：206-280-3715メール：terry.l.davis@boeing.com