Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9914 Independent
Updates: 6550, 6553, 8138 R.A. Jadhav
Category: Standards Track AccuKnox
ISSN: 2070-1721 M. Richardson
Sandelman
April 2026
The Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550) enables data packet routing along a Destination-Oriented Directed Acyclic Graph (DODAG). However, the default route establishment mechanism relies on hop-by-hop forwarding along the DODAG, which may not always provide optimal routing efficiency. This document introduces the concept of Destination Advertisement Object (DAO) Projection, a mechanism that allows a RPL Root or an external controller to install optimized routes within the RPL domain. DAO Projections enable the creation of optimized unicast or multicast routes that do not strictly follow the DODAG structure, thereby improving routing efficiency, reliability, availability, and resource utilization in the RPL domain. This document specifies two types of Projected Routes (P-Routes) -- Storing Mode and Non-Storing Mode -- and outlines the signaling procedures necessary to establish, maintain, and remove these routes. This document updates RFCs 6550, 6553, and 8138.
低電力および損失の多いネットワーク用ルーティング プロトコル (RPL) (RFC 6550) により、Destination-Oriented Directed Acyclic Graph (DODAG) に沿ったデータ パケットのルーティングが可能になります。ただし、デフォルトのルート確立メカニズムは DODAG に沿ったホップバイホップ転送に依存しているため、最適なルーティング効率が常に提供されるとは限りません。このドキュメントでは、RPL ルートまたは外部コントローラーが RPL ドメイン内に最適化されたルートをインストールできるようにするメカニズムである、宛先アドバタイズメント オブジェクト (DAO) プロジェクションの概念を紹介します。DAO プロジェクションを使用すると、DODAG 構造に厳密に従わない最適化されたユニキャストまたはマルチキャスト ルートの作成が可能になり、RPL ドメインでのルーティングの効率、信頼性、可用性、およびリソース使用率が向上します。この文書では、保存モードと非保存モードという 2 つのタイプの投影ルート (P ルート) を指定し、これらのルートの確立、維持、削除に必要なシグナリング手順の概要を説明します。この文書は RFC 6550、6553、および 8138 を更新します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9914.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9914 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
2.1. Requirements Language
2.2. Terms and Concepts
2.3. Glossary
2.4. Domain Terms
2.4.1. Projected Route
2.4.2. Projected DAO
2.4.3. Path
2.4.4. Routing Stretch
2.4.5. Track
3. Context and Goal
3.1. RPL Applicability
3.2. Multi-Topology Routing and Loop Avoidance
3.3. Requirements
3.3.1. Loose Source Routing
3.3.2. Forward Routes
3.4. On Tracks
3.4.1. Building Tracks with RPL
3.4.2. Tracks and RPL Instances
3.5. Path Signaling
3.5.1. Using Storing Mode Segments
3.5.2. Using Non-Storing Mode Joining Tracks
3.6. Complex Tracks
3.7. Scope and Expectations
3.7.1. External Dependencies
3.7.2. Relationship to Other IETF Specifications
4. Extending and Amending Existing RFCs
4.1. Extending RFC 6550
4.1.1. Projected DAO
4.1.2. Projected DAO Acknowledgment
4.1.3. Via Information Option
4.1.4. Sibling Information Option
4.1.5. P-DAO Request
4.1.6. Amending the RPI
4.1.7. Additional Flag in the RPL DODAG Configuration Option
4.2. Extending RFC 6553
4.3. Extending RFC 8138
5. New RPL Control Messages and Options
5.1. New P-DAO Request Control Message
5.2. New PDR-ACK Control Message
5.3. Via Information Options
5.4. Sibling Information Option
6. Root-Initiated Routing State
6.1. RPL Network Setup
6.2. Requesting a Track
6.3. Identifying a Track
6.4. Installing a Track
6.4.1. Signaling a Projected Route
6.4.2. Installing a Track Segment with a Storing Mode P-Route
6.4.3. Installing a Protection Path with a Non-Storing Mode
P-Route
6.5. Tearing Down a P-Route
6.6. Maintaining a Track
6.6.1. Maintaining a Track Segment
6.6.2. Maintaining a Protection Path
6.7. Encapsulating and Forwarding Along a Track
6.8. Compression of RPL Artifacts
7. Less-Constrained Variations
7.1. Storing Mode Main DODAG
7.2. A Track as a Full DODAG
8. Profiles
9. Backwards Compatibility
10. Security Considerations
11. IANA Considerations
11.1. RPL DODAG Configuration Option Flag
11.2. Elective 6LoWPAN Routing Header Type
11.3. Critical 6LoWPAN Routing Header Type
11.4. Registry for RPL Option Flags
11.5. RPL Control Codes
11.6. RPL Control Message Options
11.7. Registry for Projected DAO Request Flags
11.8. Registry for Projected DAO Request Acknowledgment
(PDR-ACK) Flags
11.9. Registry for PDR-ACK Acceptance Status Values
11.10. Registry for PDR-ACK Rejection Status Values
11.11. Registry for Via Information Options Flags
11.12. Registry for Sibling Information Option Flags
11.13. Destination Advertisement Object Flag
11.14. Destination Advertisement Object Acknowledgment Flag
11.15. ICMPv6 Error Code
11.16. RPL Rejection Status Values
12. References
12.1. Normative References
12.2. Informative References
Acknowledgments
Authors' Addresses
The Routing Protocol for Low-Power and Lossy Networks (RPL) [RPL], is a Distance Vector protocol that is well-suited for application in a variety of low-energy Internet of Things (IoT) networks where constrained nodes cannot maintain the full view of the topology and stretched paths are acceptable (as opposed to the signaling and state overhead involved in maintaining the shortest paths across). Additionally, RPL is anisotropic, meaning that its operation depends on the orientation of the links, down from or up towards the Root, with the default route advertised down and more-specific paths advertised up along a limited set of links.
Routing Protocol for Low-Power and Lossy Networks (RPL) [RPL] は、制約のあるノードがトポロジの全体像を維持できず、(最短パスの維持に伴うシグナリングや状態のオーバーヘッドとは対照的に) 延長されたパスが許容されるさまざまな低エネルギー モノのインターネット (IoT) ネットワークでのアプリケーションに適したディスタンス ベクトル プロトコルです。さらに、RPL は異方性です。これは、その動作が、ルートから下方向またはルートに向かって上方向のリンクの方向に依存し、限定されたリンクのセットに沿ってデフォルト ルートが下方向にアドバタイズされ、より具体的なパスが上方向にアドバタイズされることを意味します。
RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) in which the Root often acts as the border router to connect the RPL domain to the IP backbone. Routers inside the DODAG route along the graph up towards the Root for the default route and down towards destinations in the RPL domain for more-specific routes. As a prerequisite, this specification expects a pre-existing RPL Instance with an associated DODAG and RPL Root, which are referred to as the main Instance, main DODAG, and main Root, respectively. The main Instance is operated in RPL Non-Storing Mode of Operation (MOP).
RPL は宛先指向有向非巡回グラフ (DODAG) を形成します。DODAG では、多くの場合、ルートがボーダー ルーターとして機能し、RPL ドメインを IP バックボーンに接続します。DODAG 内のルーターは、デフォルト ルートの場合はグラフに沿ってルートに向かって上にルートし、より具体的なルートの場合は RPL ドメイン内の宛先に向かって下にルートします。前提条件として、この仕様では、関連付けられた DODAG および RPL ルートを持つ既存の RPL インスタンスを想定しています。これらは、それぞれメイン インスタンス、メイン DODAG、およびメイン ルートと呼ばれます。メイン インスタンスは、RPL 非保存動作モード (MOP) で動作します。
With this specification, an abstract routing function called a Path Computation Element (PCE) (e.g., located in a central controller or collocated with the main Root) interacts with the main Root to compute additional paths between nodes in the main Instance. In Non-Storing Mode, the base topological information to be passed to the PCE, i.e., the knowledge of the main DODAG, is already available at the Root. This specification introduces protocol extensions that enrich the topological information available to the Root with sibling relationships that are usable but not leveraged to form the main DODAG.
この仕様では、パス計算要素 (PCE) と呼ばれる抽象ルーティング関数 (たとえば、中央コントローラーに配置されるか、メイン ルートと併置される) がメイン ルートと対話して、メイン インスタンス内のノード間の追加のパスを計算します。非保存モードでは、PCE に渡される基本的なトポロジ情報、つまりメイン DODAG の知識は、ルートですでに利用可能です。この仕様では、ルートで利用できるトポロジ情報を、使用可能ではあるがメイン DODAG の形成には活用されない兄弟関係で強化するプロトコル拡張機能を導入しています。
Based on usage, path length, and knowledge of available resources such as battery levels and reservable buffers in the nodes, the PCE, which has a global visibility of the system, can optimize the computed routes for application needs, including the capability to provide path redundancy. This specification also introduces protocol extensions that enable the Root to project (i.e., advertise from a remote location) the computed paths in the RPL domain as Projected Routes (a.k.a. P-Routes) on behalf of the PCE.
使用状況、パスの長さ、ノード内のバッテリ レベルや予約可能なバッファなどの利用可能なリソースの知識に基づいて、システムをグローバルに把握できる PCE は、パスの冗長性を提供する機能など、アプリケーションのニーズに合わせて計算されたルートを最適化できます。この仕様では、ルートが PCE に代わって RPL ドメイン内の計算されたパスを投影ルート (別名 P ルート) として投影 (つまり、リモートの場所からアドバタイズ) できるようにするプロトコル拡張も導入しています。
A P-Route may be installed in either Storing or Non-Storing Mode, potentially resulting in hybrid situations where the Mode in which the P-Route operates is different from that of the RPL main Instance. P-Routes can be used as stand-alone segments meant to reduce the size of the Source Routing Headers (SRHs), leveraging loose source routing operations down the main RPL DODAG. A P-Route can also be used as a protection path, and it can be combined and interleaved with other P-Routes to form a recovery graph called a Track. A Track is signaled as a separate RPL Instance that is associated with a main RPL Instance such that the RPL routers that form the Track are also members of the main DODAG. The Track provides underlay shortcuts using its own RIB, which is separate from the RIB of the main Instance and has a higher precedence.
P-Route は保存モードまたは非保存モードのいずれかでインストールできます。その結果、P-Route が動作するモードが RPL メイン インスタンスのモードと異なるハイブリッド状況が発生する可能性があります。P-Routes は、メイン RPL DODAG の下で緩やかなソース ルーティング操作を活用して、ソース ルーティング ヘッダー (SRH) のサイズを削減することを目的としたスタンドアロン セグメントとして使用できます。P ルートは保護パスとしても使用でき、他の P ルートと組み合わせてインターリーブして、トラックと呼ばれる回復グラフを形成できます。トラックは、メイン RPL インスタンスに関連付けられた別個の RPL インスタンスとして通知されるため、トラックを形成する RPL ルーターもメイン DODAG のメンバーになります。トラックは、メイン インスタンスの RIB とは別の、より高い優先順位を持つ独自の RIB を使用してアンダーレイ ショートカットを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
In addition, the terms "Extends" and "Amends" are used as per [NEW-TAGS], Section 3.
さらに、「延長」および「修正」という用語は、[NEW-TAGS] セクション 3 に従って使用されます。
In this document, readers will encounter terms and concepts that are discussed in the following:
このドキュメントでは、読者は以下で説明する用語や概念に遭遇します。
* "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RPL]
* 「RPL: 低電力および損失の多いネットワークのための IPv6 ルーティング プロトコル」 [RPL]
* "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)" [RFC9030]
* 「IEEE 802.15.4 (6TiSCH) のタイムスロットチャネルホッピングモードを介した IPv6 のアーキテクチャ」 [RFC9030]
* "Deterministic Networking Architecture" [RFC8655]
* 「決定論的ネットワーキングアーキテクチャ」[RFC8655]
* "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008]
* 「RPL データ プレーンでの RPI オプション タイプ、ソース ルートのルーティング ヘッダー、および IPv6-in-IPv6 カプセル化の使用」 [RFC9008]
* "Reliable and Available Wireless (RAW) Architecture" [RAW-ARCH]
* 「信頼性が高く利用可能なワイヤレス (RAW) アーキテクチャ」 [RAW-ARCH]
* "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102]
* 「低電力および損失の多いネットワークのルーティングで使用される用語」[RFC7102]
The 6TiSCH, Deterministic Networking (DetNet), and RAW architectures utilize the terms "Track" and "recovery graph" to represent the same concept even though they are in different environments. This document uses "Track" to represent that concept and only builds Tracks that are DODAGs, meaning that all links are oriented from ingress to egress. This specification also utilizes the terms "segment" and "protection path", which are also defined in the RAW architecture.
6TiSCH、Deterministic Networking (DetNet)、および RAW アーキテクチャは、異なる環境にある場合でも、「トラック」および「リカバリ グラフ」という用語を使用して同じ概念を表します。このドキュメントでは、その概念を表すために「トラック」を使用し、DODAG であるトラックのみを構築します。これは、すべてのリンクが入力から出力に向けられていることを意味します。この仕様では、RAW アーキテクチャでも定義されている「セグメント」および「保護パス」という用語も使用します。
As opposed to routing trees, RPL DODAGs are typically constructed to provide redundancy and dynamically adapt the forwarding operation to the state of the Low-Power and Lossy Network (LLN) links. Note that the plain forwarding operation over DODAGs does not provide redundancy for all nodes, since at least the node nearest to the Root does not have an alternate feasible successor.
ルーティング ツリーとは対照的に、RPL DODAG は通常、冗長性を提供し、低電力および損失の多いネットワーク (LLN) リンクの状態に転送操作を動的に適応させるように構築されています。DODAG を介した単純な転送操作では、すべてのノードに冗長性が提供されないことに注意してください。これは、少なくともルートに最も近いノードには代替のフィージブル サクセサがないためです。
RAW solves that problem by defining protection paths that can be interleaved to form new paths that can be activated dynamically upon failures. This requires additional control in order to make the routing decision early enough along the Track to route around the failure.
RAW は、障害時に動的にアクティブ化できる新しいパスを形成するためにインターリーブできる保護パスを定義することで、この問題を解決します。これには、障害を回避するためにトラックに沿って十分早くルーティングの決定を行うために、追加の制御が必要です。
RAW only uses single-ended DODAGs, meaning that they can be reversed in another DODAG by reversing all the links. The ingress of the Track is the Root of the DODAG, whereas the egress is the Root of the reversed DODAG. From the RAW perspective, single-ended DODAGs are special Tracks that only have forward links, and that can be leveraged to provide protection services by defining destination-oriented protection paths within the DODAG.
RAW はシングルエンド DODAG のみを使用します。これは、すべてのリンクを反転することで、別の DODAG でそれらを反転できることを意味します。トラックの入力は DODAG のルートですが、出力は逆の DODAG のルートです。RAW の観点から見ると、シングルエンド DODAG は、順方向リンクのみを持つ特別なトラックであり、DODAG 内で宛先指向の保護パスを定義することによって保護サービスを提供するために利用できます。
This document often uses the following abbreviations:
このドキュメントでは、次の略語がよく使用されます。
6LoRH:
6LoRH:
6LoWPAN Routing Header
6LoWPANルーティングヘッダー
6LR:
6LR:
6LoWPAN Router (e.g., a RPL router in an LLN)
6LoWPAN ルーター (LLN 内の RPL ルーターなど)
ARQ:
ARQ:
Automatic Repeat Request (in other words, retries)
自動繰り返しリクエスト (つまり、再試行)
CMO:
CMO:
Control Message Option
制御メッセージオプション
DAG:
DAG:
Directed Acyclic Graph
有向非巡回グラフ
DAO:
ダオ:
Destination Advertisement Object
宛先アドバタイズメントオブジェクト
DIO:
ディオ:
DODAG Information Object
DODAG 情報オブジェクト
DODAG:
ドーダグ:
Destination-Oriented Directed Acyclic Graph. A DAG with only one vertex (i.e., node) that has no outgoing edge (i.e., link).
宛先指向の有向非巡回グラフ。発信エッジ (リンク) を持たない頂点 (ノード) が 1 つだけある DAG。
FEC:
FEC:
Forward Error Correction
前方誤り訂正
GUA:
グア:
Global Unicast Address
グローバルユニキャストアドレス
HARQ:
ハルク:
Hybrid Automatic Repeat Request (combines FEC and ARQ)
ハイブリッド自動再送要求 (FEC と ARQ を組み合わせた)
LLN:
LLN:
Low-Power and Lossy Network
低電力で損失の多いネットワーク
MOP:
モップ：
Mode of Operation
動作モード
NSM-VIO:
NSM-VIO:
Non-Storing Mode Via Information Option. Source-routed VIO used in Non-Storing Mode P-DAO messages.
情報オプションによる非保存モード。非保存モード P-DAO メッセージで使用されるソース ルーテッド VIO。
P-DAO:
P-DAO:
Projected DAO
予測されるDAO
P-DAO-ACK:
P-DAO-ACK:
Projected DAO Acknowledgment
予想される DAO 承認
P-DAO-REQ:
P-DAO-REQ:
Projected DAO Request
予想される DAO リクエスト
P-Route:
Pルート:
Projected Route
予想ルート
PCE:
PCE:
Path Computation Element
パス計算要素
PDR-ACK
PDR-ACK
Projected DAO Request Acknowledgment
予測される DAO リクエストの承認
PLR:
PLR:
Point of Local Repair
現地修理のポイント
RAL:
RAL:
RPL-Aware Leaf
RPL 対応リーフ
RAN:
ラン：
RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
RPL 対応ノード (RPL ルーターまたは RPL 対応リーフのいずれか)
RH:
RH:
Routing Header
ルーティングヘッダー
RIB:
リブ：
Routing Information Base (i.e., the routing table)
ルーティング情報ベース (つまり、ルーティング テーブル)
RPI:
RPI:
RPL Packet Information
RPLパケット情報
RPL:
RPL:
Routing Protocol for Low-Power and Lossy Networks
低電力および損失の多いネットワーク向けのルーティング プロトコル
RTO:
RTO:
RPL Target Option
RPLターゲットオプション
RUL:
規則:
RPL-Unaware Leaf
RPL-非認識リーフ
SIO:
SIO:
Sibling Information Option
兄弟情報オプション
SLO:
SLO:
Service Level Objective
サービスレベル目標
SM-VIO:
SM-VIO:
Storing Mode Via Information Option. Strict VIO used in Storing Mode P-DAO messages.
情報オプションによる保存モード。保存モード P-DAO メッセージで使用される厳密な VIO。
SRH:
SRH:
Source Routing Header (i.e., IPv6 RH type 3); see Section 2.4.5.7.2.
ソース ルーティング ヘッダー (つまり、IPv6 RH タイプ 3)。セクション2.4.5.7.2を参照してください。
SRH-6LoRH:
SRH-6LoRH:
Source Routing Header 6LoRH. A compressed form of SRH defined in "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header" [RFC8138].
ソースルーティングヘッダー 6LoRH。「IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header」[RFC8138] で定義された SRH の圧縮形式。
TIO:
ティオ:
Transit Information Option
交通情報オプション
ULA:
ULA:
Unique Local Address
固有のローカルアドレス
VIO:
VIO:
Via Information Option. It can be an SM-VIO or NSM-VIO.
情報オプション経由。SM-VIO または NSM-VIO にすることができます。
This specification uses the terminology defined in the sections that follow.
この仕様では、以降のセクションで定義される用語を使用します。
A RPL P-Route is a RPL route that is computed remotely by a PCE and installed and maintained by a RPL Root on behalf of the PCE. It is installed as a state that signals that destinations (i.e., Targets) are reachable via or along a sequence of nodes.
RPL P ルートは、PCE によってリモートで計算され、PCE に代わって RPL ルートによってインストールおよび維持される RPL ルートです。これは、一連のノードを介して、または一連のノードに沿って目的地 (つまり、ターゲット) に到達可能であることを知らせる状態としてインストールされます。
A Projected DAO (P-DAO) is a DAO message that is used to install a P-Route.
投影された DAO (P-DAO) は、P-Route をインストールするために使用される DAO メッセージです。
Quoting (non-normatively) the definition of path in Section 1.3.3 of [INT-ARCH]:
[INT-ARCH] のセクション 1.3.3 のパスの定義を (非規範的に) 引用します。
At a given moment, all the IP datagrams from a particular source host to a particular destination host will typically traverse the same sequence of gateways. We use the term "path" for this sequence. Note that a path is uni-directional; it is not unusual to have different paths in the two directions between a given host pair.
特定の時点で、特定の送信元ホストから特定の宛先ホストへのすべての IP データグラムは、通常、同じゲートウェイのシーケンスを通過します。このシーケンスには「パス」という用語を使用します。パスは単方向であることに注意してください。特定のホスト ペア間で双方向に異なるパスが存在することは珍しいことではありません。
See Section 3.1.1 of [RAW-ARCH] for a longer, more modern definition of path.
より長く、より現代的なパスの定義については、[RAW-ARCH] のセクション 3.1.1 を参照してください。
It follows that the general acceptance of a path is a linear sequence of nodes, as opposed to a multi-dimensional graph. In the context of this document, a path is observed by following one copy of a packet that is injected in a Track and possibly replicated within.
したがって、パスは多次元グラフではなく、ノードの線形シーケンスとして一般に受け入れられています。このドキュメントの文脈では、パスは、トラックに挿入され、場合によってはその中で複製されるパケットの 1 つのコピーをたどることによって観察されます。
RPL is anisotropic, meaning that it is directional or, more precisely, polar. RPL does not behave the same way "downwards" (Root towards leaves) with _multicast_ DODAG Information Object (DIO) messages that form the DODAG versus "upwards" (leaves towards Root) with _unicast_ DAO messages that follow the DODAG. This is in contrast with traditional IGPs that operate the same way in all directions and are thus called isotropic.
RPL は異方性であり、方向性、より正確には極性を意味します。RPL は、DODAG を形成する _multicast_ DODAG 情報オブジェクト (DIO) メッセージの「下向き」 (ルートに向かってルート) と、DODAG に続く _unicast_ DAO メッセージの「上向き」 (リーフに向かってルート) のように動作しません。これは、全方向に同じように動作するため等方性と呼ばれる従来の IGP とは対照的です。
The term "routing stretch" denotes the length of a path, in comparison to the length of the shortest path, which can be an abstract concept in RPL when the metrics are statistical and dynamic, and the concept of distance varies with the Objective Function.
「ルーティング ストレッチ」という用語は、最短パスの長さと比較したパスの長さを指します。これは、メトリックが統計的かつ動的である場合、RPL では抽象的な概念になる可能性があり、距離の概念は目的関数によって異なります。
The RPL DODAG optimizes Point-to-Multipoint (P2MP) paths (from the Root) and Multipoint-to-Point (MP2P) paths (towards the Root), but the Point-to-Point (P2P) traffic has to follow the same DODAG. Following the DODAG, the RPL datapath passes via a common parent in Storing Mode and via the Root in Non-Storing Mode. This typically involves more hops and more latency than the minimum possible for a directional (i.e., forward) P2P path that an isotropic protocol would compute. We refer to this elongated path as stretched.
RPL DODAG は、ポイントツーマルチポイント (P2MP) パス (ルートから) とマルチポイントツーポイント (MP2P) パス (ルートに向かう) を最適化しますが、ポイントツーポイント (P2P) トラフィックは同じ DODAG に従う必要があります。DODAG に続いて、RPL データパスは、保存モードでは共通の親を経由し、非保存モードではルートを経由します。これには通常、等方性プロトコルが計算する方向性 (つまり、順方向) P2P パスの最小値よりも多くのホップと長い遅延が伴います。この細長いパスを「伸びる」と呼びます。
The concept of Track is inherited from the 6TiSCH architecture [RFC9030] and equals that of a recovery graph in the RAW architecture [RAW-ARCH]. A Track is a networking graph that can be followed to transport packets with equivalent treatment; as opposed to other definitions of a path (see Section 1.3.3 of [INT-ARCH] and Section 3.1.1 of [RAW-ARCH], a Track is not necessarily linear. It may contain multiple paths that may fork and rejoin and that may enable RAW Packet Replication, Elimination, and Ordering Functions (PREOF).
Track の概念は 6TiSCH アーキテクチャ [RFC9030] から継承されており、RAW アーキテクチャ [RAW-ARCH] のリカバリ グラフの概念と同等です。トラックは、同等の処理でパケットを転送するために追跡できるネットワーキング グラフです。パスの他の定義 ([INT-ARCH] のセクション 1.3.3 および [RAW-ARCH] のセクション 3.1.1 を参照) とは対照的に、トラックは必ずしも線形であるとは限りません。トラックには、分岐および再結合する可能性のある複数のパスが含まれる場合があり、RAW パケットの複製、削除、順序付け機能 (PREOF) が有効になる可能性があります。
Figure 1 illustrates the mapping of the DODAG with the generic concept of a Track, with the DODAG Root acting as the ingress for the Track, and the mapping of protection paths and segments, i.e., only forward segments, meaning that they are directional and progressing towards the destination. Note that East is represented on the left since the packets are forwarded East-West.
図 1 は、トラックの一般的な概念を使用した DODAG のマッピングを示しています。このマッピングでは、DODAG ルートがトラックの入口として機能し、保護パスとセグメント (つまり、順方向セグメントのみ) のマッピングが示されています。これは、方向性があり、宛先に向かって進行することを意味します。パケットは東西に転送されるため、左側に東が表示されていることに注意してください。
North East North West
A ==> B ==> C -=- F ==> G ==> H T1
/ \ / \ /
I O E -=- T2
\ / \ / \
P ==> Q ==> R -=- T ==> U ==> V T3
South East South West
I: ingress
E: egress
T1, T2, T3: external targets
Figure 1: A Track and Its Components
図 1: トラックとそのコンポーネント
Of note:
注意:
I ==> A ==> B ==> C:
I ==> A ==> B ==> C:
A segment to targets F and O
ターゲット F と O へのセグメント
I --> F --> E:
I --> F --> E:
A protection path to targets T1, T2, T3
ターゲット T1、T2、T3 への保護パス
I, A, B, C, F, G, H, E:
I、A、B、C、F、G、H、E:
A path to T1, T2, T3
T1、T2、T3へのパス
This specification builds Tracks that are DODAGs oriented towards a Track ingress, and the forward direction for packets is from the Track ingress to one of the possible multiple Track egress nodes, which is also down the DODAG.
この仕様は、トラック入口に向けられた DODAG であるトラックを構築します。パケットの順方向は、トラック入口から、考えられる複数のトラック出口ノードの 1 つ (これも DODAG の下にあります) へです。
The Track may be strictly connected, meaning that the vertices are adjacent, or loosely connected, meaning that the vertices are connected using segments that are associated to the same Track.
トラックは、頂点が隣接していることを意味する厳密に接続されている場合もあれば、同じトラックに関連付けられたセグメントを使用して頂点が接続されていることを意味する、緩やかに接続されている場合もあります。
A RPLInstanceID (typically of a Local Instance) identifies a Track using the namespace owned by the Track ingress. For Local Instances, the TrackID is associated with the IPv6 address of the Track ingress that is used as the DODAGID, and together they form a unique identification of the Track (see the definition of DODAGID in Section 2 of [RPL]).
RPLInstanceID (通常はローカル インスタンスの) は、トラック入口が所有する名前空間を使用してトラックを識別します。ローカル インスタンスの場合、TrackID は DODAGID として使用されるトラック入口の IPv6 アドレスに関連付けられ、これらが合わせてトラックの一意の識別を形成します ([RPL] のセクション 2 の DODAGID の定義を参照)。
The term "namespace" is used to refer to the scope of the TrackID. The TrackID is locally significant within its namespace. For Local Instances, the namespace is identified by the DODAGID for the Track, and the tuple (DODAGID, TrackID) is globally unique. For Global Instances, the namespace is the whole RPL domain.
「名前空間」という用語は、TrackID の範囲を指すために使用されます。TrackID は、名前空間内でローカルに重要です。ローカル インスタンスの場合、名前空間はトラックの DODAGID によって識別され、タプル (DODAGID、TrackID) はグローバルに一意です。グローバル インスタンスの場合、名前空間は RPL ドメイン全体です。
A Complex Track is a Track that can be traversed via more than one path (e.g., a DODAG).
複雑なトラックは、複数のパス (DODAG など) を介して通過できるトラックです。
Stand alone refers to a segment or a protection path that is installed with a single P-DAO that fully defines the path, e.g., a stand-alone segment is installed with a single Storing Mode Via Information Option (SM-VIO) all the way between the ingress and egress.
スタンドアロンとは、パスを完全に定義する単一の P-DAO とともにインストールされるセグメントまたは保護パスを指します。たとえば、スタンドアロン セグメントは、イングレスとエグレスの間で単一の Storing Mode Via Information Option (SM-VIO) を使用してインストールされます。
This specification uses the term "stitching" to indicate that a Track is piped to another one, meaning that traffic out of the first Track is injected into the other Track.
この仕様では、「ステッチ」という用語を使用して、トラックが別のトラックにパイプされることを示します。これは、最初のトラックからのトラフィックが他のトラックに注入されることを意味します。
The concept of protection path is defined in the RAW architecture [RAW-ARCH] as an end-to-end forward serial path. With this specification, a protection path is installed by the Root of the main DODAG using a Non-Storing Mode P-DAO message, e.g., I --> F --> E in Figure 1.
保護パスの概念は、RAW アーキテクチャ [RAW-ARCH] でエンドツーエンドの順方向シリアル パスとして定義されています。この仕様では、保護パスは非保存モード P-DAO メッセージを使用してメイン DODAG のルートによってインストールされます (例: 図 1 の I --> F --> E)。
As the Non-Storing Mode Via Information Option (NSM-VIO) can only signal sequences of nodes, it takes one Non-Storing Mode P-DAO message per protection path to signal the structure of a Complex Track.
非保存モード情報経由オプション (NSM-VIO) はノードのシーケンスのみを通知できるため、複合トラックの構造を通知するには保護パスごとに 1 つの非保存モード P-DAO メッセージが必要です。
Each NSM-VIO for the same TrackID but with a different SegmentID signals a different protection path that the Track ingress adds to the topology.
同じ TrackID に対して異なる SegmentID を持つ各 NSM-VIO は、Track イングレスがトポロジに追加する異なる保護パスを信号で送信します。
A segment is a serial path formed by a strict sequence of nodes along which a P-Route is installed, e.g., I ==> A ==> B ==> C in Figure 1. With this specification, a segment is typically installed by the Root of the main DODAG using Storing Mode P-DAO messages. A segment is used as the topological edge of a Track joining the loose steps along the protection paths that form the structure of a Complex Track. The same segment may be leveraged by more than one protection path where the protection paths overlap.
セグメントは、P-Route がインストールされる厳密なノードのシーケンスによって形成されるシリアル パスです。たとえば、図 1 の I ==> A ==> B ==> C です。この仕様では、セグメントは通常、保存モード P-DAO メッセージを使用してメイン DODAG のルートによってインストールされます。セグメントは、複雑なトラックの構造を形成する保護パスに沿った緩やかなステップを結合するトラックのトポロジー エッジとして使用されます。保護パスが重複する場合、同じセグメントが複数の保護パスによって利用される場合があります。
Since this specification builds only DODAGs, all segments are oriented from the ingress (East) to egress (West), as opposed to the general Track model in the RAW architecture [RAW-ARCH], which allows North/South segments that can be bidirectional as well.
この仕様は DODAG のみを構築するため、RAW アーキテクチャ [RAW-ARCH] の一般的なトラック モデルとは対照的に、すべてのセグメントは入力 (東) から出力 (西) に向けられます。これにより、North/South セグメントも双方向にできるようになります。
The section of a segment refers to a continuous subset of a segment that may be replaced while the segment remains. For instance, in segment A=>B=>C=>D=>E=>F, say that the link C to D might be misbehaving. The section B=>C=>D=>E in the segment may be replaced by B=>C'=>D'=>E to route around the problem. The segment becomes A=>B=>C'=>D'=>E=>F.
セグメントのセクションとは、セグメントが残っている間に置き換えられるセグメントの連続したサブセットを指します。たとえば、セグメント A=>B=>C=>D=>E=>F では、C から D へのリンクが誤動作している可能性があるとします。問題を回避するには、セグメント内のセクション B=>C=>D=>E を B=>C'=>D'=>E に置き換えることができます。セグメントは A=>B=>C'=>D'=>E=>F になります。
In a Non-Storing Mode RPL domain, the IPv6 Routing Header used for source routing is the RPL Source Route Header as defined in [RFC6554]. This specification operates in that context and uses the acronym SRH to mean IPv6 RH type 3, as opposed to IPv6 RH type 4 defined in [RFC8754] for Segment Routing over IPv6 (SRv6) operation.
非保存モード RPL ドメインでは、ソース ルーティングに使用される IPv6 ルーティング ヘッダーは、[RFC6554] で定義されている RPL ソース ルート ヘッダーです。この仕様はその文脈で運用され、[RFC8754] でセグメント ルーティング オーバー IPv6 (SRv6) 動作に対して定義されている IPv6 RH タイプ 4 とは対照的に、IPv6 RH タイプ 3 を意味する頭字語 SRH を使用します。
If the network is a 6LoWPAN network, the expectation is that the SRH is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as specified in Section 5 of [RFC8138].
ネットワークが 6LoWPAN ネットワークの場合、[RFC8138] のセクション 5 で指定されているように、SRH が 6LoWPAN ルーティング ヘッダー (6LoRH) として圧縮およびエンコードされることが期待されます。
This specification uses the term "Segment Routing" generically to refer to using source routing to hop over segments. As such, forwarding along segments as specified hereafter can be seen as a form of Segment Routing [RFC8402] that leverages the RPL Source Route Header for its operation.
この仕様では、ソース ルーティングを使用してセグメントをホップすることを総称して「セグメント ルーティング」という用語を使用します。したがって、以降で指定するセグメントに沿った転送は、その動作に RPL ソース ルート ヘッダーを利用するセグメント ルーティング [RFC8402] の形式とみなすことができます。
Outside of LLNs, the RPL network may be less constrained and operated in Storing Mode, as discussed in Section 7.1. In that case, this specification could be extended to accommodate the SRv6 RH.
LLN の外では、セクション 7.1 で説明したように、RPL ネットワークは制約が少なく、ストレージ モードで動作する場合があります。その場合、この仕様は SRv6 RH に対応するように拡張できます。
RPL is optimized for situations where the power is scarce, the bandwidth is constrained, and the transmissions are unreliable. This matches the use case of an IoT LLN where RPL is typically used today and also situations of high relative mobility between the nodes in the network (a.k.a. swarming), e.g., within a variable set of vehicles with a similar global motion or a platoon of drones. In contrast, this specification only applies when the platoon has a relatively stable topology where the segments can be attributed reliability and availability for a certain lifetime; see [RAW-ARCH].
RPL は、電力が不足し、帯域幅が制限され、送信の信頼性が低い状況に最適化されます。これは、現在 RPL が一般的に使用されている IoT LLN のユースケースと、ネットワーク内のノード間の相対モビリティが高い状況 (別名スワーミング)、たとえば、同様のグローバル モーションを持つ車両の可変セット内やドローンの小隊内などに一致します。対照的に、この仕様は、小隊が比較的安定したトポロジを持ち、セグメントの信頼性と可用性が一定期間続く場合にのみ適用されます。[RAW-ARCH]を参照してください。
To reach this goal, RPL is primarily designed to minimize the control plane activity (i.e., the relative amount of routing protocol exchanges versus data traffic) and the amount of state that is maintained in each node. RPL does not need to converge, and it provides connectivity to most nodes most of the time.
この目標を達成するために、RPL は主に、コントロール プレーンのアクティビティ (つまり、データ トラフィックに対するルーティング プロトコル交換の相対量) と各ノードで維持される状態の量を最小限に抑えるように設計されています。RPL は収束する必要がなく、ほとんどの場合、ほとんどのノードへの接続を提供します。
RPL may form multiple topologies called Instances. Instances can be created to enforce various optimizations through Objective Functions or to reach out through different Root nodes. The concept of Objective Function allows adapting the activity of the routing protocol to the use case, e.g., type, speed, and quality of the LLN links.
RPL は、インスタンスと呼ばれる複数のトポロジを形成する場合があります。インスタンスを作成して、目的関数を通じてさまざまな最適化を強制したり、さまざまなルート ノードを通じてアクセスしたりすることができます。目的関数の概念により、ルーティング プロトコルのアクティビティをユース ケース (LLN リンクのタイプ、速度、品質など) に適応させることができます。
RPL Instances operate in parallel, unaware of one another. Yet, it is possible to define a model whereby if a route cannot be found in the current Instance A where a packet is being forwarded, then the router may look up the routing table (i.e., the RIB) in Instance B and forward along Instance B if the route is found there. To avoid loops, this must happen in such a way that the Instances themselves form a Directed Acyclic Graph (DAG) leading to the last resort Instance, which is the "lowest" Instance if Instance A is considered "higher" then Instance B. This specification uses underlay Tracks as "lower" Instances, with the main Instance being the "highest" of all.
RPL インスタンスは、お互いを意識することなく並行して動作します。ただし、パケットが転送されている現在のインスタンス A でルートが見つからない場合、ルーターはインスタンス B のルーティング テーブル (つまり RIB) を検索し、そこでルートが見つかった場合はインスタンス B に沿って転送するというモデルを定義することは可能です。ループを回避するには、これは、インスタンス自体が有向非巡回グラフ (DAG) を形成し、最後の手段のインスタンス (インスタンス A がインスタンス B よりも「上位」であるとみなされる場合の「最低」インスタンス) につながるような方法で行う必要があります。 この仕様では、アンダーレイ トラックを「下位」インスタンスとして使用し、メイン インスタンスがすべての中で「最高」になります。
The RPL Root is responsible for selecting the RPL Instance that is used to forward a packet coming from the backbone into the RPL domain and for setting the related RPL information in the packets. Each Instance creates its own routing table (i.e., a RIB) in participating nodes, and the RIB associated to the Instance must be used end to end in the RPL domain. To that effect, RPL tags the packets with the Instance ID in a Hop-by-Hop extension header. 6TiSCH leverages RPL for its distributed routing operations.
RPL ルートは、バックボーンからのパケットを RPL ドメインに転送するために使用される RPL インスタンスを選択し、パケット内に関連する RPL 情報を設定する責任があります。各インスタンスは、参加ノードに独自のルーティング テーブル (RIB) を作成し、インスタンスに関連付けられた RIB を RPL ドメイン内でエンドツーエンドで使用する必要があります。その目的で、RPL はホップバイホップ拡張ヘッダー内のインスタンス ID でパケットにタグを付けます。6TiSCH は、分散ルーティング操作に RPL を活用しています。
To reduce the routing exchanges, RPL leverages an anisotropic Distance Vector approach, which does not need global knowledge of the topology and only optimizes the routes to and from the RPL Root, allowing P2P paths to be stretched. Although RPL installs its routes proactively, it only maintains them lazily, in reaction to actual traffic or as a slow background activity.
ルーティング交換を削減するために、RPL は異方性ディスタンス ベクトル アプローチを活用します。このアプローチでは、トポロジに関するグローバルな知識は必要なく、RPL ルートとの間のルートを最適化するだけで、P2P パスを拡張できます。RPL はルートをプロアクティブにインストールしますが、実際のトラフィックに反応して、または遅いバックグラウンド アクティビティとして、ルートを遅延的に維持するだけです。
This is simple and efficient in situations where the traffic is mostly directed from or to a central node, such as the control traffic between routers and a controller of a Software-Defined Networking (SDN) infrastructure or an Autonomic Control Plane (ACP).
これは、ルーターと Software-Defined Networking (SDN) インフラストラクチャまたは Autonomic Control Plane (ACP) のコントローラー間の制御トラフィックなど、トラフィックが主に中央ノードから送受信される状況ではシンプルで効率的です。
But stretch in P2P routing is counter-productive to both reliability and latency as it introduces additional delay and chances of loss. As a result, [RPL] is not a good fit for the use cases listed in the RAW use cases document [RFC9450], which demand high availability and reliability and, as a consequence, require both short and diverse paths.
しかし、P2P ルーティングのストレッチは追加の遅延と損失の可能性をもたらすため、信頼性と遅延の両方に逆効果です。結果として、[RPL] は、高可用性と信頼性を要求し、その結果、短くて多様なパスの両方を必要とする RAW ユースケース文書 [RFC9450] にリストされているユースケースには適していません。
RPL first forms a default route in each node towards the Root, and those routes together coalesce as a DAG oriented upwards. RPL then constructs routes to destinations signaled as Targets in the reverse direction, down the same DODAG. To do so, a RPL Instance can be operated in either RPL Storing or Non-Storing MOP. The default route towards the Root is maintained aggressively and may change while a packet progresses without causing loops, so the packet will still reach the Root.
RPL はまず、各ノードでルートに向かうデフォルト ルートを形成し、それらのルートが上向きの DAG として結合されます。次に、RPL は、同じ DODAG を下る、逆方向のターゲットとして通知された宛先へのルートを構築します。これを行うには、RPL インスタンスを RPL ストレージまたは非ストレージ MOP のいずれかで操作できます。ルートへのデフォルト ルートは積極的に維持され、ループを引き起こすことなくパケットが進行する間に変更される可能性があるため、パケットは依然としてルートに到達します。
In Non-Storing Mode, each node advertises itself as a Target directly to the Root, indicating the parents that may be used to reach itself. Recursively, the Root builds and maintains an image of the whole DODAG in memory and leverages that abstraction to compute source route paths for the packets to their destinations down the DODAG. When a node changes its point(s) of attachment to the DODAG, it takes a single unicast packet to the Root along the default route to update it, and the connectivity to the node is restored immediately; this mode is preferable for use cases where internet connectivity is dominant or when the Root controls the network activity in the nodes, which is the case in this specification.
非保存モードでは、各ノードは自身をターゲットとしてルートに直接アドバタイズし、自身に到達するために使用できる親を示します。ルートは再帰的に DODAG 全体のイメージをメモリ内に構築して維持し、その抽象化を活用して DODAG を下る宛先へのパケットのソース ルート パスを計算します。ノードが DODAG への接続ポイントを変更すると、単一のユニキャスト パケットがデフォルト ルートに沿ってルートに送信され、更新され、ノードへの接続が直ちに復元されます。このモードは、インターネット接続が優勢である場合、またはルートがノード内のネットワーク アクティビティを制御する場合 (この仕様ではこれに当てはまります) の使用例に適しています。
In Storing Mode, the routing information percolates upwards, and each node maintains the routes to the subDAG of its descendants down the DODAG. The maintenance is lazy; it is either reactive upon receiving traffic or a slow background process. Packets flow via the common parent and the routing stretch is reduced, compared to the Non-Storing MOP, for better P2P connectivity. However, a new route takes a longer time to propagate to the Root, since it takes time for the Distance Vector protocol to operate hop by hop, and the connectivity from the Internet to the node is restored more slowly upon node movement.
保存モードでは、ルーティング情報は上向きに浸透し、各ノードは DODAG の下の子孫のサブ DAG へのルートを維持します。メンテナンスは怠惰です。トラフィックの受信時に反応するか、バックグラウンド プロセスが遅いかのいずれかです。パケットは共通の親を経由して流れるため、非保存 MOP と比較してルーティングのストレッチが軽減され、P2P 接続が向上します。ただし、ディスタンス ベクター プロトコルがホップごとに動作するのに時間がかかり、ノードの移動時にインターネットからノードへの接続が復元されるのが遅くなるため、新しいルートがルートに伝播するまでに時間がかかります。
Either way, the RPL routes are injected by the Target nodes in a distributed fashion. To complement RPL and eliminate routing stretch, this specification introduces a hybrid mode that combines Storing and Non-Storing operations to build and project routes onto the nodes where they should be installed. This specification uses the term "P-Route" to refer to those routes.
いずれの場合でも、RPL ルートはターゲット ノードによって分散方式で挿入されます。RPL を補完し、ルーティングのストレッチを排除するために、この仕様では、保存操作と非保存操作を組み合わせてルートを構築し、ルートをインストールする必要があるノードに投影するハイブリッド モードが導入されています。この仕様では、これらのルートを指すために「P ルート」という用語を使用します。
In the simplest mode of this specification, Storing Mode P-Routes can be deployed to complete the path between the hops described in the loose SRH in the main DODAG. In that case, all the routes (source routed and P-Routes) belong to the Routing Information Base (RIB) associated with the main Instance. Storing Mode P-Routes are referred to as segments in this specification.
この仕様の最も単純なモードでは、ストレージ モード P ルートを展開して、メイン DODAG のルーズ SRH に記述されているホップ間のパスを完成させることができます。その場合、すべてのルート (ソース ルーティングおよび P ルート) は、メイン インスタンスに関連付けられたルーティング情報ベース (RIB) に属します。保存モード P ルートは、この仕様ではセグメントと呼ばれます。
A set of P-Routes can also be projected to form a dotted-line underlay of the main Instance and provide Traffic-Engineered paths for an application. In that case, the P-Routes are installed in Non-Storing Mode, and the set of P-Routes is called a Track. A Track is associated with its own RPL Instance and, as any RPL Instance, with its own RIB. As a result, each Track defines a routing topology in the RPL domain. As for the main DODAG, segments associated to the Track Instance may be deployed to establish the complete path between loose source routing hops using segments expressed as Storing Mode P-Routes.
一連の P ルートを投影して、メイン インスタンスの点線のアンダーレイを形成し、アプリケーションにトラフィック エンジニアリングされたパスを提供することもできます。この場合、P ルートは非保存モードでインストールされ、P ルートのセットはトラックと呼ばれます。トラックは独自の RPL インスタンスに関連付けられ、他の RPL インスタンスと同様に独自の RIB にも関連付けられます。その結果、各トラックは RPL ドメイン内のルーティング トポロジを定義します。メイン DODAG に関しては、トラック インスタンスに関連付けられたセグメントを展開して、ストレージ モード P ルートとして表現されるセグメントを使用して、ルーズ ソース ルーティング ホップ間の完全なパスを確立できます。
Routing in a multi-topology domain may cause loops unless strict rules are applied. This specification defines two strict orders to ensure loop avoidance when P-Routes are used in a RPL domain: one between forwarding methods and one between RPL Instances, which are routing topologies.
厳密なルールが適用されない限り、マルチトポロジ ドメインでのルーティングではループが発生する可能性があります。この仕様では、P-Route が RPL ドメインで使用される場合にループ回避を確実にするための 2 つの厳密な順序を定義します。1 つは転送メソッド間で、もう 1 つはルーティング トポロジである RPL インスタンス間です。
The first order is strict and complete and relates to the forwarding method and, more specifically, the origin of the information used in the next-hop computation. The possible forwarding methods are: 1) to a direct next hop, 2) to an indirect neighbor via a common neighbor, 3) along a segment, and 4) along a nested Track. The methods are strictly ordered as listed above; see more in Section 6.7. A forwarding method may leverage any of the lower-order ones, but never one with a higher order; for instance, when forwarding a packet along a segment, the router may use direct or indirect neighbors but cannot use a Track. The lower-order methods have a strict precedence, so the router will always prefer a direct neighbor over an indirect one or a segment within the current RPL Instance over another Track.
最初の順序は厳密かつ完全であり、転送方法、より具体的にはネクストホップの計算で使用される情報の発信元に関連します。可能な転送方法は次のとおりです。1) 直接の次のホップへ、2) 共通の隣接ノードを介して間接的な隣接ノードへ、3) セグメントに沿って、4) ネストされたトラックに沿って。メソッドは上記のように厳密に順序付けされています。詳細についてはセクション 6.7 を参照してください。転送方法は低次のものを利用できますが、上位のものは決して利用できません。たとえば、セグメントに沿ってパケットを転送する場合、ルーターは直接または間接的なネイバーを使用できますが、トラックは使用できません。下位メソッドには厳密な優先順位があるため、ルーターは常に間接的なメソッドよりも直接的なネイバーを優先するか、別のトラックよりも現在の RPL インスタンス内のセグメントを優先します。
The second order is strict and partial and applies between RPL Instances. It allows the RPL node to detect an error in the state installed by the PCE, e.g., after a desynchronization. That order must be defined by the administrator for the RPL domain and defines a DODAG of underlay RPL Instances with the main Instance as the Root. The relation of RPL Instances may be represented as a DODAG of Instances where the main Instance is the Root. The rule is that a RPL Instance may leverage another RPL Instance as an underlay if and only if that other Instance is one of its descendants in the graph. Supporting this method is OPTIONAL for nested Tracks and REQUIRED between a Track Instance and the main Instance. It may be done using network management or future extensions to this specifications. When the DODAG of underlay Instances is not provided, the RPL nodes consider by default that all Track Instances are children of the main Instance, and they do not attempt to validate the order for nested Tracks, trusting the PCE implicitly. As a result, a packet that is being forwarded along the main Instance may be encapsulated in any Track, but a packet that was forwarded along a Track MUST NOT be forwarded along the default route of the main Instance.
2 番目の順序は厳密かつ部分的なもので、RPL インスタンス間で適用されます。これにより、RPL ノードは、PCE によってインストールされた状態 (非同期後など) のエラーを検出できるようになります。この順序は、RPL ドメインの管理者が定義する必要があり、メイン インスタンスをルートとしてアンダーレイ RPL インスタンスの DODAG を定義します。RPL インスタンスの関係は、メイン インスタンスがルートであるインスタンスの DODAG として表すことができます。ルールとしては、RPL インスタンスは、他のインスタンスがグラフ内のその子孫の 1 つである場合に限り、別の RPL インスタンスをアンダーレイとして利用できるということです。このメソッドのサポートは、ネストされたトラックではオプションですが、トラック インスタンスとメイン インスタンスの間では必須です。これは、ネットワーク管理またはこの仕様の将来の拡張機能を使用して実行される可能性があります。アンダーレイ インスタンスの DODAG が提供されていない場合、RPL ノードはデフォルトですべてのトラック インスタンスがメイン インスタンスの子であると見なし、ネストされたトラックの順序を検証しようとせず、暗黙的に PCE を信頼します。その結果、メイン インスタンスに沿って転送されるパケットは任意のトラックにカプセル化できますが、トラックに沿って転送されたパケットはメイン インスタンスのデフォルト ルートに沿って転送してはなりません (MUST NOT)。
A RPL implementation operating in a very constrained LLN typically uses the Non-Storing MOP as represented in Figure 2. In that mode, a RPL node indicates a parent-child relationship to the Root, using a Destination Advertisement Object (DAO) that is unicast from the node directly to the Root, and the Root typically builds a source-routed path to a destination down the DODAG by recursively concatenating this information.
非常に制約された LLN で動作する RPL 実装は通常、図 2 に示すように非ストレージ MOP を使用します。このモードでは、RPL ノードは、ノードからルートに直接ユニキャストされる宛先アドバタイズメント オブジェクト (DAO) を使用して、ルートへの親子関係を示します。ルートは通常、この情報を再帰的に連結することによって、DODAG の下に宛先へのソース ルーティング パスを構築します。
+-----+
| | Border Router
| | (RPL Root)
+-----+ ^ | |
| | DAO | ACK |
o o o o | | | Strict
o o o o o o o o o | | | Source
o o o o o o o o o o | | | Route
o o o o o o o o o | | |
o o o o o o o o | v v
o o o o
LLN
Figure 2: RPL Non-Storing Mode of Operation
図 2: RPL 非保存動作モード
Based on the parent-children relationships expressed in the Non-Storing DAO messages, the Root possesses topological information about the whole network, though this information is limited to the structure of the DODAG for which it is the destination. A packet that is generated within the domain will always reach the Root, which can then apply source routing information to reach the destination if the destination is also in the DODAG. Similarly, a packet coming from the outside of the domain for a destination that is expected to be in a RPL domain reaches the Root. This results in the wireless bandwidth near the Root being the limiting factor for all transmissions towards or within the domain, and the Root is a single point of failure for all connectivity to nodes within its domain.
Non-Storing DAO メッセージで表現される親子関係に基づいて、ルートはネットワーク全体に関するトポロジ情報を保持しますが、この情報は宛先である DODAG の構造に限定されます。ドメイン内で生成されたパケットは常にルートに到達し、宛先も DODAG 内にある場合は、ソース ルーティング情報を適用して宛先に到達できます。同様に、RPL ドメイン内にあると予想される宛先へのドメイン外部からのパケットは、ルートに到達します。その結果、ルート付近のワイヤレス帯域幅がドメインへの、またはドメイン内のすべての送信の制限要因となり、ルートはドメイン内のノードへのすべての接続に対する単一障害点になります。
The RPL Root must add a Source Routing Header to all downward packets. As a network grows, the size of the Source Routing Header increases with the depth of the network. In some use cases, a RPL network forms long lines along physical structures like streets with lighting. Limiting the packet size is beneficial to the energy budget, directly for the current transmission and also indirectly since it reduces the chances of frame loss and energy spent in retries, e.g., by ARQ over one hop at Layer 2 or end to end at upper layers. Using smaller packets also reduces the chances of packet fragmentation, which is highly detrimental to the LLN operation, in particular when fragments are forwarded but not recovered; see [RFC8930] compared to [RFC8931] for more details.
RPL ルートは、すべての下向きパケットにソース ルーティング ヘッダーを追加する必要があります。ネットワークが成長するにつれて、ソース ルーティング ヘッダーのサイズもネットワークの深さに応じて増加します。一部のユースケースでは、RPL ネットワークは、照明のある道路などの物理的構造物に沿って長い列を形成します。パケット サイズを制限することは、現在の送信に対して直接的に、また間接的にもエネルギー バジェットにとって有益です。これは、フレーム損失の可能性や、レイヤ 2 での 1 ホップ上の ARQ や上位層でのエンドツーエンドなどの再試行で費やされるエネルギーが減少するためです。より小さいパケットを使用すると、パケットの断片化の可能性も減ります。これは、特に断片が転送されても回復されない場合に、LLN の動作に非常に悪影響を及ぼします。詳細については、[RFC8930] と [RFC8931] の比較を参照してください。
A limited amount of well-targeted routing state would allow the source routing operation to be loose as opposed to strict and would reduce the overhead of routing information in packets. Because the capability to store routing state in every node is limited, the decision of which route is installed where can only be optimized with global knowledge of the system, knowledge that the Root or an associated PCE may possess by means that are outside the scope of this specification.
限定された量の適切にターゲットを絞ったルーティング ステートにより、ソース ルーティング操作が厳密ではなく緩やかになり、パケット内のルーティング情報のオーバーヘッドが削減されます。すべてのノードにルーティング状態を保存する機能は限られているため、どのルートをどこにインストールするかの決定は、システムのグローバルな知識、つまりルートまたは関連する PCE がこの仕様の範囲外の手段で所有している可能性がある知識によってのみ最適化できます。
Being on path for all packets in Non-Storing Mode, the Root may determine the number of P2P packets in its RPL domain per source and destination, the latency incurred, and the amount of energy and bandwidth that is consumed to reach itself and then back down, including possible fragmentation when encapsulating larger packets. Enabling a shorter path that would not traverse the Root for select P2P sources/destinations may improve the latency, lower the consumption of constrained resources, free bandwidth at the bottleneck near the Root, improve the delivery ratio, and reduce the latency for those P2P flows; this would be a global benefit for all flows by reducing the load at the Root.
非保存モードのすべてのパケットのパス上にあるルートは、送信元および宛先ごとの RPL ドメイン内の P2P パケットの数、発生する遅延、および大きなパケットをカプセル化するときに発生する可能性のある断片化を含む、自身に到達してから元に戻るまでに消費されるエネルギーと帯域幅の量を決定できます。選択した P2P ソース/宛先に対してルートを通過しない短いパスを有効にすると、遅延が改善され、制約されたリソースの消費が減少し、ルート付近のボトルネックで帯域幅が解放され、配信率が向上し、それらの P2P フローの遅延が削減される可能性があります。これは、ルートでの負荷が軽減されるため、すべてのフローにとって全体的な利点になります。
To limit the need for RPL Source Route Headers in deep networks, one possibility is to store a routing state associated with the main DODAG in select RPL routers down the path. The Root may elide the sequence of routers that is installed in the network from its RPL Source Route Header, which therefore becomes loose, in contrast to being strict in [RPL].
深いネットワークでの RPL ソース ルート ヘッダーの必要性を制限するための 1 つの可能性は、メイン DODAG に関連付けられたルーティング状態を、パス上の選択された RPL ルーターに保存することです。ルートは、ネットワークにインストールされているルーターのシーケンスを RPL ソース ルート ヘッダーから省略する可能性があるため、[RPL] では厳密であるのとは対照的に、ルーズになります。
[RPL] optimizes P2MP routes from the Root, MP2P routes towards the Root, and routes from/to the outside of the RPL domain when the Root also serves as the border router. All routes are installed North-South (a.k.a. up/down) along the RPL DODAG. Peer-to-Peer forward routes in a RPL network will generally experience elongated (stretched) paths rather than direct (optimized) paths, since routing between two nodes always happens via a common parent, as illustrated in Figure 3:
[RPL] は、ルートからの P2MP ルート、ルートに向かう MP2P ルート、およびルートが境界ルータとしても機能する場合の RPL ドメイン外部との間のルートを最適化します。すべてのルートは RPL DODAG に沿って南北 (別名上り/下り) に設置されます。図 3 に示すように、2 つのノード間のルーティングは常に共通の親を介して行われるため、RPL ネットワークのピアツーピア転送ルートでは、一般に直接 (最適化された) パスではなく、延長された (拡張された) パスが発生します。
------+---------
| Internet
+-----+
| | Border Router
| | (RPL Root)
+-----+
X
^ v o o
^ o o v o o o o o
^ o o o v o o o o o
^ o o v o o o o o
S o o o D o o o
o o o o
LLN
Figure 3: Routing Stretch Between S and D via Common Parent X Along North-South Paths
図 3: 南北パスに沿った共通の親 X を介した S と D 間の配線ストレッチ
As described in [RFC9008], the amount of stretch depends on the MOP:
[RFC9008] で説明されているように、ストレッチの量は MOP によって異なります。
* In Non-Storing Mode, all packets routed within the DODAG flow all the way up to the Root of the DODAG. If the destination is in the same DODAG, the Root must encapsulate the packet to place an RH that has the strict source route information down the DODAG to the destination. This will be the case even if the destination is relatively close to the source and the Root is relatively far off.
* 非保存モードでは、DODAG 内でルーティングされたすべてのパケットは、DODAG のルートまで流れます。宛先が同じ DODAG 内にある場合、ルートはパケットをカプセル化して、厳密なソース ルート情報を持つ RH を DODAG を介して宛先に配置する必要があります。これは、宛先がソースに比較的近く、ルートが比較的遠い場合にも当てはまります。
* In Storing Mode, unless the destination is a child of the source, the packets will follow the default route up the DODAG as well. If the destination is in the same DODAG, they will eventually reach a common parent that has a route to the destination; at worst, the common parent may also be the Root. From that common parent, the packet will follow a path down the DODAG that is optimized for the Objective Function that was used to build the DODAG.
* 保存モードでは、宛先が送信元の子でない限り、パケットは DODAG までのデフォルト ルートをたどります。宛先が同じ DODAG 内にある場合、最終的には宛先へのルートを持つ共通の親に到達します。最悪の場合、共通の親がルートになる可能性もあります。パケットは、その共通の親から、DODAG の構築に使用された目的関数に最適化されたパスをたどって DODAG を下ります。
It turns out that it is often beneficial to enable direct P2P routes if either the RPL route presents a stretch from the shortest path or the new route is engineered with a different objective, and this is even more critical in Non-Storing Mode than it is in Storing Mode because the routing stretch is wider. For that reason, earlier work within the IETF was introduced: the "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks" [RFC6997], which specifies a distributed method for establishing optimized P2P routes. This specification proposes an alternative based on centralized route computation.
RPL ルートが最短パスから離れている場合、または新しいルートが別の目的で設計されている場合、ダイレクト P2P ルートを有効にすることが有益であることが多いことがわかりました。これは、ルーティング範囲が広いため、非ストレージ モードではストレージ モードよりもさらに重要です。そのため、IETF 内の初期の作業である「低電力および損失の多いネットワークにおけるポイントツーポイント ルートのリアクティブ検出」[RFC6997] が導入されました。これは、最適化された P2P ルートを確立するための分散方式を規定しています。この仕様では、集中型ルート計算に基づく代替案を提案します。
+-----+
| | Border Router
| | (RPL Root)
+-----+
|
o o o o
o o o o o o o o o
o o o o o o o o o o
o o o o o o o o o
S>>A>>>B>>C>>>D o o o
o o o o
LLN
Figure 4: More Direct Forward Route Between S and D
図 4: S と D 間のより直接的な前方ルート
The requirement is to install additional routes in the RPL routers, to reduce the stretch of some P2P routes and maintain the characteristics within a given Service Level Objective (SLO), e.g., in terms of latency and/or reliability.
要件は、RPL ルーターに追加のルートをインストールして、一部の P2P ルートのストレッチを軽減し、遅延や信頼性などの観点から、特定のサービス レベル目標 (SLO) 内の特性を維持することです。
The concept of a Track was introduced in the 6TiSCH architecture [RFC9030] as a collection of potential protection paths that leverage redundant forwarding solutions along the way. This can be a DODAG or a more complex structure that is only partially acyclic (e.g., per packet).
トラックの概念は、途中で冗長転送ソリューションを活用する潜在的な保護パスの集合として 6TiSCH アーキテクチャ [RFC9030] で導入されました。これは、DODAG、または部分的にのみ非周期的な (パケットごとなど) より複雑な構造にすることができます。
With this specification, a Track is shaped as a DODAG, and following the directed edges leads to a Track ingress. Storing Mode P-DAO messages follow the direction of the edges to set up routes for traffic that flows the other way, towards the Track egress(es). If there is a single Track egress, then the Track is reversible so that another DODAG may be formed by reversing the direction of each edge. A node at the ingress of more than one segment in a Track may use one or more of these segments to forward a packet inside the Track.
この仕様では、トラックは DODAG として形成され、有向エッジをたどるとトラックの入口につながります。保存モード P-DAO メッセージは、エッジの方向に従い、トラック出力に向かって逆方向に流れるトラフィックのルートを設定します。単一のトラック出力がある場合、トラックは可逆的であるため、各エッジの方向を反転することによって別の DODAG を形成できます。トラック内の複数のセグメントの入口にあるノードは、これらのセグメントの 1 つまたは複数を使用して、トラック内でパケットを転送できます。
A RPL Track is a collection of (one or more) parallel loose source-routed sequences of nodes ordered from ingress to egress, each forming a protection path. The nodes in a Track are directly connected, reachable via existing Tracks as illustrated in Section 3.5.2.3 or joined with strict segments of other nodes as shown in Section 3.5.1.3. The protection paths are expressed in RPL Non-Storing Mode and require an encapsulation to add a RPL Source Route Header, whereas the segments are expressed in RPL Storing Mode.
RPL トラックは、入力から出力に順序付けされた、(1 つ以上の) 並列の緩やかなソース ルーティングされたノードのシーケンスの集合であり、それぞれが保護パスを形成します。トラック内のノードは直接接続されており、セクション 3.5.2.3 に示すように既存のトラックを介して到達可能であるか、セクション 3.5.1.3 に示すように他のノードの厳密なセグメントに結合されています。保護パスは RPL 非保存モードで表現され、RPL ソース ルート ヘッダーを追加するためのカプセル化が必要ですが、セグメントは RPL 保存モードで表現されます。
A path provides only one path between the ingress and egress. It comprises exactly one protection path. A stand-alone segment implicitly defines a path from its ingress to egress.
パスは、入力と出力の間に 1 つのパスのみを提供します。まさに 1 つの保護パスで構成されます。スタンドアロン セグメントは、入口から出口までのパスを暗黙的に定義します。
A Complex Track forms a graph that provides a collection of potential paths to provide redundancy for the packets, either as a collection of protection paths that may be parallel or interleaved at certain points or as a more generic DODAG.
Complex Track は、特定のポイントで並列またはインターリーブできる保護パスの集合として、またはより汎用的な DODAG として、パケットに冗長性を提供する潜在的なパスの集合を提供するグラフを形成します。
Section 5.1 of [RPL] describes the RPL Instance and its encoding. There can be up to 128 Global RPL Instances, for which there can be one or more DODAGs, and there can be 64 Local RPL Instances, with a namespace that is indexed by a DODAGID, where the DODAGID is a Unique Local Address (ULA) or a Global Unicast Address (GUA) of the Root of the DODAG. Bit 0 (most significant) is set to 1 to signal a Local RPLInstanceID, as shown in Figure 5. By extension, this specification expresses the value of the RPLInstanceID as a single integer between 128 and 191, representing both the Local RPLInstanceID in 0..63 in the rightmost bits and bit 0 set.
[RPL] のセクション 5.1 では、RPL インスタンスとそのエンコーディングについて説明しています。グローバル RPL インスタンスは最大 128 個存在でき、そのグローバル RPL インスタンスには 1 つ以上の DODAG が存在でき、ローカル RPL インスタンスは DODAGID によってインデックス付けされた名前空間を持つ 64 個存在できます。DODAGID は、DODAG のルートの一意のローカル アドレス (ULA) またはグローバル ユニキャスト アドレス (GUA) です。図 5 に示すように、ビット 0 (最上位) は 1 に設定され、ローカル RPLInstanceID を通知します。拡張すると、この仕様は、RPLInstanceID の値を 128 ～ 191 の単一の整数として表現し、右端のビットの 0..63 のローカル RPLInstanceID とビット 0 セットの両方を表します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+
| |
\ \
\ Bit 1 is set to 0 in TrackIDs
Bit 0 set to 1 signals a Local RPLInstanceID
Figure 5: Local RPLInstanceID Encoding
図 5: ローカル RPLInstanceID エンコーディング
A Track typically forms an underlay to the main Instance and is associated with a Local RPL Instance from which the RPLInstanceID is used as the TrackID. When a packet is placed on a Track, it is IP-in-IP encapsulated with a RPL Option containing RPL Packet Information (RPI) that signals the RPLInstanceID. The encapsulating source IP address and RPI Instance are set to the Track ingress IP address and Local RPLInstanceID, respectively; see more in Section 6.3.
通常、トラックはメイン インスタンスのアンダーレイを形成し、RPLInstanceID が TrackID として使用されるローカル RPL インスタンスに関連付けられます。パケットがトラックに配置されると、RPLInstanceID を通知する RPL パケット情報 (RPI) を含む RPL オプションで IP-in-IP カプセル化されます。カプセル化ソース IP アドレスと RPI インスタンスは、それぞれ Track イングレス IP アドレスとローカル RPLInstanceID に設定されます。詳細についてはセクション 6.3 を参照してください。
A Track typically offers service protection across several protection paths. As a degraded form of a Track, a path made of a single protection path (i.e., offering no protection) can be used as an alternative to a segment for forwarding along a RPL Instance. In that case, instead of following native routes along the Instance, the packets are encapsulated to signal a more-specific source-routed path between the loose hops in the encapsulated Source Routing Header.
通常、トラックは複数の保護パスにわたってサービス保護を提供します。トラックの劣化形式として、単一の保護パスで構成されるパス (つまり、保護を提供しない) を、RPL インスタンスに沿った転送用のセグメントの代替として使用できます。その場合、インスタンスに沿ったネイティブ ルートをたどる代わりに、パケットはカプセル化され、カプセル化されたソース ルーティング ヘッダー内のルーズ ホップ間のより具体的なソース ルーティング パスを通知します。
If the encapsulated packet follows a Global Instance, then the protection path may be part of that Global Instance as well, e.g., the Global Instance of the main DODAG. This can only be done for Global Instances because the ingress node that encapsulates the packets over the protection path is not the Root of the Instance, so the source address of the encapsulated packet cannot be used to determine the Track along the way.
カプセル化されたパケットがグローバル インスタンスに従う場合、保護パスもそのグローバル インスタンス、たとえばメイン DODAG のグローバル インスタンスの一部である可能性があります。これは、グローバル インスタンスに対してのみ実行できます。これは、保護パス上のパケットをカプセル化する入力ノードがインスタンスのルートではないため、カプセル化されたパケットの送信元アドレスを途中のトラックの決定に使用できないためです。
This specification enables setting up a P-Route along either a protection path or a segment. A P-Route is installed and maintained by the Root of the main DODAG using an extended RPL DAO message called a P-DAO, and a Track is composed of the combination of one or more P-Routes. In order to clarify the techniques that may be used to install a P-Route, this section uses the simple case of the path illustrated in Figure 6. Thus, the goal is to build a path from node A to E for packets towards E's neighbors F and G along A, B, C, D, and E as opposed to via the Root:
この仕様により、保護パスまたはセグメントに沿って P ルートを設定できるようになります。P-Route は、P-DAO と呼ばれる拡張 RPL DAO メッセージを使用してメイン DODAG のルートによってインストールおよび維持され、トラックは 1 つまたは複数の P-Route の組み合わせで構成されます。P ルートのインストールに使用できる手法を明確にするために、このセクションでは、図 6 に示す単純なパスのケースを使用します。 したがって、目標は、ルート経由ではなく、A、B、C、D、および E に沿って、E の隣接ノード F および G に向かうパケット用のノード A から E へのパスを構築することです。
/===> F
A ===> B ===> C ===> D===> E <
\===> G
Figure 6: Reference Track
図 6: リファレンス トラック
A P-DAO message for a Track signals the TrackID in the RPLInstanceID field. In the case of a Local RPL Instance, the address of the Track ingress is used as the source to encapsulate packets along the Track. The Track is signaled in the DODAGID field of the P-DAO Base Object; see Figure 8.
トラックの P-DAO メッセージは、RPLInstanceID フィールドの TrackID を通知します。ローカル RPL インスタンスの場合、トラック入口のアドレスは、トラックに沿ってパケットをカプセル化するためのソースとして使用されます。トラックは、P-DAO ベース オブジェクトの DODAGID フィールドで通知されます。図 8 を参照してください。
This specification introduces the Via Information Option (VIO) to signal a sequence of hops in a protection path or a segment in the P-DAO messages, either in Storing Mode (SM-VIO) or in Non-Storing Mode (NSM-VIO). One P-DAO message contains a single VIO, which is associated to one or more RPL Target Options that signal the destination IPv6 addresses that can reached along the Track (see more in Section 5.3).
この仕様では、保存モード (SM-VIO) または非保存モード (NSM-VIO) のいずれかで、P-DAO メッセージ内の保護パスまたはセグメント内のホップのシーケンスを通知するための Via Information Option (VIO) が導入されています。1 つの P-DAO メッセージには 1 つの VIO が含まれており、これはトラックに沿って到達できる宛先 IPv6 アドレスを通知する 1 つ以上の RPL ターゲット オプションに関連付けられています (詳細はセクション 5.3 を参照)。
Before diving deeper into Track and segment signaling and operation, this section provides examples of how route projection works through variations of a simple example. This simple example illustrates the case of host routes, though RPL Targets can also be prefixes.
追跡およびセグメントのシグナリングと操作について詳しく説明する前に、このセクションでは、簡単な例のバリエーションを通じて、ルート投影がどのように機能するかを例で説明します。この簡単な例はホスト ルートの場合を示していますが、RPL ターゲットをプレフィックスにすることもできます。
Conventionally, we use ==> to represent a strict hop and --> for a loose hop. We use "-to-", such as in C==>D==>E-to-F, to represent comma-separated Targets, e.g., F is a Target for segment C==>D==>E. In the example below, A is the Track ingress and E is the Track egress. C is a stitching point. F and G are "external" Targets for the Track and become reachable from A via Track A (ingress) to E (egress and implicit Target in Non-Storing Mode), leading to F and G (explicit Targets).
従来、厳密なホップを表すには ==> を使用し、緩やかなホップには --> を使用します。C==>D==>E-to-F のように「-to-」を使用して、カンマ区切りのターゲットを表します。たとえば、F はセグメント C==>D==>E のターゲットです。以下の例では、A はトラック入力、E はトラック出力です。Cはステッチポイントです。F と G はトラックの「外部」ターゲットであり、トラック A (入力) を介して A から E (出力および非保存モードの暗黙的ターゲット) に到達可能になり、F と G (明示的ターゲット) につながります。
In a general manner, the desired outcome is as follows:
一般的に、望ましい結果は次のとおりです。
* Targets are E, F, and G
* ターゲットはE、F、Gです
* P-DAO 1 signals C==>D==>E
* P-DAO 1 信号 C==>D==>E
* P-DAO 2 signals A==>B==>C
* P-DAO 2 信号 A==>B==>C
* P-DAO 3 signals F and G via the A-->E Track
* P-DAO 3 は、A-->E トラック経由で F と G に信号を送ります
P-DAO 3 may be omitted if P-DAOs 1 and 2 signal F and G as Targets.
P-DAO 1 および 2 が F および G をターゲットとして信号を送る場合、P-DAO 3 は省略できます。
Loose sequences of hops are expressed in Non-Storing Mode; this is why P-DAO 3 contains an NSM-VIO. With this specification:
ホップの緩やかなシーケンスは非保存モードで表現されます。これが、P-DAO 3 に NSM-VIO が含まれている理由です。この仕様では:
* The DODAGID to be used by the ingress as the source address is signaled in the DAO Base Object (see Figure 8).
* 入力側で送信元アドレスとして使用される DODAGID は、DAO ベース オブジェクトで通知されます (図 8 を参照)。
* The via list in the VIO is encoded as an SRH-6LoRH (see Figure 16), and it starts with the address of the first-hop node after the ingress node in the loose hop sequence.
* VIO のビア リストは SRH-6LoRH としてエンコードされ (図 16 を参照)、ルーズ ホップ シーケンスの入力ノードの後の最初のホップ ノードのアドレスで始まります。
* The via list ends with the address of the egress node.
* 経由リストは出力ノードのアドレスで終わります。
Note 1: The egress of a Non-Storing Mode P-Route is implicitly a target; it is not listed in the RPL Target Options but is still accounted for as if it was. The only exception is when the egress is the only address listed in the VIO, in which case it would indicate via itself, which would be nonsensical.
注 1: 非保存モード P ルートの出力は暗黙的にターゲットになります。RPL ターゲット オプションにはリストされていませんが、依然としてリストされているかのように考慮されています。唯一の例外は、出力が VIO にリストされている唯一のアドレスである場合です。この場合、それ自体が経由であることを示すことになりますが、これは無意味です。
Note 2: By design, the list of nodes in a VIO in Non-Storing Mode is exactly the list that shows in the encapsulation SRH. So in the cases detailed below, if the Mode of the P-DAO is Non-Storing, then the VIO row can be read as indicating the SRH as well.
注 2: 設計上、非保存モードの VIO 内のノードのリストは、カプセル化 SRH に表示されるリストとまったく同じです。したがって、以下で詳しく説明するケースでは、P-DAO のモードが非保存の場合、VIO 行も SRH を示すものとして読み取ることができます。
A==>B==>C and C==>D==>E are segments of the same Track. Note that the Storing Mode signaling imposes strict continuity in a segment, since the P-DAO is passed hop by hop, as a classical DAO is, along the reverse datapath that it signals. One benefit of strict routing is that loops are avoided along the Track.
A==>B==>C と C==>D==>E は、同じトラックのセグメントです。従来の DAO と同様に、P-DAO は信号を送信する逆方向データパスに沿ってホップごとに渡されるため、Storing Mode シグナリングはセグメントに厳密な連続性を課すことに注意してください。厳密なルーティングの利点の 1 つは、トラックに沿ったループが回避されることです。
In this formulation:
この定式化では次のようになります。
* P-DAO 1 signals C==>D==>E-to-F,G
* P-DAO 1 信号 C==>D==>E-to-F,G
* P-DAO 2 signals A==>B==>C-to-F,G
* P-DAO 2 信号 A==>B==>C-to-F,G
Storing Mode P-DAO 1 is sent to E, and when it is successfully acknowledged, Storing Mode P-DAO 2 is sent to C as follows:
以下のように、Storing Mode P-DAO 1 が E に送信され、正常に確認されると、Storing Mode P-DAO 2 が C に送信されます。
+====================+==============+==============+
| Field | P-DAO 1 to E | P-DAO 2 to C |
+====================+==============+==============+
| Mode | Storing | Storing |
+====================+--------------+--------------+
| Track ingress | A | A |
+====================+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) |
+====================+--------------+--------------+
| SegmentID | 1 | 2 |
+====================+--------------+--------------+
| VIO | C, D, E | A, B, C |
+====================+--------------+--------------+
| Targets | F, G | F, G |
+====================+--------------+--------------+
Table 1: P-DAO Messages
表 1: P-DAO メッセージ
As a result, the RIBs are set as follows:
その結果、RIB は次のように設定されます。
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 1 | E | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 2: RIB Settings
表 2: RIB 設定
Note: The " sign is used throughout the tables in this document to indicate the same value as in the row above.
注: このドキュメントの表全体で「」記号は、上の行と同じ値を示すために使用されています。
Packets originating at A and going to F or G do not require encapsulation as the RPI can be placed in the native header chain. For packets that it routes, A must encapsulate to add the RPI that signals the TrackID; the outer headers of the packets that are forwarded along the Track have the following settings:
A で発信され、F または G に向かうパケットは、RPI をネイティブ ヘッダー チェーンに配置できるため、カプセル化は必要ありません。A はルーティングするパケットについて、TrackID を通知する RPI を追加するためにカプセル化する必要があります。トラックに沿って転送されるパケットの外側のヘッダーには次の設定があります。
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | F or G | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | Any but A | F or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 3: Packet Header Settings
表 3: パケットヘッダーの設定
As an example, say that A has a packet for F. Using the RIB in Table 2:
例として、A が F 宛てのパケットを持っているとします。表 2 の RIB を使用すると、次のようになります。
* From P-DAO 2: A forwards to B, and B forwards to C.
* P-DAO 2 から: A は B に転送し、B は C に転送します。
* From P-DAO 1: C forwards to D, and D forwards to E.
* P-DAO 1 から: C は D に転送され、D は E に転送されます。
* From Neighbor Cache Entry: E delivers the packet to F.
* 近隣キャッシュ エントリから: E はパケットを F に配信します。
In this example, we consider F and G as destinations that are external to the Track as a DODAG, as discussed in Section 4.1.1 of [RFC9008]. We then apply the directives for encapsulating in that case (see more in Section 6.7).
この例では、[RFC9008] のセクション 4.1.1 で説明されているように、F と G を DODAG としてトラックの外部にある宛先とみなします。次に、その場合にカプセル化するためのディレクティブを適用します (詳細はセクション 6.7 を参照)。
In this formulation, we set up the protection path explicitly, which creates less routing state in intermediate hops at the expense of larger packets to accommodate source routing:
この定式化では、保護パスを明示的に設定します。これにより、ソース ルーティングに対応するためにより大きなパケットが犠牲になりますが、中間ホップでのルーティング ステートが少なくなります。
* P-DAO 1 signals C==>D==>E-to-E
* P-DAO 1 信号 C==>D==>E-to-E
* P-DAO 2 signals A==>B==>C-to-E
* P-DAO 2 信号 A==>B==>C-to-E
* P-DAO 3 signals F and G via the A-->E-to-F,G Track
* P-DAO 3 は、A-->E-to-F,G トラック経由で F と G に信号を送ります
Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to E, C, and A, respectively, as follows:
保存モード P-DAO 1 と 2 および非保存モード P-DAO 3 は、次のようにそれぞれ E、C、A に送信されます。
+====================+==============+==============+==============+
| | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Storing | Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | A | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 2 | 3 |
+====================+--------------+--------------+--------------+
| VIO | C, D, E | A, B, C | E |
+====================+--------------+--------------+--------------+
| Targets | E | E | F, G |
+====================+--------------+--------------+--------------+
Table 4: P-DAO Messages
表 4: P-DAO メッセージ
Note in the above that E is not an implicit Target in Storing Mode, so it must be added in the RPL Target Option (RTO) for P-DAOs 1 and 2. E is not an implicit Target for P-DAO 3 either, since E is the only entry in the VIO.
上記では、E は保存モードの暗黙的なターゲットではないため、P-DAO 1 および 2 の RPL ターゲット オプション (RTO) に追加する必要があることに注意してください。E は VIO 内の唯一のエントリであるため、P-DAO 3 の暗黙的なターゲットでもありません。
As a result, the RIBs are set as follows:
その結果、RIB は次のように設定されます。
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 3 | E | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 5: RIB Settings
表 5: RIB 設定
Packets from A to E do not require an encapsulation. In the tables below, this is why E may show as an IPv6 destination address only if the IPv6 source address X is different from A. Conversely, the encapsulation is always done when the IPv6 destination address is F or G. Other destination addresses do not match this P-Route and are not subject to encapsulation.
A から E へのパケットにはカプセル化は必要ありません。以下の表では、IPv6 送信元アドレス X が A と異なる場合にのみ、IPv6 宛先アドレスとして E が表示されるのはこのためです。逆に、IPv6 宛先アドレスが F または G の場合、カプセル化は常に行われます。他の宛先アドレスはこの P-Route に一致しないため、カプセル化の対象になりません。
The outer headers of the packets that are forwarded along the Track have the following settings:
トラックに沿って転送されるパケットの外側のヘッダーには次の設定があります。
+========+=====================+==========================+=========+
| Header | IPv6 Source | IPv6 Destination Address | TrackID |
| | Address | | in RPI |
+========+=====================+==========================+=========+
| Outer | A | E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | X | Either F or G. If X!=A, | N/A |
| | | E is also permitted. | |
+--------+---------------------+--------------------------+---------+
Table 6: Packet Header Settings
表 6: パケットヘッダーの設定
As an example, say that A has a packet for F. Using the RIB in Table 5:
例として、A が F 宛てのパケットを持っているとします。表 5 の RIB を使用すると、次のようになります。
* From P-DAO 3: A encapsulates the packet and sends it down the Track signaled by P-DAO 3, with the outer header above. Now the packet destination is E.
* P-DAO 3 から: A はパケットをカプセル化し、上の外側ヘッダーを付けて P-DAO 3 によって通知されたトラックに送信します。現在、パケットの宛先は E です。
* From P-DAO 2: A forwards to B, and B forwards to C.
* P-DAO 2 から: A は B に転送し、B は C に転送します。
* From P-DAO 1: C forwards to D, and D forwards to E; E decapsulates the packet.
* P-DAO 1 から: C は D に転送され、D は E に転送されます。E はパケットをカプセル化解除します。
* From Neighbor Cache Entry: E delivers packets to F or G.
* 近隣キャッシュ エントリから: E はパケットを F または G に配信します。
In this formulation, protection paths are leveraged to combine segments and form a graph. The packets are source routed from a segment to the next to adapt the path:
この定式化では、保護パスを利用してセグメントを結合し、グラフを形成します。パケットは、パスを適応させるためにセグメントから次のセグメントにソース ルーティングされます。
* P-DAO 1 signals C==>D==>E-to-E
* P-DAO 1 信号 C==>D==>E-to-E
* P-DAO 2 signals A==>B-to-B,C
* P-DAO 2 信号 A==>B-to-B,C
* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track
* P-DAO 3 は、A-->C-->E-to-(E),F,G トラック経由で F と G に信号を送ります。
Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to E, B, and A, respectively, as follows:
保存モード P-DAO 1 と 2、および非保存モード P-DAO 3 は、次のようにそれぞれ E、B、A に送信されます。
+====================+==============+==============+==============+
| | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Storing | Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | A | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 2 | 3 |
+====================+--------------+--------------+--------------+
| VIO | C, D, E | A, B | C, E |
+====================+--------------+--------------+--------------+
| Targets | E | B, C | F, G |
+====================+--------------+--------------+--------------+
Table 7: P-DAO Messages
表 7: P-DAO メッセージ
Note in the table above that the segment can terminate at the loose hop as used in the example of P-DAO 1 or at the previous hop as done with P-DAO 2. Both methods are possible on any segment joined by a loose protection path. P-DAO 1 generates more signaling since E is the segment egress when D could be, but a benefit is that it validates that the connectivity between D and E still exists.
上の表では、セグメントは、P-DAO 1 の例で使用されているようにルーズ ホップで終了することも、P-DAO 2 で行われているように前のホップで終了することもできることに注意してください。両方の方法は、ルーズ保護パスによって結合されたセグメントで可能です。P-DAO 1 は、D がセグメント出力である可能性がある場合に E がセグメント出力になるため、より多くのシグナリングを生成しますが、利点は、D と E の間の接続がまだ存在していることを検証することです。
As a result, the RIBs are set as follows:
その結果、RIB は次のように設定されます。
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | C | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 3 | C, E | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 8: RIB Settings
表 8: RIB 設定
Packets originated at A to E do not require an encapsulation, but they carry an SRH via C. The outer headers of the packets that are forwarded along the Track have the following settings:
A から E で発信されたパケットはカプセル化を必要としませんが、C 経由で SRH を伝送します。トラックに沿って転送されるパケットの外側ヘッダーには次の設定があります。
+========+=====================+==========================+=========+
| Header | IPv6 Source | IPv6 Destination Address | TrackID |
| | Address | | in RPI |
+========+=====================+==========================+=========+
| Outer | A | C until C then E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | X | Either F or G. If X!=A, | N/A |
| | | E is also permitted. | |
+--------+---------------------+--------------------------+---------+
Table 9: Packet Header Settings
表 9: パケットヘッダーの設定
As an example, say that A has a packet for F. Using the RIB in Table 8:
例として、A が F 宛てのパケットを持っているとします。表 8 の RIB を使用すると、次のようになります。
* From P-DAO 3: A encapsulates the packet the Track signaled by P-DAO 3, with the outer header above. Now the destination in the IPv6 header is C, and an SRH signals that the final destination is E.
* P-DAO 3 から: A は、P-DAO 3 によって通知されたトラックのパケットを、上記の外側ヘッダーでカプセル化します。現在、IPv6 ヘッダーの宛先は C であり、SRH は最終的な宛先が E であることを通知します。
* From P-DAO 2: A forwards to B, and B forwards to C.
* P-DAO 2 から: A は B に転送し、B は C に転送します。
* From P-DAO 3: C processes the SRH and sets the destination in the IPv6 header to E.
* P-DAO 3 から: C は SRH を処理し、IPv6 ヘッダーの宛先を E に設定します。
* From P-DAO 1: C forwards to D, and D forwards to E; E decapsulates the packet.
* P-DAO 1 から: C は D に転送され、D は E に転送されます。E はパケットをカプセル化解除します。
* From the Neighbor Cache Entry: E delivers packets to F or G.
* 近隣キャッシュ エントリから: E はパケットを F または G に配信します。
In this formulation:
この定式化では次のようになります。
* P-DAO 1 signals C==>D==>E-to-(E),F,G
* P-DAO 1 信号 C==>D==>E-to-(E)、F、G
* P-DAO 2 signals A==>B==>C-to-(C),E,F,G
* P-DAO 2 信号 A==>B==>C-to-(C)、E、F、G
A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing Mode P-DAOs.
A==>B==>C および C==>D==>E は、非保存モード P-DAO として表現されるトラックです。
Non-Storing Mode P-DAO 1 and 2 are sent to C and A, respectively, as follows:
非保存モード P-DAO 1 と 2 は、次のようにそれぞれ C と A に送信されます。
+====================+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A |
+====================+==============+==============+
| Mode | Non-Storing | Non-Storing |
+====================+--------------+--------------+
| Track ingress | C | A |
+====================+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 131) |
+====================+--------------+--------------+
| SegmentID | 1 | 1 |
+====================+--------------+--------------+
| VIO | D, E | B, C |
+====================+--------------+--------------+
| Targets | F, G | E, F, G |
+====================+--------------+--------------+
Table 10: P-DAO Messages
表 10: P-DAO メッセージ
As a result, the RIBs are set as follows (using "ND" to indicate that the address is discovered by IPv6 Neighbor Discovery [RFC4861] [RFC8505] or an equivalent method):
その結果、RIB は次のように設定されます (「ND」を使用して、アドレスが IPv6 近隣探索 [RFC4861] [RFC8505] または同等の方法によって検出されたことを示します)。
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | C, E, F, G | P-DAO 2 | B, C | (A, 131) |
+------+-------------+---------+-------------+----------+
Table 11: RIB Settings
表 11: RIB 設定
Packets originated at A to E, F, and G could be generated with the RPI and the SRH and no encapsulation. Alternatively, A may generate a native packet to the target and then encapsulate it with an RPI and an SRH indicating the source-routed path leading to E, as it would for a packet that it routes coming from another node. This is effectively the same case as for packets generated by the Root in a RPL network in Non-Storing Mode; see Section 8.1.3 of [RFC9008]. The latter is often preferred since it leads to a single code path, and when the destination is F or G, it does not need to understand and process the RPI or the SRH. Either way, the packets to E, F, or G carry an SRH via B and C, and when they reach C, C needs to encapsulate them again to add an SRH via D and E. The encapsulating headers of packets that are forwarded along the Track between C and E have the following settings:
A から E、F、G で発信されたパケットは、RPI と SRH を使用してカプセル化なしで生成できます。あるいは、A は、別のノードからルーティングされるパケットの場合と同様に、ターゲットへのネイティブ パケットを生成し、それを RPI と E につながるソース ルーティング パスを示す SRH でカプセル化することもできます。これは、非保存モードの RPL ネットワーク内のルートによって生成されたパケットの場合と事実上同じです。[RFC9008] のセクション 8.1.3 を参照してください。後者は単一のコード パスにつながり、宛先が F または G の場合、RPI または SRH を理解して処理する必要がないため、多くの場合好まれます。いずれの場合も、E、F、または G へのパケットは B および C 経由で SRH を伝送し、C に到着すると、C はそれらを再度カプセル化して D および E 経由で SRH を追加する必要があります。C と E の間のトラックに沿って転送されるパケットのカプセル化ヘッダーには次の設定があります。
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 12: Packet Header Settings Between C and E
表 12: C と E の間のパケット ヘッダー設定
As an example, say that A has a packet for F. Using the RIB in Table 11:
例として、A が F 宛てのパケットを持っているとします。表 11 の RIB を使用すると、次のようになります。
* From P-DAO 2: A encapsulates the packet with a destination of F in the Track signaled by P-DAO 2. The outer header has source A, destination B, an SRH that indicates C as the next loose hop, and an RPI indicating a TrackID of 131 from A's namespace, which is distinct from a TrackID of 131 from C's.
* P-DAO 2 から: A は、P-DAO 2 によって通知されたトラック内の宛先 F を持つパケットをカプセル化します。外側のヘッダーには、送信元 A、宛先 B、次のルーズ ホップとして C を示す SRH、および A の名前空間からの TrackID 131 を示す RPI が含まれます。これは、C からの TrackID 131 とは異なります。
* From the SRH: Packets forwarded by B have source A, destination C, a consumed SRH, and an RPI indicating a TrackID of 131 from A's namespace. C decapsulates.
* SRH から: B によって転送されたパケットには、送信元 A、宛先 C、消費された SRH、および A の名前空間からの TrackID 131 を示す RPI が含まれます。C はカプセル化を解除します。
* From P-DAO 1: C encapsulates the packet with a destination of F in the Track signaled by P-DAO 1. The outer header has source C, destination D, an SRH that indicates E as the next loose hop, and an RPI indicating a TrackID of 131 from C's namespace. E decapsulates.
* P-DAO 1 から: C は、P-DAO 1 によって通知されたトラック内の宛先 F を持つパケットをカプセル化します。外側のヘッダーには、送信元 C、宛先 D、次のルーズ ホップとして E を示す SRH、および C の名前空間からの TrackID 131 を示す RPI が含まれます。E はカプセル化を解除します。
In this formulation:
この定式化では次のようになります。
* P-DAO 1 signals C==>D==>E-to-(E)
* P-DAO 1 信号 C==>D==>E-to-(E)
* P-DAO 2 signals A==>B==>C-to-(C),E
* P-DAO 2 信号 A==>B==>C-to-(C),E
* P-DAO 3 signals F and G via the A-->E-to-F,G Track
* P-DAO 3 は、A-->E-to-F,G トラック経由で F と G に信号を送ります
Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2 and 3 are sent to A, as follows:
次のように、非保存モード P-DAO 1 は C に送信され、非保存モード P-DAO 2 および 3 は A に送信されます。
+====================+==============+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Non-Storing | Non-Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | C | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 1 | 1 |
+====================+--------------+--------------+--------------+
| VIO | D, E | B, C | E |
+====================+--------------+--------------+--------------+
| Targets | | E | F, G |
+====================+--------------+--------------+--------------+
Table 13: P-DAO Messages
表 13: P-DAO メッセージ
Note in the table above that E is an implicit Target in P-DAO 1 and so is C in P-DAO 2. As Non-Storing Mode egress node addresses, they are not listed in the respective RTOs.
上の表では、E が P-DAO 1 の暗黙的なターゲットであり、P-DAO 2 の C であることに注意してください。非ストレージ モードの出力ノード アドレスとして、これらはそれぞれの RTO にリストされていません。
As a result, the RIBs are set as follows:
その結果、RIB は次のように設定されます。
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | C, E | P-DAO 2 | B, C | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 3 | E | (A, 141) |
+------+-------------+---------+-------------+----------+
Table 14: RIB Settings
表 14: RIB 設定
The encapsulating headers of packets that are forwarded along the Track between C and E have the following settings:
C と E 間のトラックに沿って転送されるパケットのカプセル化ヘッダーには、次の設定があります。
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Middle | A | E | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 15: Packet Header Settings
表 15: パケットヘッダー設定
As an example, say that A has a packet for F. Using the RIB in Table 14:
例として、A が F 宛てのパケットを持っているとします。表 14 の RIB を使用すると、次のようになります。
* From P-DAO 3: A encapsulates the packet with a destination of F in the Track signaled by P-DAO 3. The outer header has source A, destination E, and an RPI indicating a TrackID of 141 from A's namespace. This recurses with the following.
* P-DAO 3 から: A は、P-DAO 3 によって通知されたトラックに宛先 F のパケットをカプセル化します。外側のヘッダーには、送信元 A、宛先 E、および A の名前空間からの TrackID 141 を示す RPI が含まれます。これは以下のように再帰的に起こります。
* From P-DAO 2: A encapsulates the packet with a destination of E in the Track signaled by P-DAO 2. The outer header has source A, destination B, an SRH that indicates C as the next loose hop, and an RPI indicating a TrackID of 129 from A's namespace.
* P-DAO 2 から: A は、P-DAO 2 によって通知されたトラック内の E を宛先とするパケットをカプセル化します。外側のヘッダーには、送信元 A、宛先 B、次のルーズ ホップとして C を示す SRH、および A の名前空間からの TrackID 129 を示す RPI が含まれます。
* From the SRH: Packets forwarded by B have source A, destination C, a consumed SRH, and an RPI indicating a TrackID of 129 from A's namespace. C decapsulates.
* SRH から: B によって転送されたパケットには、送信元 A、宛先 C、消費された SRH、および A の名前空間からの TrackID 129 を示す RPI が含まれます。C はカプセル化を解除します。
* From P-DAO 1: C encapsulates the packet with a destination of E in the Track signaled by P-DAO 1. The outer header has source C, destination D, an SRH that indicates E as the next loose hop, and an RPI indicating a TrackID of 131 from C's namespace. E decapsulates.
* P-DAO 1 から: C は、P-DAO 1 によって通知されたトラック内の E を宛先とするパケットをカプセル化します。外側のヘッダーには、送信元 C、宛先 D、E を次のルーズ ホップとして示す SRH、および C の名前空間からの TrackID 131 を示す RPI が含まれます。E はカプセル化を解除します。
In this formulation:
この定式化では次のようになります。
* P-DAO 1 signals C==>D==>E-to-(E)
* P-DAO 1 信号 C==>D==>E-to-(E)
* P-DAO 2 signals A==>B-to-C
* P-DAO 2 信号 A==>B-to-C
* P-DAO 3 signals F and G via the A-->C-->E-to-(E),F,G Track
* P-DAO 3 は、A-->C-->E-to-(E),F,G トラック経由で F と G に信号を送ります。
Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2 and 3 are sent to A, as follows:
次のように、非保存モード P-DAO 1 は C に送信され、非保存モード P-DAO 2 および 3 は A に送信されます。
+====================+==============+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Non-Storing | Non-Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | C | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 1 | 1 |
+====================+--------------+--------------+--------------+
| VIO | D, E | B | C, E |
+====================+--------------+--------------+--------------+
| Targets | | C | F, G |
+====================+--------------+--------------+--------------+
Table 16: P-DAO Messages
表 16: P-DAO メッセージ
As a result, the RIBs are set as follows:
その結果、RIB は次のように設定されます。
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | B, C | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 3 | C, E | (A, 141) |
+------+-------------+---------+-------------+----------+
Table 17: RIB Settings
表 17: RIB 設定
The encapsulating headers of packets that are forwarded along the Track between A and B have the following settings:
A と B の間のトラックに沿って転送されるパケットのカプセル化ヘッダーには、次の設定があります。
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | B until D then E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Middle | A | C | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 18: Packet Header Settings
表 18: パケットヘッダー設定
The encapsulating headers of packets that are forwarded along the Track between B and C have the following settings:
B と C 間のトラックに沿って転送されるパケットのカプセル化ヘッダーには、次の設定があります。
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | C | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 19: Packet Header Settings
表 19: パケットヘッダー設定
The encapsulating headers of packets that are forwarded along the Track between C and E have the following settings:
C と E 間のトラックに沿って転送されるパケットのカプセル化ヘッダーには、次の設定があります。
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Middle | A | E | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 20: Packet Header Settings
表 20: パケットヘッダー設定
As an example, say that A has a packet for F. Using Table 18:
例として、A が F 宛てのパケットを持っているとします。表 18 を使用すると、次のようになります。
* From P-DAO 3: A encapsulates the packet with a destination of F in the Track signaled by P-DAO 3. The outer header has source A, destination C, an SRH that indicates E as the next loose hop, and an RPI indicating a TrackID of 141 from A's namespace. This recurses with the following.
* P-DAO 3 から: A は、P-DAO 3 によって通知されたトラック内の宛先 F を持つパケットをカプセル化します。外側のヘッダーには、送信元 A、宛先 C、次のルーズ ホップとして E を示す SRH、および A の名前空間からの TrackID 141 を示す RPI が含まれます。これは以下のように再帰的に起こります。
* From P-DAO 2: A encapsulates the packet with a destination of C in the Track signaled by P-DAO 2. The outer header has source A, destination B, and an RPI indicating a TrackID of 129 from A's namespace. B decapsulates forwards to C based on a sibling connected route.
* P-DAO 2 から: A は、P-DAO 2 によって通知されたトラック内に宛先 C のパケットをカプセル化します。外側のヘッダーには、送信元 A、宛先 B、および A の名前空間からの TrackID 129 を示す RPI が含まれます。B は、兄弟接続されたルートに基づいて C への転送をカプセル化解除します。
* From the SRH: C consumes the SRH and makes the destination E.
* SRH から: C は SRH を消費し、宛先を E にします。
* From P-DAO 1: C encapsulates the packet with a destination of E in the Track signaled by P-DAO 1. The outer header has source C, destination D, an SRH that indicates E as the next loose hop, and an RPI indicating a TrackID of 131 from C's namespace. E decapsulates.
* P-DAO 1 から: C は、P-DAO 1 によって通知されたトラック内の E を宛先とするパケットをカプセル化します。外側のヘッダーには、送信元 C、宛先 D、E を次のルーズ ホップとして示す SRH、および C の名前空間からの TrackID 131 を示す RPI が含まれます。E はカプセル化を解除します。
To increase the reliability of the P2P transmission, this specification enables building a collection of protection paths between the same ingress and egress Nodes and combining them within the same TrackID, as shown in Figure 7. Protection paths may be interleaved at the edges of loose hops or remain parallel.
P2P 伝送の信頼性を高めるために、この仕様では、図 7 に示すように、同じ入力ノードと出力ノードの間に保護パスの集合を構築し、それらを同じ TrackID 内で組み合わせることができます。保護パスは、ルーズ ホップのエッジでインターリーブすることも、並列のままにすることもできます。
The segments that join the loose hops of a protection path are installed with the same TrackID as the protection path. But each individual protection path and segment has its own P-RouteID that allows it to be managed separately. Two protection paths of the same Track may cross at a common node that is a member of a segment of each protection path or may be joined by additional segments. The final path of a packet may then be the result of interleaving those two (and possibly more) protection paths. In that case, the common node has more than one next hop in its RIB associated to the Track but no specific signal in the packet to indicate which segment is being followed. A next hop that can reach the loose hop is selected.
保護パスのルース ホップに接続するセグメントは、保護パスと同じ TrackID でインストールされます。ただし、個々の保護パスとセグメントには独自の P-RouteID があり、個別に管理できます。同じトラックの 2 つの保護パスは、各保護パスのセグメントのメンバーである共通ノードで交差することも、追加のセグメントによって結合されることもあります。パケットの最終パスは、これら 2 つ (場合によってはそれ以上) の保護パスをインターリーブした結果である可能性があります。その場合、共通ノードの RIB にはトラックに関連付けられたネクスト ホップが 1 つ以上ありますが、どのセグメントがフォローされているかを示す特定の信号がパケット内にありません。ルーズ ホップに到達できるネクスト ホップが選択されます。
< Controller Plane Functions >
Southbound API
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
+----------+
| RPL Root |
+----------+
( main DODAG )
( all around )
<- Protection path 1 via B, E ->
<--- Segment 1 A,B ---> <------- Segment 2 C,D,E ------->
FWD -- Relay -- FWD -- FWD Target 1
/-- Node -- Node -- Node -- Node \ /
--/ (A) (B) \ (C) (D) \ /
Track \ Track
Ingress Segment 5 Egress -- Target
(I) \ -- (E) 2
\ \ / \
\ FWD -- FWD -- Relay -- FWD --/ \
Node -- Node -- Node -- Node Target 3
(F) (G) (H) (J)
<------ Segment 3 F,G,H ------> <---- Segment 4 J,E ---->
<- Protection path 2 via H, E ->
<--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ---->
<- Protection path 3 via B, H, E ->
)
(
( )
Figure 7: Segments and Tracks
図 7: セグメントとトラック
Note that while this specification enables building both segments inside a protection path, for instance, segment 2 above (which is within protection path 1) and Inter-protection-path segments (i.e., North-South) such as segment 5 above (which joins protection paths 1 and 2), it does not signal which Inter-protection-path segments are available to the ingress, so the use of North-South segments and associated path redundancy functions is currently limited. The only possibility available at this time is to define overlapping protection paths as illustrated in Figure 7, with protection path 3 that is congruent with protection path 1 until node B and that is congruent with protection path 2 from node H on, abstracting segment 5 as a forward segment.
この仕様では、保護パス内に両方のセグメント、たとえば上のセグメント 2 (保護パス 1 内にある) と、上のセグメント 5 (保護パス 1 と 2 を結合する) などの保護パス間セグメント (つまり、North-South) の両方を構築することができますが、どの保護パス間セグメントが入力に利用可能であるかは通知されないため、North-South セグメントおよび関連するパス冗長機能の使用は現在制限されていることに注意してください。現時点で利用可能な唯一の可能性は、図 7 に示すように重複する保護パスを定義することです。保護パス 3 はノード B までは保護パス 1 と一致し、ノード H 以降は保護パス 2 と一致し、セグメント 5 を前方セグメントとして抽象化します。
This specification expects that the main DODAG is operated in RPL Non-Storing Mode to sustain the exchanges with the Root. Based on its comprehensive knowledge of the parent-child relationship, the Root can form an abstracted view of the whole DODAG topology. This document adds the capability for nodes to advertise additional sibling information to complement the topological awareness of the Root to be passed on to the PCE and enables the PCE to build more/ better paths that traverse those siblings.
この仕様では、メイン DODAG がルートとの交換を維持するために RPL 非保存モードで動作することを想定しています。ルートは、親子関係に関する包括的な知識に基づいて、DODAG トポロジ全体の抽象化されたビューを形成できます。このドキュメントでは、PCE に渡されるルートのトポロジ認識を補完する追加の兄弟情報をノードがアドバタイズする機能を追加し、PCE がこれらの兄弟を通過するより多くの/より適切なパスを構築できるようにします。
P-Routes require resources such as routing table space in the routers and bandwidth on the links; the amount of state that is installed in each node must be computed to fit within the node's memory, and the amount of rerouted traffic must fit within the capabilities of the transmission links. The methods used to learn the node capabilities and the resources that are available in the devices and in the network are out of scope for this document. The method to capture and report the LLN link capacity and reliability statistics are also out of scope. They may be fetched from the nodes through network management functions or other forms of telemetry such as Operations, Administration, and Maintenance (OAM).
P ルートには、ルーター内のルーティング テーブル スペースやリンク上の帯域幅などのリソースが必要です。各ノードにインストールされる状態の量は、ノードのメモリ内に収まるように計算する必要があり、再ルーティングされるトラフィックの量は、伝送リンクの能力内に収まるように計算する必要があります。ノードの機能と、デバイスおよびネットワークで利用可能なリソースを学習するために使用される方法は、このドキュメントの範囲外です。LLN リンク容量と信頼性統計を取得して報告する方法も対象外です。これらは、ネットワーク管理機能または運用、管理、保守 (OAM) などの他の形式のテレメトリを通じてノードから取得される場合があります。
The 6TiSCH architecture [RFC9030] leverages a centralized model that is similar to that of the DetNet architecture [RFC8655], whereby the device resources and capabilities are exposed to an external controller that installs routing states into the network based on its own Objective Functions that reside in that external entity.
6TiSCH アーキテクチャ [RFC9030] は、DetNet アーキテクチャ [RFC8655] と同様の集中モデルを利用しています。これにより、デバイスのリソースと機能が、外部エンティティに存在する独自の目的関数に基づいてネットワークにルーティング状態をインストールする外部コントローラに公開されます。
DetNet forwarding nodes only understand the simple 1-to-1 forwarding sublayer transport operation along a segment whereas the more sophisticated relay nodes can also provide service sublayer functions such as Replication and Elimination.
DetNet 転送ノードは、セグメントに沿った単純な 1 対 1 転送サブレイヤ トランスポート操作のみを理解しますが、より高度な中継ノードは、レプリケーションやエリミネーションなどのサービス サブレイヤ機能も提供できます。
One possible mapping between DetNet and this specification is to signal the relay nodes as the hops of a protection path and the forwarding nodes as the hops in a segment that join the relay nodes as illustrated in Figure 7.
DetNet とこの仕様の間で考えられるマッピングの 1 つは、図 7 に示すように、中継ノードを保護パスのホップとして信号で通知し、転送ノードを中継ノードに接続するセグメント内のホップとして信号で通知することです。
With DetNet and 6TiSCH, the component of the controller that is responsible for computing routes is a PCE. The PCE computes its routes based on its own Objective Functions, as described in [RFC4655], and typically controls the routes using the PCE Communication Protocol (PCEP) [RFC5440]. While this specification expects a PCE, and while PCEP might effectively be used between the Root and the PCE, the control protocol between the PCE and the Root is out of scope.
DetNet と 6TiSCH では、ルートの計算を担当するコントローラーのコンポーネントは PCE です。PCE は、[RFC4655] で説明されているように、独自の目的関数に基づいてルートを計算し、通常は PCE 通信プロトコル (PCEP) [RFC5440] を使用してルートを制御します。この仕様は PCE を想定しており、PCEP はルートと PCE の間で効果的に使用される可能性がありますが、PCE とルートの間の制御プロトコルは範囲外です。
This specification also expects a single PCE with a full view of the network. Distributing the PCE function for a large network is out of scope. This specification uses the RPL Root as a proxy to the PCE. The PCE may be collocated with the Root or may reside in an external Controller. In the latter case, the protocol between the Root and the PCE is out of scope and mapped to RPL inside the DODAG; one possible control protocol between the Root and external PCE is for the Root to transmit the information it received in the RPL DAOs, including all the SIOs that detail the parent/child and sibling information, to the PCEs.
この仕様では、ネットワークの全体像を把握できる単一の PCE も想定しています。大規模なネットワークに対する PCE 機能の分散は対象外です。この仕様では、RPL ルートを PCE へのプロキシとして使用します。PCE はルートと同じ場所に配置されることも、外部コントローラーに常駐することもあります。後者の場合、ルートと PCE の間のプロトコルは範囲外となり、DODAG 内の RPL にマッピングされます。ルートと外部 PCE の間で可能な制御プロトコルの 1 つは、ルートが RPL DAO で受信した情報 (親/子および兄弟情報の詳細を示すすべての SIO を含む) を PCE に送信することです。
The algorithm to compute the paths, the protocol used by the PCE, and the metrics and link statistics involved in the computation are also out of scope. The effectiveness of the route computation by the PCE depends on the quality of the metrics that are reported from the RPL network. Which metrics are used and how they are reported are out of scope, but the expectation is that they are mostly of a long-term, statistical nature and provide visibility on link throughput, latency, stability, and availability over relatively long periods.
パスを計算するアルゴリズム、PCE で使用されるプロトコル、計算に含まれるメトリックとリンク統計も対象外です。PCE によるルート計算の有効性は、RPL ネットワークから報告されるメトリックの品質に依存します。どのメトリクスが使用され、どのように報告されるかについては範囲外ですが、これらのメトリクスは主に長期的な統計的な性質のものであり、比較的長期間にわたるリンクのスループット、遅延、安定性、可用性に関する可視性を提供することが期待されています。
A recovery graph as in the RAW architecture [RAW-ARCH] can be composed of forward East-West directional segments and North-South bidirectional segments to enable additional path diversity using PREOF to select the protection paths to be used for a given datagram. This provides a dynamic balance between the reliability and availability requirements of the flows and the need to conserve energy and spectrum. This specification prepares for RAW by setting up the Tracks, but it only forms DODAGs, which are composed of aggregated end-to-end loose source-routed protection paths, joined by strict routed segments, all oriented forward.
RAW アーキテクチャ [RAW-ARCH] のようなリカバリ グラフは、順方向の東西方向セグメントと南北双方向セグメントで構成でき、PREOF を使用して特定のデータグラムに使用する保護パスを選択する追加のパス ダイバーシティを可能にします。これにより、フローの信頼性と可用性の要件と、エネルギーとスペクトルを節約する必要性との間の動的なバランスが提供されます。この仕様は、トラックを設定することによって RAW を準備しますが、DODAG を形成するだけです。DODAG は、厳密にルーティングされたセグメントによって結合された、集約されたエンドツーエンドの緩やかなソースルーティング保護パスで構成され、すべて前方に向けられています。
The RAW architecture defines a data plane extension of the PCE called the Point of Local Repair (PLR) that adapts the use of the path redundancy within a Track to defeat the diverse causes of packet loss. The PLR controls the forwarding operation of the packets within a Track. This specification can use but does not impose a PLR and does not provide the policies that would select which packets are routed through which path within a Track (in other words, how the PLR may use the path redundancy within the Track). By default, the use of the available redundancy is limited to simple load balancing, and all the segments are forward unidirectional only.
RAW アーキテクチャは、パケット損失のさまざまな原因を克服するためにトラック内のパス冗長性の使用を適応させる、Point of Local Repair (PLR) と呼ばれる PCE のデータ プレーン拡張を定義します。PLR は、トラック内のパケットの転送動作を制御します。この仕様は、PLR を使用できますが、強制するものではなく、どのパケットがトラック内のどのパスを経由してルーティングされるかを選択するポリシー (つまり、PLR がトラック内のパス冗長性をどのように使用できるか) を提供しません。デフォルトでは、利用可能な冗長性の使用は単純なロード バランシングに限定されており、すべてのセグメントは順方向のみです。
A Track may be set up to reduce the load around the Root or to enable urgent traffic to flow more directly. This specification does not provide the policies that would decide which flows are routed through which Track. In a Non-Storing Mode RPL Instance, the main DODAG provides a default route via the Root, and the Tracks provide more-specific routes to the Track Targets.
トラックは、ルート周辺の負荷を軽減するため、または緊急のトラフィックがより直接的に流れるようにするために設定できます。この仕様では、どのフローがどのトラックを経由するかを決定するポリシーは提供されません。非保存モード RPL インスタンスでは、メイン DODAG はルート経由でデフォルト ルートを提供し、トラックはより具体的なルートをトラック ターゲットに提供します。
This section explains which changes are extensions and which are amendments to existing specifications. It is expected that extensions to existing specifications will not cause existing code on legacy 6LRs to malfunction, as the extensions will simply be ignored. New code is required for an extension. Those 6LRs will be unable to function in the new mechanisms and may also make the P-DAOs impossible to install. Amendments to existing specifications are situations where there are semantic changes required to existing code and where new unit tests may be required to confirm that legacy operations will continue unaffected.
このセクションでは、どの変更が拡張であり、どの変更が既存の仕様の修正であるかを説明します。既存の仕様の拡張は単に無視されるため、レガシー 6LR 上の既存のコードが誤動作することはないと予想されます。拡張には新しいコードが必要です。これらの 6LR は新しいメカニズムでは機能できなくなり、P-DAO のインストールも不可能になる可能性があります。既存の仕様の修正とは、既存のコードにセマンティックな変更が必要な場合や、従来の操作が影響を受けずに継続されることを確認するために新しい単体テストが必要になる場合を指します。
This specification Extends RPL [RPL] to enable the Root to install forward routes inside a main DODAG that is operated as Non-Storing Mode. The Root issues a P-DAO message (see Section 4.1.1) to the Track ingress; the P-DAO message contains a new VIO that installs a strict or a loose sequence of hops to form a Track segment or a protection path, respectively.
この仕様は、RPL [RPL] を拡張して、ルートが非保存モードとして動作するメイン DODAG 内に転送ルートをインストールできるようにします。ルートは P-DAO メッセージ (セクション 4.1.1 を参照) をトラック入口に発行します。P-DAO メッセージには、トラック セグメントまたは保護パスをそれぞれ形成する厳密なホップ シーケンスまたはルーズなホップ シーケンスをインストールする新しい VIO が含まれています。
The Projected DAO Request (P-DAO-REQ) is a new message detailed in Section 5.1. As per Section 6 of [RPL], if a node receives this message and it does not understand this new code, it discards the message. When the Root initiates communication to a node that it has not communicated with before and that it has not ascertained to implement this specification (by means such as capabilities), then the Root SHOULD request a Projected DAO Request Acknowledgment (PDR-ACK).
投影された DAO リクエスト (P-DAO-REQ) は、セクション 5.1 で詳述される新しいメッセージです。[RPL] のセクション 6 に従って、ノードがこのメッセージを受信し、この新しいコードを理解できない場合は、メッセージを破棄します。ルートが、以前に通信したことがなく、(機能などの手段によって) この仕様を実装することを確認していないノードとの通信を開始する場合、ルートは投影された DAO 要求肯定応答 (PDR-ACK) を要求する必要があります (SHOULD)。
A P-DAO-REQ message enables a Track ingress to request the Track from the Root. The resulting Track is also a DODAG for which the Track ingress is the Root, and the owner is the address that serves as the DODAGID and is authoritative for the associated namespace from which the TrackID is selected. In the context of this specification, the installed route appears as a more-specific route to the Track Targets, and the Track ingress forwards the packets toward the Targets via the Track using normal longest match IP forwarding.
P-DAO-REQ メッセージにより、トラック入力がルートからトラックを要求できるようになります。結果として得られる Track も DODAG であり、その Track ingress がルートであり、所有者は DODAGID として機能するアドレスであり、TrackID が選択される関連する名前空間に対して権限を持ちます。この仕様のコンテキストでは、インストールされたルートはトラック ターゲットへのより具体的なルートとして表示され、トラック入力は通常の最長一致 IP 転送を使用してトラック経由でターゲットにパケットを転送します。
To ensure that the P-DAO-REQ and P-DAO messages can flow at most times, it is RECOMMENDED that the nodes involved in a Track maintain multiple parents in the main DODAG, advertise them all to the Root, and use them in turn to retry similar packets. It is also RECOMMENDED that the Root uses diverse source route paths to retry similar messages to the nodes in the Track.
P-DAO-REQ および P-DAO メッセージが常に流れるようにするために、トラックに関与するノードがメイン DODAG 内に複数の親を維持し、それらをすべてルートにアドバタイズし、それらを順番に使用して同様のパケットを再試行することが推奨されます。また、ルートがさまざまなソース ルート パスを使用して、トラック内のノードへの同様のメッセージを再試行することも推奨されます。
Section 6 of [RPL] introduces the RPL Control Message Options (CMOs), including the RPL Target Option (RTO) and Transit Information Option (TIO), which can be placed in RPL messages such as the DAO. A DAO message signals routing information to one or more Targets indicated in the RTOs and provides one and only one via-node in the TIO, with the via-node being the tunnel endpoint to reach the targets.
[RPL] のセクション 6 では、DAO などの RPL メッセージに配置できる、RPL ターゲット オプション (RTO) および通過情報オプション (TIO) を含む、RPL 制御メッセージ オプション (CMO) を紹介します。DAO メッセージは、RTO で示された 1 つ以上のターゲットにルーティング情報を通知し、TIO 内に 1 つだけの経由ノードを提供します。経由ノードは、ターゲットに到達するためのトンネル エンドポイントになります。
This document Amends the specification of the DAO to create the P-DAO message. This Amended DAO is signaled with a new "Projected DAO" (P) flag; see Figure 8.
この文書は、P-DAO メッセージを作成するために DAO の仕様を修正します。この修正 DAO は、新しい「投影 DAO」(P) フラグで通知されます。図 8 を参照してください。
A P-DAO is a special DAO message generated by the Root to install a P-Route formed of multiple hops in its DODAG. This provides a RPL-based method to install the Tracks as a collection of multiple P-Routes as expected by the 6TiSCH architecture [RFC9030].
P-DAO は、複数のホップで構成される P-Route を DODAG にインストールするためにルートによって生成される特別な DAO メッセージです。これは、6TiSCH アーキテクチャ [RFC9030] で期待されるように、複数の P-Route の集合としてトラックをインストールするための RPL ベースの方法を提供します。
The Root MUST source the P-DAO message with its address that serves as the DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO message that is not sent by the Root of its DODAG and MUST ignore such messages silently.
ルートは、メイン DODAG の DODAGID として機能するアドレスを持つ P-DAO メッセージをソースしなければなりません (MUST)。受信者は、DODAG のルートによって送信されない P-DAO メッセージを受け入れてはならず、そのようなメッセージを黙って無視しなければなりません (MUST)。
The 'P' flag is encoded in bit position 2 of the Flags field in the DAO Base Object. The Root MUST set it to 1 in a P-DAO message. Otherwise, it MUST be set to 0. It is set to 0 in legacy implementations as specified, respectively, in Sections 20.11 and 6.4 of [RPL].
「P」フラグは、DAO 基本オブジェクトの Flags フィールドのビット位置 2 でエンコードされます。ルートは、P-DAO メッセージ内でこれを 1 に設定しなければなりません (MUST)。それ以外の場合は、0 に設定しなければなりません (MUST)。レガシー実装では、[RPL] のセクション 20.11 および 6.4 でそれぞれ指定されているように、0 に設定されます。
The P-DAO is a part of control plane signaling and should not be stuck behind high traffic levels. The expectation is that the P-DAO message be sent at a high QoS level, above that of data traffic, typically with the Network Control precedence.
P-DAO はコントロール プレーン シグナリングの一部であり、高いトラフィック レベルの背後で立ち往生すべきではありません。P-DAO メッセージは、データ トラフィックよりも高い QoS レベルで、通常はネットワーク制御の優先順位で送信されることが期待されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|D|P| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| DODAGID field is set to the |
+ IPv6 address of the Track ingress +
| used to source encapsulated packets |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 8: Projected DAO Base Object
図 8: 投影された DAO ベース オブジェクト
New fields:
新しいフィールド:
TrackID:
トラックID:
The Local or Global RPLInstanceID of the DODAG that serves as the Track (see more in Section 6.3).
トラックとして機能する DODAG のローカルまたはグローバル RPLInstanceID (詳細はセクション 6.3 を参照)。
P:
P:
1-bit flag.
1ビットのフラグ。
The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise, it is set to 0.
「P」フラグはルートによって 1 に設定され、P-DAO に信号を送ります。それ以外の場合は 0 に設定されます。
The 'D' flag is set to 1 to signal that the DODAGID field is present. It may be set to 0 if and only if the destination address of the Projected DAO Acknowledgment (P-DAO-ACK) message is set to the IPv6 address that serves as the DODAGID, and it MUST be set to one otherwise, meaning that the DODAGID field MUST then be present.
「D」フラグは 1 に設定され、DODAGID フィールドが存在することを示します。Projected DAO Acknowledgment (P-DAO-ACK) メッセージの宛先アドレスが DODAGID として機能する IPv6 アドレスに設定されている場合に限り、0 に設定できます。それ以外の場合は 1 に設定しなければなりません。つまり、DODAGID フィールドが存在しなければなりません。
In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO message to inform the DODAG Root of all the edges in the DODAG, which are formed by the directed parent-child relationships. The DAO message signals to the Root that a given parent can be used to reach a given child. The P-DAO message generalizes the DAO to signal to the Track ingress that a Track, for which the sender is the Root, can be used to reach children and siblings of the Track egress. In both cases, options may be factorized and multiple RTOs may be present to signal a collection of children that can be reached through the parent or the Track, respectively.
RPL 非保存モードでは、TIO と RTO が DAO メッセージ内で結合され、有向親子関係によって形成される DODAG 内のすべてのエッジを DODAG ルートに通知します。DAO メッセージは、特定の親を使用して特定の子に到達できることをルートに通知します。P-DAO メッセージは、送信者がルートであるトラックを使用してトラック出口の子および兄弟に到達できることをトラック入口に信号を送るように DAO を一般化します。どちらの場合も、オプションは因数分解され、複数の RTO が存在して、それぞれ親またはトラックを通じて到達できる子のコレクションを通知することができます。
This document also Amends the DAO-ACK message. The new 'P' flag signals the projected form.
この文書は DAO-ACK メッセージも修正します。新しい「P」フラグは、投影されたフォームを示します。
The format of the P-DAO-ACK message is thus illustrated in Figure 9:
P-DAO-ACK メッセージのフォーマットを図 9 に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |D|P| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| DODAGID field is set to the |
+ IPv6 address of the Track ingress +
| used to source encapsulated packets |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 9: P-DAO-ACK Base Object
図 9: P-DAO-ACK ベース オブジェクト
New fields:
新しいフィールド:
TrackID:
トラックID:
The Local or Global RPLInstanceID of the DODAG that serves as the Track (see more in Section 6.3).
トラックとして機能する DODAG のローカルまたはグローバル RPLInstanceID (詳細はセクション 6.3 を参照)。
P:
P:
1-bit flag.
1ビットのフラグ。
The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise, it is set to 0.
「P」フラグはルートによって 1 に設定され、P-DAO に信号を送ります。それ以外の場合は 0 に設定されます。
The 'D' flag is set to 1 to signal that the DODAGID field is present. It may be set to 0 if and only if the source address of the P-DAO-ACK message is set to the IPv6 address that serves as the DODAGID, and it MUST be set to one otherwise, meaning that the DODAGID field MUST then be present.
「D」フラグは 1 に設定され、DODAGID フィールドが存在することを示します。P-DAO-ACK メッセージの送信元アドレスが DODAGID として機能する IPv6 アドレスに設定されている場合にのみ 0 に設定できます。それ以外の場合は 1 に設定しなければなりません。つまり、DODAGID フィールドが存在しなければなりません。
This document Extends the CMO to create new objects called Via Information Options (VIOs). The VIOs are the multi-hop alternative to the TIOs (see more in Section 5.3). One VIO is the stateful Storing Mode VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop P-Route called a Track segment. The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs a loose source-routed P-Route called a protection path at the Track ingress, which uses that state to encapsulate an IP-in-IP packet with a new Routing Header (RH) to the Track egress (see more in Section 6.7).
このドキュメントは、CMO を拡張して、Via Information Options (VIO) と呼ばれる新しいオブジェクトを作成します。VIO は、TIO に代わるマルチホップです (詳細はセクション 5.3 を参照)。1 つの VIO はステートフル ストレージ モード VIO (SM-VIO) です。SM-VIO は、トラック セグメントと呼ばれる厳密なホップバイホップ P-Route をインストールします。もう 1 つは非保存モード VIO (NSM-VIO) です。NSM-VIO は、保護パスと呼ばれるルーズなソースルーティング P ルートをトラック入口にインストールします。この P ルートは、その状態を使用して、トラック出口への新しいルーティング ヘッダー (RH) を持つ IP-in-IP パケットをカプセル化します (詳細はセクション 6.7 を参照)。
A P-DAO contains one or more RTOs to indicate the Target (destinations) that can be reached via the P-Route, followed by exactly one VIO that signals the sequence of nodes to be followed (see more in Section 6). There are two modes of operation for the P-Routes: Storing Mode and Non-Storing Mode (see more in Sections 6.4.2 and 6.4.3, respectively).
P-DAO には、P-Route 経由で到達できるターゲット (宛先) を示す 1 つ以上の RTO が含まれており、その後に、たどるノードのシーケンスを信号で知らせる 1 つの VIO が続きます (詳細はセクション 6 を参照)。P ルートには、保存モードと非保存モードの 2 つの動作モードがあります (詳細はそれぞれセクション 6.4.2 と 6.4.3 を参照してください)。
This specification Extends the CMO to create the Sibling Information Option (SIO). The SIO is used by a RPL-Aware Node (RAN) to advertise a selection of its candidate neighbors as siblings to the Root (see more in Section 5.4). The SIO is placed in DAO messages that are sent directly to the main Root, including multicast DAO (see Section 9.10 of [RPL]).
この仕様は、CMO を拡張して兄弟情報オプション (SIO) を作成します。SIO は、RPL 認識ノード (RAN) によって、選択した近隣候補をルートの兄弟としてアドバタイズするために使用されます (詳細はセクション 5.4 を参照)。SIO は、マルチキャスト DAO を含む、メイン ルートに直接送信される DAO メッセージに配置されます ([RPL] のセクション 9.10 を参照)。
This specification Amends rules 1 and 2 listed in Section 9.10 of [RPL] for the multicast DAO operation as follows:
この仕様は、マルチキャスト DAO 操作に関して [RPL] のセクション 9.10 にリストされているルール 1 および 2 を次のように修正します。
OLD:
OLD:
1. A node MAY multicast a DAO message to the link-local scope all-RPL-nodes multicast address.
1. ノードは、DAO メッセージをリンクローカル スコープの全 RPL ノードのマルチキャスト アドレスにマルチキャストしてもよい (MAY)。
2. A multicast DAO message MUST be used only to advertise information about the node itself, i.e., prefixes directly connected to or owned by the node, such as a multicast group that the node is subscribed to or a global address owned by the node
2. マルチキャスト DAO メッセージは、ノード自体に関する情報、つまり、ノードがサブスクライブしているマルチキャスト グループやノードが所有するグローバル アドレスなど、ノードに直接接続されている、またはノードが所有しているプレフィックスなどの情報をアドバタイズするためにのみ使用しなければなりません (MUST)。
NEW:
NEW:
1. A multicast DAO message MUST be used only to advertise information about the node (using the Target Option) and direct Link Neighbors such as learned by Neighbor Discovery (using the SIO).
1. マルチキャスト DAO メッセージは、(ターゲット オプションを使用して) ノードに関する情報と、(SIO を使用して) 近隣探索によって学習されたようなダイレクト リンク ネイバーに関する情報をアドバタイズするためにのみ使用しなければなりません (MUST)。
2. The multicast DAO may be used to enable direct and indirect (via a common neighbor) P2P communication without needing the DODAG to relay the packets. The multicast DAO exposes the sender's addresses as Targets in RTOs and the sender's neighbors addresses as siblings in SIOs; this tells the sender's neighbors that the sender is willing to act as a relay between those of its neighbors that are too far apart.
2. マルチキャスト DAO を使用すると、DODAG がパケットを中継する必要がなく、直接的および間接的 (共通の近隣経由) の P2P 通信を可能にすることができます。マルチキャスト DAO は、送信者のアドレスを RTO のターゲットとして公開し、送信者の近隣アドレスを SIO の兄弟として公開します。これは、送信者の近隣者に、送信者が遠すぎる近隣者間の中継役として機能する意思があることを伝えます。
The set of RPL Control Messages is Extended to include the P-DAO-REQ and PDR-ACK. These two new RPL Control Messages enable a RAN to request the establishment of a Track between itself (as the Track ingress Node) and a Track egress. The node makes its request by sending a new P-DAO-REQ message to the Root. The Root confirms with a new PDR-ACK message back to the requester RAN; see Section 5.1 for more.
RPL 制御メッセージのセットは、P-DAO-REQ および PDR-ACK を含むように拡張されています。これら 2 つの新しい RPL 制御メッセージにより、RAN は、RAN 自身 (トラック入口ノードとして) とトラック出口との間のトラックの確立を要求できるようになります。ノードは、新しい P-DAO-REQ メッセージをルートに送信することによって要求を行います。ルートは、要求側 RAN に新しい PDR-ACK メッセージを返して確認します。詳細については、セクション 5.1 を参照してください。
Sending a packet within a RPL Local Instance requires the presence of the abstract RPI described in Section 11.2 of [RPL] in the outer IPv6 header chain (see [RFC9008]). The RPI carries a Local RPLInstanceID that, in association with either the source or the destination address in the IPv6 header, indicates the RPL Instance that the packet follows.
RPL ローカル インスタンス内でパケットを送信するには、[RPL] のセクション 11.2 で説明されている抽象 RPI が外側の IPv6 ヘッダー チェーンに存在する必要があります ([RFC9008] を参照)。RPI は、IPv6 ヘッダー内の送信元アドレスまたは宛先アドレスに関連して、パケットが続く RPL インスタンスを示すローカル RPLInstanceID を伝送します。
This specification Amends [RPL] to create a new flag that signals when a packet is forwarded along a P-Route.
この仕様は、パケットが P ルートに沿って転送されるときに通知する新しいフラグを作成するために [RPL] を修正します。
Projected-Route 'P':
投影ルート「P」:
1-bit flag. It is set to 1 in the RPI that is added in the encapsulation when a packet is sent over a Track. It is set to 0 when a packet is forwarded along the main DODAG (as a Track), including when the packet follows a segment that joins loose hops of the main DODAG. The flag is not mutable en route.
1ビットのフラグ。これは、パケットがトラック上で送信されるときにカプセル化に追加される RPI で 1 に設定されます。パケットがメイン DODAG に沿って (トラックとして) 転送されるとき、これは 0 に設定されます。これには、パケットがメイン DODAG のルーズ ホップに結合するセグメントに従うときも含まれます。フラグは途中で変更できません。
The encoding of the 'P' flag in native format is shown in Section 4.2 while the compressed format is indicated in Section 4.3.
ネイティブ形式の「P」フラグのエンコーディングはセクション 4.2 に示され、圧縮形式はセクション 4.3 に示されます。
The DODAG Configuration option is defined in Section 6.7.6 of [RPL]. Its purpose is extended to distribute configuration information affecting the construction and maintenance of the DODAG, as well as operational parameters for RPL on the DODAG, through the DODAG. This option was originally designed with four bit positions reserved for future use as Flags.
DODAG 設定オプションは、[RPL] のセクション 6.7.6 で定義されています。その目的は、DODAG の構築と保守に影響を与える構成情報、および DODAG 上の RPL の動作パラメータを DODAG を通じて配布するように拡張されています。このオプションは元々、将来フラグとして使用するために 4 つのビット位置を予約して設計されました。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14|D| | | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits |
Figure 10: DODAG Configuration Option (Partial View)
図 10: DODAG 構成オプション (部分図)
This specification Amends [RPL] to define the new "Projected Routes Support" (D) flag. The 'D' flag is encoded in bit position 0 of the reserved Flags in the DODAG Configuration option (this is the most significant bit). It is set to 0 in legacy implementations as specified respectively in Sections 20.14 and 6.7.6 of [RPL].
この仕様は、新しい「投影ルートのサポート」(D) フラグを定義するために [RPL] を修正します。「D」フラグは、DODAG 構成オプションの予約済みフラグのビット位置 0 でエンコードされます (これは最上位ビットです)。[RPL] のセクション 20.14 および 6.7.6 でそれぞれ指定されているように、従来の実装では 0 に設定されます。
The 'D' flag is set to 1 to indicate that this specification is enabled in the network and that the Root will install the requested Tracks when feasible upon receiving a P-DAO-REQ message.
「D」フラグは 1 に設定され、この仕様がネットワークで有効になっていること、およびルートが P-DAO-REQ メッセージの受信時に可能な場合に要求されたトラックをインストールすることを示します。
Section 4.1.2 of [RFC9008] Amends [RPL] to indicate that the definition of the Flags applies to MOP values from zero (0) to six (6) only. For a MOP value of 7, the implementation MUST consider that the Root accepts P-DAO-REQ messages and will install P-Routes.
[RFC9008] のセクション 4.1.2 は [RPL] を修正し、フラグの定義が 0 から 6 までの MOP 値のみに適用されることを示します。MOP 値が 7 の場合、実装はルートが P-DAO-REQ メッセージを受け入れ、P-Routes をインストールすることを考慮しなければなりません (MUST)。
The RPL DODAG Configuration option is typically placed in a DIO message. The DIO message propagates down the DODAG to form and then maintain its structure. The DODAG Configuration option is copied unmodified from parents to children.
RPL DODAG 構成オプションは通常、DIO メッセージに配置されます。DIO メッセージは DODAG を伝播してその構造を形成し、維持します。DODAG 設定オプションは、変更されずに親から子にコピーされます。
[RPL] states that:
[RPL] は次のように述べています。
Nodes other than the DODAG root MUST NOT modify this information when propagating the DODAG Configuration option.
DODAG ルート以外のノードは、DODAG 設定オプションを伝播するときにこの情報を変更してはなりません (MUST NOT)。
Therefore, a legacy parent propagates the 'D' flag as set by the Root, and when the 'D' flag is set to 1, it is transparently flooded to all the nodes in the DODAG.
したがって、レガシーの親は、ルートによって設定された「D」フラグを伝播し、「D」フラグが 1 に設定されると、DODAG 内のすべてのノードに透過的にフラッディングされます。
"The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" [RFC6553] describes the RPL Option for use among RPL routers to include the abstract RPI described in Section 11.2 of [RPL] in data packets.
「データプレーンデータグラムで RPL 情報を搬送するための低電力および損失の多いネットワーク用ルーティング プロトコル (RPL) オプション」[RFC6553] は、[RPL] のセクション 11.2 で説明されている抽象 RPI をデータ パケットに含めるために RPL ルータ間で使用する RPL オプションについて説明しています。
The RPL Option is commonly referred to as the RPI even though the RPI is really the abstract information that is transported in the RPL Option. [RFC9008] updated the Option Type from 0x63 to 0x23.
RPL オプションは、実際には RPL オプションで転送される抽象的な情報ですが、一般に RPI と呼ばれます。[RFC9008] は、オプション タイプを 0x63 から 0x23 に更新しました。
This specification Extends the RPL Option to encode the 'P' flag as follows:
この仕様は、次のように「P」フラグをエンコードするように RPL オプションを拡張します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Amended RPL Option Format
図 11: 修正された RPL オプションの形式
Option Type:
オプションの種類:
0x23 or 0x63; see [RFC9008].
0x23 または 0x63;[RFC9008]を参照してください。
Opt Data Len:
オプトデータレン:
See [RFC6553].
[RFC6553]を参照してください。
'O', 'R', and 'F' flags:
「O」、「R」、および「F」フラグ:
See [RFC6553]. These flags MUST be set to 0 by the sender and MUST be ignored by the receiver if the 'P' flag is set.
[RFC6553]を参照してください。これらのフラグは送信者によって 0 に設定されなければならず (MUST)、「P」フラグが設定されている場合は受信者によって無視されなければなりません (MUST)。
Projected-Route 'P':
投影ルート「P」:
1-bit flag as defined in Section 4.1.6.
セクション 4.1.6 で定義されている 1 ビットのフラグ。
RPLInstanceID:
RPLインスタンスID:
See [RFC6553]. Indicates the TrackID if the 'P' flag is set, as discussed in Section 4.1.1.
[RFC6553]を参照してください。セクション 4.1.1 で説明したように、「P」フラグが設定されている場合は TrackID を示します。
SenderRank:
送信者ランク:
See [RFC6553]. This field MUST be set to 0 by the sender and MUST be ignored by the receiver if the 'P' flag is set.
[RFC6553]を参照してください。このフィールドは送信者によって 0 に設定されなければならず (MUST)、「P」フラグが設定されている場合は受信者によって無視されなければなりません (MUST)。
The 6LoWPAN Routing Header specification [RFC8138] introduces a new 6LoWPAN [RFC6282] dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of RPL data packet compression.
6LoWPAN ルーティング ヘッダー仕様 [RFC8138] では、6LoWPAN ルートオーバー トポロジで使用するための新しい 6LoWPAN [RFC6282] ディスパッチ タイプが導入されており、これは最初に RPL データ パケット圧縮のニーズをカバーします。
Section 4 of [RFC8138] presents the generic formats of the 6LoRH in two forms: Elective, which can be ignored and skipped when the router does not understand it, and Critical, which causes the packet to be dropped when the router cannot process it. The 'E' flag in the 6LoRH indicates its form. In order to skip the Elective 6LoRHs, their format imposes a fixed expression of the size, whereas the size of a Critical 6LoRH may be signaled in variable forms to enable additional optimizations.
[RFC8138] のセクション 4 では、6LoRH の一般的なフォーマットを 2 つの形式で示しています。1 つはルーターが理解できない場合に無視してスキップできる Elective、もう 1 つはルーターが処理できない場合にパケットをドロップさせる Critical です。6LoRH の「E」フラグはその形式を示しています。選択的 6LoRH をスキップするために、その形式ではサイズの固定式が強制されますが、クリティカル 6LoRH のサイズは、追加の最適化を可能にするために可変形式で通知される場合があります。
When compression as described in [RFC8138] is used, the Root of the main DODAG that sets up the Track also constructs the compressed Routing Header (SRH-6LoRH) on behalf of the Track ingress, which avoids the complexities of optimizing SRH-6LoRH encoding in constrained code. In that case, the SRH-6LoRH is signaled in the NSM-VIO, and it is expressed in a fashion that can be placed as is in the packet encapsulation by the Track ingress.
[RFC8138] で説明されている圧縮が使用される場合、トラックを設定するメイン DODAG のルートは、トラックのイングレスに代わって圧縮されたルーティング ヘッダー (SRH-6LoRH) も構築します。これにより、制約付きコードでの SRH-6LoRH エンコーディングの最適化の複雑さが回避されます。その場合、SRH-6LoRH は NSM-VIO でシグナリングされ、Track イングレスによるパケット カプセル化にそのまま配置できる形式で表現されます。
Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN RH of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL operation. The format of the RPI-6LoRH is not suited for P-Routes since the 'O', 'R', and 'F' flags are not used and the Rank is unknown and ignored.
[RFC8138] のセクション 6.3 は、通常の RPL 動作のために RPI を圧縮するタイプ 5 の 6LoWPAN RH (RPI-6LoRH) のフォーマットを示しています。RPI-6LoRH の形式は、「O」、「R」、および「F」フラグが使用されず、ランクが不明で無視されるため、P ルートには適していません。
This specification Extends [RFC8138] to introduce a new 6LoRH, the P-RPI-6LoRH, that can be used in either Elective or Critical 6LoRH form; see Tables 22 and 23, respectively. The new 6LoRH MUST be used as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the routing decision, in which case it MAY be used in Elective form.
この仕様は [RFC8138] を拡張して、選択的またはクリティカル 6LoRH 形式で使用できる新しい 6LoRH、P-RPI-6LoRH を導入します。それぞれ表 22 と 23 を参照してください。新しい 6LoRH は、SRH-6LoRH が存在し、ルーティング決定を制御しない限り、クリティカル 6LoRH として使用しなければなりません (MUST)。SRH-6LoRH が存在し、ルーティング決定を制御する場合は、選択形式で使用できます。
The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes. Its format is as follows:
P-RPI-6LoRH は、RPL P ルートに沿って RPI を圧縮するように設計されています。その形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|E| Length | 6LoRH Type | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: P-RPI-6LoRH Format
図 12: P-RPI-6LoRH フォーマット
6LoRH Type:
6LoRHタイプ:
IANA has defined the value 8 for both the Elective and Critical forms.
IANA は、選択形式と重要形式の両方に値 8 を定義しました。
Elective 'E':
選択「E」:
See [RFC8138]. The 'E' flag is set to 1 to indicate an Elective 6LoRH, meaning that it can be ignored when forwarding.
[RFC8138]を参照してください。「E」フラグは 1 に設定され、選択的 6LoRH を示します。これは、転送時に無視できることを意味します。
RPLInstanceID :
RPLインスタンスID:
In the context of this specification, the RPLInstanceID field signals the TrackID; see Sections 3.4 and 6.3.
この仕様のコンテキストでは、RPLInstanceID フィールドは TrackID を通知します。セクション 3.4 および 6.3 を参照してください。
Section 6.8 details how a Track ingress leverages the P-RPI-6LoRH header as part of the encapsulation of a packet to place it into a Track.
セクション 6.8 では、トラック入力がパケットのカプセル化の一部として P-RPI-6LoRH ヘッダーを利用してパケットをトラックに配置する方法について詳しく説明します。
The P-DAO-REQ message is sent by a node in the main DODAG to the Root. It is a request to establish or refresh a Track where the node sending the P-DAO-REQ is the Track ingress, and it signals whether or not an acknowledgment called PDR-ACK is requested. A positive PDR-ACK indicates that the Track was built and that the Root commits to maintaining the Track for the negotiated lifetime.
P-DAO-REQ メッセージは、メイン DODAG 内のノードによってルートに送信されます。これは、P-DAO-REQ を送信するノードがトラック入口であるトラックを確立またはリフレッシュするための要求であり、PDR-ACK と呼ばれる確認応答が要求されているかどうかを通知します。肯定的な PDR-ACK は、トラックが構築され、ルートがネゴシエートされた有効期間にわたってトラックを維持することを約束することを示します。
The main Root MAY indicate to the Track ingress that the Track was terminated before its time; to do so, it MUST use an asynchronous PDR-ACK with a negative status. A status of "Transient Failure" (see Section 11.10) is an indication that the P-DAO-REQ may be retried after a reasonable time that depends on the deployment. Other negative status values indicate a permanent error; the attempt must be abandoned until a corrective action is taken at the application layer or through network management.
メインルートは、トラックがその時間より前に終了したことをトラック入口に示してもよい(MAY)。そのためには、否定ステータスの非同期 PDR-ACK を使用しなければなりません (MUST)。「一時的な障害」のステータス (セクション 11.10 を参照) は、展開に応じて適切な時間が経過した後に P-DAO-REQ が再試行される可能性があることを示します。その他の負のステータス値は永続的なエラーを示します。アプリケーション層またはネットワーク管理を通じて修正措置が取られるまで、この試みは中止される必要があります。
The Track ingress to be of the requested Track is indicated in the source IPv6 address of the P-DAO-REQ, and the TrackID is indicated in the message itself. At least one RPL Target Option MUST be present in the message. If more than one RPL Target Option is present, the Root will provide a Track that reaches the first listed Target and a subset of the other Targets; the details of the subset selection are out of scope. The RTO signals the Track egress (see more in Section 6.2).
要求されたトラックのトラック イングレスは、P-DAO-REQ のソース IPv6 アドレスで示され、TrackID はメッセージ自体で示されます。少なくとも 1 つの RPL ターゲット オプションがメッセージ内に存在する必要があります。複数の RPL ターゲット オプションが存在する場合、ルートは最初にリストされたターゲットと他のターゲットのサブセットに到達するトラックを提供します。サブセット選択の詳細は範囲外です。RTO はトラック出力に信号を送ります (セクション 6.2 を参照)。
The RPL Control Code for the P-DAO-REQ is 0x09. The format of the P-DAO-REQ Base Object is as follows:
P-DAO-REQ の RPL 制御コードは 0x09 です。P-DAO-REQ ベース オブジェクトの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|R| Flags | ReqLifetime | PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 13: New P-DAO Request Format
図 13: 新しい P-DAO リクエスト形式
TrackID:
トラックID:
8-bit field. In the context of this specification, the TrackID field signals the RPLInstanceID of the DODAG formed by the Track; see Sections 3.4 and 6.3. To allocate a new Track, the ingress Node must provide a value that is not in use at this time.
8ビットフィールド。この仕様の文脈では、TrackID フィールドは、Track によって形成された DODAG の RPLInstanceID を通知します。セクション 3.4 および 6.3 を参照してください。新しいトラックを割り当てるには、入力ノードは現時点では使用されていない値を提供する必要があります。
K:
K:
The 'K' flag is set to indicate that the recipient is expected to send a PDR-ACK back.
「K」フラグは、受信者が PDR-ACK を返信することが期待されていることを示すために設定されます。
R:
R:
The 'R' flag is set to request a Complex Track for redundancy.
「R」フラグは、冗長性のために複雑なトラックを要求するために設定されます。
Flags:
フラグ:
Reserved. The Flags field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済み。Flags フィールドは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
ReqLifetime:
要求寿命:
8-bit unsigned integer. The requested lifetime for the Track expressed in Lifetime Units (obtained from the DODAG Configuration option). The value of 255 (0xFF) represents infinity (never time out).
8 ビットの符号なし整数。ライフタイム単位で表されるトラックの要求されたライフタイム (DODAG 構成オプションから取得)。値 255 (0xFF) は無限 (タイムアウトしない) を表します。
A P-DAO-REQ with a fresher PDRSequence refreshes the lifetime, and a ReqLifetime of 0 indicates that the Track MUST be destroyed, e.g., when the application that requested the Track terminates.
より新しい PDRSequence を持つ P-DAO-REQ はライフタイムをリフレッシュし、ReqLifetime が 0 の場合は、トラックを要求したアプリケーションが終了するときなどに、トラックを破棄しなければならないことを示します。
PDRSequence:
PDRシーケンス:
8-bit wrapping sequence number, obeying the operation in Section 7.2 of [RPL]. The PDRSequence is used to correlate a PDR-ACK message with the P-DAO-REQ message that triggered it. It is incremented at each P-DAO-REQ message and echoed in the PDR-ACK by the Root.
[RPL] のセクション 7.2 の操作に従う 8 ビットのラッピング シーケンス番号。PDRSequence は、PDR-ACK メッセージを、それをトリガーした P-DAO-REQ メッセージと関連付けるために使用されます。これは、P-DAO-REQ メッセージごとにインクリメントされ、ルートによって PDR-ACK でエコーされます。
The new PDR-ACK is sent as a response to a P-DAO-REQ message with the 'K' flag set. The RPL Control Code for the PDR-ACK is 0x0A. Its format is as follows:
新しい PDR-ACK は、「K」フラグが設定された P-DAO-REQ メッセージへの応答として送信されます。PDR-ACK の RPL 制御コードは 0x0A です。その形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID | Flags | Track Lifetime| PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDR-ACK Status| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+
Figure 14: New PDR-ACK Control Message Format
図 14: 新しい PDR-ACK 制御メッセージ フォーマット
TrackID:
トラックID:
Set to the TrackID indicated in the TrackID field of the P-DAO-REQ messages that this replies to.
これが応答する P-DAO-REQ メッセージの TrackID フィールドに示されている TrackID に設定します。
Flags:
フラグ:
Reserved. The Flags field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済み。Flags フィールドは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
Track Lifetime:
トラックの有効期間:
Indicates the remaining lifetime for the Track, expressed in Lifetime Units. The value of 255 (0xFF) represents infinity. The value of zero (0x00) indicates that the Track was destroyed or not created.
トラックの残りの寿命をライフタイム単位で示します。値 255 (0xFF) は無限大を表します。値ゼロ (0x00) は、トラックが破棄されたか、作成されなかったことを示します。
PDRSequence:
PDRシーケンス:
8-bit wrapping sequence number. It is incremented at each P-DAO-REQ message and echoed in the PDR-ACK.
8 ビットのラッピング シーケンス番号。これは、P-DAO-REQ メッセージごとに増分され、PDR-ACK でエコーされます。
PDR-ACK Status:
PDR-ACK ステータス:
8-bit field indicating the completion. The PDR-ACK Status is substructured as indicated in Figure 15:
完了を示す 8 ビットのフィールド。PDR-ACK ステータスは、図 15 に示すようにサブ構造化されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|E|R| Value |
+-+-+-+-+-+-+-+-+
Figure 15: PDR-ACK Status Format
図 15: PDR-ACK ステータスのフォーマット
E:
E:
1-bit flag. Set to indicate a rejection. When not set, a Value field that is set to 0 indicates Success/Unqualified Acceptance, and other values indicate "not an outright rejection".
1ビットのフラグ。拒否を示すように設定します。設定されていない場合、0 に設定された値フィールドは成功/無条件の受け入れを示し、その他の値は「完全な拒否ではない」ことを示します。
R:
R:
1-bit flag. Reserved; MUST be set to 0 by the sender and MUST be ignored by the receiver.
1ビットのフラグ。予約済み;送信者は 0 に設定しなければならず、受信者は無視しなければなりません。
Status Value:
ステータス値:
6-bit unsigned integer. Values depend on the setting of the 'E' flag; see Tables 28 and 29.
6 ビットの符号なし整数。値は「E」フラグの設定によって異なります。表 28 と 29 を参照してください。
Reserved:
予約済み：
The Reserved field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Reserved フィールドは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
A VIO signals the ordered list of IPv6 Via Addresses that constitutes the hops of either a protection path (using Non-Storing Mode) or a segment (using Storing Mode) of a Track. A Storing Mode P-DAO contains one SM-VIO whereas a Non-Storing Mode P-DAO contains one NSM-VIO.
VIO は、トラックの保護パス (非保存モードを使用) またはセグメント (保存モードを使用) のホップを構成する IPv6 経由アドレスの順序付きリストを通知します。保存モード P-DAO には 1 つの SM-VIO が含まれ、非保存モード P-DAO には 1 つの NSM-VIO が含まれます。
The duration of the validity of a VIO is indicated in a Segment Lifetime field. A P-DAO message that contains a VIO with a Segment Lifetime of 0 is referred as a No-Path P-DAO.
VIO の有効期間は、Segment Lifetime フィールドに示されます。セグメント ライフタイムが 0 の VIO を含む P-DAO メッセージは、パスなし P-DAO と呼ばれます。
The VIO contains one or more SRH-6LoRH headers, each formed of an SRH-6LoRH head and a collection of compressed Via Addresses, except in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH header is not present.
VIO には 1 つ以上の SRH-6LoRH ヘッダーが含まれており、それぞれは SRH-6LoRH ヘッダーと圧縮された Via アドレスの集合で構成されます。ただし、SRH-6LoRH ヘッダーが存在しない非保存モードのパスなし P-DAO の場合は除きます。
In the case of an SM-VIO, or if [RFC8138] is not used in the data packets, then the Root MUST use only one SRH-6LoRH per Via Information Option, and the compression is the same for all the addresses, as shown in Figure 16, for simplicity.
SM-VIO の場合、またはデータ パケットで [RFC8138] が使用されていない場合、ルートは経由情報オプションごとに SRH-6LoRH を 1 つだけ使用しなければなりません (MUST)。簡略化のため、図 16 に示すように、圧縮はすべてのアドレスで同じになります。
In case of an NSM-VIO, and if [RFC8138] is in use in the main DODAG, the Root SHOULD optimize the size of the NSM-VIO if using different SRH-6LoRH Types would make the VIO globally shorter; this means that more than one SRH-6LoRH may be present.
NSM-VIO の場合、および [RFC8138] がメイン DODAG で使用されている場合、異なる SRH-6LoRH タイプを使用すると VIO が全体的に短くなる場合、ルートは NSM-VIO のサイズを最適化する必要があります (SHOULD)。これは、複数の SRH-6LoRH が存在する可能性があることを意味します。
The format of the VIO is as follows:
VIO の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Flags | P-RouteID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seg. Sequence | Seg. Lifetime | SRH-6LoRH head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Via Address 1 (compressed by RFC 8138) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Via Address n (compressed by RFC 8138) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Additional SRH-6LoRH header(s) .
| |
. .... .
Figure 16: VIO Format
図 16: VIO フォーマット
Option Type:
オプションの種類:
0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26).
SM-VIO の場合は 0x0F、NSM-VIO の場合は 0x10 (表 26 を参照)。
Option Length:
オプションの長さ:
8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields (see Section 6.7.1 of [RPL]); the Option Length is variable, depending on the number of Via Addresses and the compression applied.
オプションの長さをオクテット単位で表す 8 ビットの符号なし整数。オプション タイプおよび長さフィールドは含まれません ([RPL] のセクション 6.7.1 を参照)。オプションの長さは、ビア アドレスの数と適用される圧縮に応じて変化します。
Flags:
フラグ:
8-bit field. No flag is defined in this specification. The field MUST be set to 0 by the sender and MUST be ignored by the receiver.
8ビットフィールド。この仕様ではフラグは定義されていません。このフィールドは送信者によって 0 に設定されなければならず、受信者によって無視されなければなりません。
P-RouteID:
P ルート ID:
8-bit field that identifies a component of a Track or the main DODAG as indicated by the TrackID field. The value of 0 is used to signal a path, i.e., made of a single segment/protection path. In an SM-VIO, the P-RouteID indicates a SegmentID. In an NSM-VIO, it indicates the ID of a protection path that is added (or updated) to the overall topology of the Track.
TrackID フィールドで示されるトラックまたはメイン DODAG のコンポーネントを識別する 8 ビット フィールド。値 0 は、パス、つまり単一のセグメント/保護パスで構成されるパスを通知するために使用されます。SM-VIO では、P-RouteID は SegmentID を示します。NSM-VIO では、トラックのトポロジー全体に追加 (または更新) される保護パスの ID を示します。
Segment Sequence:
セグメントシーケンス:
8-bit unsigned integer. The Segment Sequence obeys the operation in Section 7.2 of [RPL], and the initial value is 255.
8 ビットの符号なし整数。セグメントシーケンスは [RPL] のセクション 7.2 の操作に従い、初期値は 255 です。
When the Root of the DODAG needs to refresh or update a segment in a Track, it increments the Segment Sequence individually for that segment.
DODAG のルートがトラック内のセグメントをリフレッシュまたは更新する必要がある場合、そのセグメントのセグメント シーケンスを個別にインクリメントします。
The segment information indicated in the VIO deprecates any state for the segment indicated by the P-RouteID within the indicated Track and provides the new information about the segment.
VIO で示されるセグメント情報は、示された Track 内の P-RouteID で示されるセグメントの状態を廃止し、セグメントに関する新しい情報を提供します。
A VIO with a Segment Sequence that is not as fresh as the current one is ignored.
現在のセグメント シーケンスほど新しくないセグメント シーケンスを持つ VIO は無視されます。
A VIO for a given DODAGID with the same (TrackID, P-RouteID, Segment Sequence) indicates a retry; it MUST NOT change the segment and MUST be propagated or answered as the first copy.
同じ (TrackID、P-RouteID、Segment Sequence) を持つ特定の DODAGID の VIO は、再試行を示します。セグメントを変更してはならず、最初のコピーとして伝播または応答されなければなりません。
Segment Lifetime:
セグメントの存続期間:
8-bit unsigned integer. The length of time in Lifetime Units (obtained from the Configuration option) that the segment is usable.
8 ビットの符号なし整数。セグメントが使用可能な時間の長さ (ライフタイム単位) ([構成] オプションから取得)。
The period starts when a new Segment Sequence is seen. The value of 255 (0xFF) represents infinity. The value of zero (0x00) indicates a loss of reachability.
この期間は、新しいセグメント シーケンスが表示されたときに開始されます。値 255 (0xFF) は無限大を表します。値ゼロ (0x00) は、到達可能性が失われたことを示します。
SRH-6LoRH head:
SRH-6LoRHヘッド：
The first 2 bytes of the (first) SRH-6LoRH as shown in Figure 6 of [RFC8138]. As an example, a 6LoRH of type 4 means that the Via Addresses are provided in full with no compression.
[RFC8138] の図 6 に示されている、(最初の) SRH-6LoRH の最初の 2 バイト。たとえば、タイプ 4 の 6LoRH は、ビア アドレスが圧縮なしで完全に提供されることを意味します。
Via Address:
経由アドレス:
An IPv6 ULA or GUA of a node along the segment. The VIO contains one or more IPv6 Via Addresses listed in the datapath order from ingress to egress. The list is expressed in a compressed form as signaled by the preceding SRH-6LoRH header.
セグメント上のノードの IPv6 ULA または GUA。VIO には、入力から出力までのデータパスの順序でリストされた 1 つ以上の IPv6 経由アドレスが含まれています。リストは、先行する SRH-6LoRH ヘッダーによって通知される圧縮形式で表現されます。
In a Storing Mode P-DAO that updates or removes a section of an already existing segment, the list in the SM-VIO may represent only the section of the segment that is being updated; at the extreme, the SM-VIO updates only one node, in which case it contains only one IPv6 address. In all other cases, the list in the VIO MUST be complete.
既存のセグメントのセクションを更新または削除する保存モード P-DAO では、SM-VIO 内のリストは、更新されるセグメントのセクションのみを表す場合があります。極端な場合、SM-VIO は 1 つのノードのみを更新します。この場合、SM-VIO には 1 つの IPv6 アドレスのみが含まれます。それ以外の場合はすべて、VIO 内のリストが完全である必要があります。
In the case of an SM-VIO, the list indicates a sequential (strict) path through direct neighbors; the complete list starts at the ingress and ends at the egress, and the nodes listed in the VIO, including the egress, MAY be considered as implicit Targets.
SM-VIO の場合、リストは直接の隣接ノードを通る順次 (厳密な) パスを示します。完全なリストは入口で始まり出口で終わり、出口を含む VIO にリストされたノードは暗黙的なターゲットとみなされてもよい(MAY)。
In the case of an NSM-VIO, the complete list can be loose and excludes the ingress node, starting at the first loose hop and ending at a Track egress; the Track egress MUST be considered as an implicit Target, so it MUST NOT be signaled in a RPL Target Option.
NSM-VIO の場合、完全なリストはルーズになる可能性があり、最初のルーズ ホップから開始してトラック出力で終了するイングレス ノードが除外されます。トラック出力は暗黙的なターゲットとして考慮されなければならないため、RPL ターゲット オプションで通知されてはなりません (MUST NOT)。
The Sibling Information Option (SIO) provides information about siblings that could be used by the Root to form P-Routes. One or more SIOs may be placed in the DAO messages that are sent to the Root in Non-Storing Mode.
兄弟情報オプション (SIO) は、ルートが P ルートを形成するために使用できる兄弟に関する情報を提供します。非保存モードでルートに送信される DAO メッセージに 1 つ以上の SIO を配置できます。
To advertise a neighbor node, the router MUST have an active Address Registration from that sibling per [RFC8505] for an address (ULA or GUA) that serves as an identifier for the node. If this router also registers an address to that sibling, and the link has similar properties in both directions, only the router with the lowest Interface ID in its registered address needs to report the SIO, with the 'B' flag set, and the Root will assume symmetry.
隣接ノードをアドバタイズするには、ルータは、ノードの識別子として機能するアドレス (ULA または GUA) について、[RFC8505] に従ってその兄弟からのアクティブなアドレス登録を持っていなければなりません (MUST)。このルータがその兄弟へのアドレスも登録しており、リンクが両方向で同様のプロパティを持っている場合、登録されたアドレスで最も小さいインターフェイス ID を持つルータのみが、「B」フラグを設定して SIO を報告する必要があり、ルートは対称性を想定します。
The SIO carries a flag (B) that is set when similar performance can be expected in both directions; this flag indicates to the routing that the information provided for one direction is valid for both. If the SIO is effectively received from both sides, then the 'B' flag MUST be ignored. The policy that describes the performance criteria and how they are asserted is out of scope. In the absence of an external protocol to assert the link quality, the flag SHOULD NOT be set.
SIO にはフラグ (B) があり、両方向で同様のパフォーマンスが期待できる場合に設定されます。このフラグは、一方向に提供された情報が両方の方向に有効であることをルーティングに示します。SIO が両方の側から効果的に受信された場合、「B」フラグは無視されなければなりません (MUST)。パフォーマンス基準とその主張方法を説明するポリシーは範囲外です。リンク品質をアサートする外部プロトコルがない場合、フラグを設定すべきではありません (SHOULD NOT)。
The format of the SIO is as follows:
SIO のフォーマットは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |S|B|Flags|Comp.| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Step in Rank | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Sibling DODAGID (if the D flag is not set) .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Sibling Address .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Sibling Information Option Format
図 17: 兄弟情報オプションの形式
Option Type:
オプションの種類:
0x11 for SIO (see Table 26).
SIO の場合は 0x11 (表 26 を参照)。
Option Length:
オプションの長さ:
8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields (see Section 6.7.1 of [RPL]).
オプションの長さをオクテット単位で表す 8 ビットの符号なし整数。オプション タイプおよび長さフィールドは含まれません ([RPL] のセクション 6.7.1 を参照)。
Reserved for Flags:
フラグ用に予約されています:
MUST be set to 0 by the sender and MUST be ignored by the receiver.
送信者は 0 に設定しなければならず、受信者は無視しなければなりません。
B:
B:
1-bit flag that is set to indicate that the connectivity to the sibling is bidirectional and roughly symmetrical. In that case, only one of the siblings needs to report the SIO for the hop. If 'B' is not set, then the SIO only indicates connectivity from the sibling to this node, and it does not provide information on the hop from this node to the sibling.
兄弟への接続が双方向でほぼ対称であることを示すために設定される 1 ビットのフラグ。その場合、兄弟のうち 1 つだけがホップの SIO を報告する必要があります。「B」が設定されていない場合、SIO は兄弟からこのノードへの接続のみを示し、このノードから兄弟へのホップに関する情報は提供しません。
S:
S:
1-bit flag that is set to indicate that the sibling belongs to the same DODAG. When not set, the Sibling DODAGID is indicated.
兄弟が同じ DODAG に属していることを示すために設定される 1 ビットのフラグ。設定されていない場合は、兄弟 DODAGID が示されます。
Flags:
フラグ:
Reserved. The Flags field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済み。Flags フィールドは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
Comp.:
比較:
Compression Type; a 3-bit unsigned integer. This is the SRH-6LoRH Type as defined in Figure 7 in Section 5.1 of [RFC8138] that corresponds to the compression used for the Sibling Address and its DODAGID if present. The Compression reference is the Root of the main DODAG.
圧縮タイプ。3 ビットの符号なし整数。これは、[RFC8138] のセクション 5.1 の図 7 で定義されている SRH-6LoRH タイプで、兄弟アドレスとその DODAGID (存在する場合) に使用される圧縮に対応します。圧縮参照は、メイン DODAG のルートです。
Opaque:
不透明:
MAY be used to carry information that the node and the Root understand, e.g., a particular representation of the link properties such as a proprietary Link Quality Information for packets received from the sibling. In some scenarios such as Industrial Alliances that use RPL for a particular use/ environment, this field MAY be redefined to fit the needs of the case.
ノードとルートが理解する情報、例えば、兄弟から受信したパケットの独自のリンク品質情報などのリンクプロパティの特定の表現を運ぶために使用されてもよい(MAY)。特定の用途/環境に RPL を使用する産業同盟などの一部のシナリオでは、このフィールドはケースのニーズに合わせて再定義してもよい(MAY)。
Step in Rank:
ランクインステップ:
16-bit unsigned integer. This is the Step in Rank [RPL] as computed by the Objective Function between this node and the sibling, which reflects the abstract Rank increment that would be computed by the Objective Function if the sibling was the preferred parent.
16 ビットの符号なし整数。これは、このノードと兄弟の間の目的関数によって計算されたランクのステップ [RPL] であり、兄弟が優先親である場合に目的関数によって計算される抽象的なランク増分を反映します。
Reserved:
予約済み：
The Reserved field MUST be initialized to zero by the sender and MUST be ignored by the receiver
予約フィールドは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
Sibling DODAGID:
兄弟の DODAGID:
2 to 16 bytes. The DODAGID of the sibling in a compressed form [RFC8138] as indicated by the Compression Type field. This field is present if and only if the 'D' flag is not set.
2～16バイト。Compression Type フィールドで示される圧縮形式 [RFC8138] の兄弟の DODAGID。このフィールドは、「D」フラグが設定されていない場合にのみ存在します。
Sibling Address:
兄弟のアドレス:
2 to 16 bytes. An IPv6 address of the sibling with a scope that MUST make it reachable from the Root, e.g., it cannot be a Link Local Address. The IPv6 address is encoded in the compressed form [RFC8138] indicated by the Compression Type field.
2～16バイト。ルートから到達可能にしなければならないスコープを持つ兄弟の IPv6 アドレス。たとえば、リンク ローカル アドレスであってはなりません。IPv6 アドレスは、Compression Type フィールドで示される圧縮形式 [RFC8138] でエンコードされます。
An SIO MAY be immediately followed by a DAG Metric Container. In that case, the DAG Metric Container provides additional metrics for the hop from the Sibling to this node.
SIO の直後に DAG メトリック コンテナが続いてもよい (MAY)。その場合、DAG メトリック コンテナーは、兄弟からこのノードへのホップに追加のメトリックを提供します。
To avoid the need of Path MTU Discovery by 6LoWPAN endpoints, 6LoWPAN links are normally defined with an MTU of 1280 (see Section 4 of [6LoWPAN]). Injecting packets in a Track typically involves an IP-in-IP encapsulation and additional IPv6 extension headers. This may cause fragmentation if the resulting packets exceed the MTU that is defined for the RPL domain.
6LoWPAN エンドポイントによるパス MTU 検出の必要性を回避するために、6LoWPAN リンクは通常 1280 の MTU で定義されます ([6LoWPAN] のセクション 4 を参照)。トラックへのパケットの挿入には、通常、IP-in-IP カプセル化と追加の IPv6 拡張ヘッダーが含まれます。これにより、結果のパケットが RPL ドメインに定義されている MTU を超えると断片化が発生する可能性があります。
Though fragmentation is possible in a 6LoWPAN LLN, e.g., using [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to define an MTU that is larger than 1280 between the RPL routers that form the main DODAG to allow for the necessary header additions, while still exposing 1280 to the 6LoWPAN endpoint stacks.
6LoWPAN LLN では、[6LoWPAN]、[RFC8930]、[RFC8931] などを使用して断片化が可能ですが、6LoWPAN エンドポイント スタックに 1280 を公開しながら、必要なヘッダーの追加を可能にするために、メイン DODAG を形成する RPL ルーター間で 1280 より大きい MTU を定義することが推奨されます。
This specification introduces the P-DAO-REQ message, which is used by an LLN node to request the formation of a new Track for which the LLN node is the ingress. Note that the namespace for the TrackID is owned by the ingress node, and in the absence of a P-DAO-REQ, there must be some procedure for the Root to assign TrackIDs in that namespace while avoiding collisions (see more in Section 6.3).
この仕様では、LLN ノードが入口となる新しいトラックの形成を要求するために LLN ノードによって使用される P-DAO-REQ メッセージが導入されています。TrackID の名前空間は入口ノードによって所有されており、P-DAO-REQ がない場合、ルートが衝突を回避しながらその名前空間に TrackID を割り当てるための何らかの手順が必要であることに注意してください (詳細はセクション 6.3 を参照)。
The P-DAO-REQ signals the desired TrackID and the duration for which the Track should be established. Upon a P-DAO-REQ, the Root MAY install the Track as requested, in which case it answers with a PDR-ACK indicating the granted Track Lifetime. All the segments MUST be of the same mode, either Storing or Non-Storing. All the segments MUST be created with the same TrackID and the same DODAGID signaled in the P-DAO.
P-DAO-REQ は、必要な TrackID と、トラックが確立される必要がある期間を通知します。P-DAO-REQ の際、ルートは要求どおりにトラックをインストールしてもよい (MAY)。その場合、許可されたトラックの有効期間を示す PDR-ACK で応答する。すべてのセグメントは、保存または非保存の同じモードでなければなりません。すべてのセグメントは、P-DAO で通知される同じ TrackID と同じ DODAGID を使用して作成されなければなりません (MUST)。
The Root designs the Track as it sees fit and updates/changes the segments over time to serve the Track as needed. Note that there is no protocol element to notify the requesting Track ingress when changes happen deeper down the Track, so they are transparent to the Track ingress. If the main Root cannot maintain an expected service level, then it needs to tear down the Track completely. The Segment Lifetime in the P-DAO messages does not need to be aligned to the Requested Lifetime in the P-DAO-REQ or between P-DAO messages for different segments. For example, the Root may use shorter lifetimes for the segments and renew them or change them during the lifetime of the Track. All the components (protection paths and segments) of a Track MUST be destroyed (or have their lifetime elapsed) before the TrackID can be reused.
ルートは、必要に応じてトラックを設計し、時間の経過とともにセグメントを更新/変更して、必要に応じてトラックを提供します。トラックのより深いところで変更が発生した場合に、要求元のトラック入力に通知するプロトコル要素がないため、変更はトラック入力に対して透過的であることに注意してください。メインのルートが期待されるサービス レベルを維持できない場合は、トラックを完全に破棄する必要があります。P-DAO メッセージのセグメント ライフタイムは、P-DAO-REQ または異なるセグメントの P-DAO メッセージ間のリクエスト ライフタイムに合わせる必要はありません。たとえば、ルートはセグメントに短い存続期間を使用し、トラックの存続期間中にそれらを更新または変更することができます。TrackID を再利用する前に、Track のすべてのコンポーネント (保護パスとセグメント) を破棄する (または有効期間が経過する) 必要があります。
When the Track Lifetime is relatively close to elapse -- meaning in the order of the trip time from the node to the Root -- the requesting node SHOULD resend a P-DAO-REQ using the TrackID in the PDR-ACK to extend the lifetime of the Track; otherwise, the Track will time out, and the Root will tear down the whole structure.
トラックの存続期間が経過に比較的近い場合、つまりノードからルートまでのトリップ時間の順序で、要求側ノードはトラックの存続期間を延長するために、PDR-ACK 内の TrackID を使用して P-DAO-REQ を再送信する必要があります (SHOULD)。そうしないと、トラックがタイムアウトになり、ルートが構造全体を破壊します。
If the Track fails and cannot be restored, the Root notifies the requesting node asynchronously with a PDR-ACK with a Track Lifetime of 0, indicating that the Track has failed, and a PDR-ACK Status, indicating the reason of the fault.
トラックに障害が発生して復元できない場合、ルートは、トラックのライフタイムが 0 の PDR-ACK (トラックの障害が発生したことを示す) と PDR-ACK ステータス (障害の理由を示す) を要求側ノードに非同期で通知します。
RPL defines the concept of an Instance to signal an individual routing topology, and multiple topologies can coexist in the same network. The RPLInstanceID is tagged in the RPI of every packet to signal which topology the packet actually follows.
RPL は、個々のルーティング トポロジを通知するインスタンスの概念を定義し、複数のトポロジが同じネットワーク内に共存できます。RPLInstanceID は各パケットの RPI でタグ付けされ、パケットが実際にどのトポロジに従っているかを示します。
This specification leverages the RPL Instance model as follows:
この仕様は、次のように RPL インスタンス モデルを利用します。
* The main Root MAY use P-DAO messages to add better routes in the main Instance in conformance with the routing objectives in that Instance.
* メインルートは、P-DAO メッセージを使用して、そのインスタンスのルーティング目標に従ってメインインスタンスにより良いルートを追加してもよい(MAY)。
To achieve this, the main Root MAY install a segment along a path down the main DODAG, which is operated in Non-Storing Mode. This enables loose source routing and reduces the size of the Routing Header; see Section 3.3.1. The main Root MAY also install a protection path across the main DODAG to complement the routing topology.
これを達成するために、メイン ルートは、非保存モードで動作するメイン DODAG の下のパスに沿ってセグメントをインストールしてもよい(MAY)。これにより、緩やかなソース ルーティングが可能になり、ルーティング ヘッダーのサイズが削減されます。セクション 3.3.1 を参照してください。メイン ルートは、ルーティング トポロジを補完するために、メイン DODAG を横切る保護パスをインストールしてもよい (MAY)。
When adding a P-Route to the RPL main DODAG, the main Root MUST set the RPLInstanceID field of the P-DAO Base Object (see Section 6.4.1 of [RPL]) to the RPLInstanceID of the main DODAG, and it MUST NOT use the DODAGID field. A P-Route provides a longer match to the Target Address than the default route via the main Root, so it is preferred.
P-Route を RPL メイン DODAG に追加する場合、メイン ルートは P-DAO Base Object ([RPL] のセクション 6.4.1 を参照) の RPLInstanceID フィールドをメイン DODAG の RPLInstanceID に設定しなければならず (MUST)、DODAGID フィールドを使用してはなりません (MUST NOT)。P ルートは、メイン ルート経由のデフォルト ルートよりもターゲット アドレスとの一致が長くなるため、優先されます。
* The main Root MAY also use P-DAO messages to install a Track as an independent routing topology (say, Traffic Engineered) to achieve particular routing characteristics from ingress to egress endpoints. To achieve this, the main Root MUST set up a Local RPL Instance (see Section 5 of [RPL]), and the Local RPLInstanceID serves as the TrackID. The TrackID MUST be unique for the IPv6 ULA or GUA of the Track ingress that serves as the DODAGID for the Track.
* メイン ルートは、P-DAO メッセージを使用して、独立したルーティング トポロジ (トラフィック エンジニアリングなど) としてトラックをインストールし、入力エンドポイントから出力エンドポイントまでの特定のルーティング特性を実現することもできます (MAY)。これを達成するには、メインルートはローカル RPL インスタンスをセットアップしなければなりません ([RPL] のセクション 5 を参照)。ローカル RPLInstanceID は TrackID として機能します。TrackID は、トラックの DODAGID として機能するトラック入力の IPv6 ULA または GUA に対して一意でなければなりません。
This way, a Track is uniquely identified by the tuple (DODAGID, TrackID) where the TrackID is always represented with the 'D' flag set to 0 (see also Section 5.1 of [RPL]), indicating that when used in an RPI, the source address of the IPv6 packet signals the DODAGID.
このように、トラックはタプル (DODAGID, TrackID) によって一意に識別されます。ここで、TrackID は常に 0 に設定された「D」フラグで表されます ([RPL] のセクション 5.1 も参照)。これは、RPI で使用される場合、IPv6 パケットの送信元アドレスが DODAGID を通知することを示します。
The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) that identifies the Track as shown in Figure 8, and the P-RouteID that identifies the P-Route MUST be signaled in the VIO as shown in Figure 16.
P-DAO ベース オブジェクトは、図 8 に示すように、トラックを識別するタプル (DODAGID、TrackID) を示さなければならず、図 16 に示すように、P-Route を識別する P-RouteID が VIO でシグナリングされなければなりません (MUST)。
The Track ingress is the Root of the DODAGID formed by the Local RPL Instance. It owns the namespace of its TrackIDs, so it can pick any unused value to request a new Track with a P-DAO-REQ. In a particular deployment where P-DAO-REQs are not used, a portion of the namespace can be administratively delegated to the main Root, meaning that the main Root is authoritative for assigning the TrackIDs for the Tracks it creates.
Track ingress は、ローカル RPL インスタンスによって形成された DODAGID のルートです。TrackID の名前空間を所有しているため、未使用の値を選択して、P-DAO-REQ で新しいトラックを要求できます。P-DAO-REQ が使用されない特定の展開では、ネームスペースの一部をメイン ルートに管理的に委任できます。これは、メイン ルートが、作成するトラックに TrackID を割り当てる権限を持っていることを意味します。
With this specification, the main Root is aware of all the active Tracks, so it can also pick any unused value to form Tracks without a P-DAO-REQ. To avoid a collision of the main Root and the Track ingress picking the same value at the same time, it is RECOMMENDED that the Track ingress starts allocating the ID value of the Local RPLInstanceID (see Section 5.1 of [RPL]) used as TrackIDs with the value 0 incrementing, while the Root starts with 63 decrementing.
この仕様では、メインのルートはすべてのアクティブなトラックを認識しているため、P-DAO-REQ なしで未使用の値を選択してトラックを形成することもできます。メインルートとトラックイングレスが同時に同じ値を選択する衝突を避けるために、トラックイングレスは値 0 を増分してトラック ID として使用されるローカル RPLInstanceID ([RPL] のセクション 5.1 を参照) の ID 値の割り当てを開始し、ルートは 63 を減分して開始することが推奨されます。
A path can be installed by a single P-Route that signals the sequence of consecutive nodes either in Storing Mode as a single-segment Track or in Non-Storing Mode as a single-protection-path Track. A single-protection-path Track can be installed as a loose Non-Storing Mode P-Route, in which case the next loose entry must recursively be reached over a path.
パスは、単一セグメント トラックとしてのストレージ モード、または単一保護パス トラックとしての非ストレージ モードのいずれかで、連続するノードのシーケンスを信号で伝える単一の P ルートによってインストールできます。単一保護パス トラックは、ルーズな非保存モード P ルートとしてインストールできます。この場合、パスを介して次のルーズ エントリに再帰的に到達する必要があります。
A Complex Track can be installed as a collection of P-Routes with the same DODAGID and TrackID. The ingress of a Non-Storing Mode P-Route is the owner and Root of the DODAGID. The ingress of a Storing Mode P-Route must be either the owner of the DODAGID or a hop of a protection path of the same Track. In the latter case, the Targets of the P-Route must include the next hop of the protection path if there is one to ensure forwarding continuity. In the case of a Complex Track, each segment is maintained independently and asynchronously by the Root, with its own lifetime that may be shorter, the same, or longer than that of the Track.
Complex Track は、同じ DODAGID と TrackID を持つ P-Route のコレクションとしてインストールできます。非保存モード P-Route の入口は、DODAGID の所有者およびルートです。保存モード P ルートの入口は、DODAGID の所有者であるか、同じトラックの保護パスのホップである必要があります。後者の場合、転送の継続性を確保するために、P ルートのターゲットには、保護パスのネクスト ホップが存在する場合にはそれを含める必要があります。複雑なトラックの場合、各セグメントはルートによって独立して非同期に維持され、その独自の存続期間はトラックの存続期間よりも短い、同じ、または長い場合があります。
A route along a Track for which the TrackID is not the RPLInstanceID of the main DODAG MUST be installed with a higher precedence than the routes along the main DODAG, meaning that:
TrackID がメイン DODAG の RPLInstanceID ではないトラックに沿ったルートは、メイン DODAG に沿ったルートよりも高い優先順位でインストールされなければなりません (MUST)。これは以下のことを意味します。
* The longest match MUST be the prime comparison for routing.
* 最長一致がルーティングの主な比較でなければなりません。
* For an equal-length match, the route along the Track MUST be preferred over the one along the main DODAG.
* 等しい長さの一致の場合、トラックに沿ったルートがメイン DODAG に沿ったルートよりも優先されなければなりません (MUST)。
* There SHOULD NOT be two different Tracks leading to the same Target from same ingress node, unless there's a policy for selecting which packets use which Track; such a policy is out of scope.
* どのパケットがどのトラックを使用するかを選択するポリシーがない限り、同じ入口ノードから同じターゲットにつながる 2 つの異なるトラックがあってはなりません。そのようなポリシーは範囲外です。
* A packet that was routed along a Track MUST NOT be routed along the main DODAG again; if the destination is not reachable as a neighbor by the node where the packet exits the Track, then the packet MUST be dropped.
* トラックに沿ってルーティングされたパケットは、メイン DODAG に再び沿ってルーティングされてはなりません (MUST NOT)。パケットがトラックから出るノードによって宛先が隣接ノードとして到達できない場合、パケットはドロップされなければなりません(MUST)。
This specification adds a capability whereby the Root of a main DODAG installs a Track as a collection of P-Routes, using a P-DAO message for each individual protection path or segment. The P-DAO signals a collection of Targets in one or more RTOs. Those Targets can be reached via a sequence of routers indicated in a VIO.
この仕様は、メイン DODAG のルートが、個々の保護パスまたはセグメントごとに P-DAO メッセージを使用して、P-Route のコレクションとしてトラックをインストールする機能を追加します。P-DAO は、1 つ以上の RTO 内のターゲットのコレクションを通知します。これらのターゲットには、VIO で示された一連のルーターを介して到達できます。
Like a classical DAO message, a P-DAO causes a change of state only if it is "new" per Section 9.2.2 ("Generation of DAO Messages") of the RPL specification [RPL]; this is determined using the Segment Sequence information from the VIO as opposed to the Path Sequence from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that the P-Route associated to the segment is to be removed. There are two Modes of operation for the P-Routes: Storing and Non-Storing.
古典的な DAO メッセージと同様に、P-DAO は、RPL 仕様 [RPL] のセクション 9.2.2 (「DAO メッセージの生成」) に従って「新しい」場合にのみ状態の変化を引き起こします。これは、TIO からのパス シーケンスではなく、VIO からのセグメント シーケンス情報を使用して決定されます。また、VIO 内のセグメント ライフタイム 0 は、セグメントに関連付けられた P-Route が削除されることを示します。P ルートには、保存と非保存という 2 つの動作モードがあります。
A P-DAO message MUST be sent from the address of the Root that serves as the DODAGID for the main DODAG. It MUST contain either exactly one sequence of one or more RTOs followed by one VIO or any number of sequences of one or more RTOs followed by one or more TIOs. The former is the normal expression for this specification, whereas the latter corresponds to the variation for less-constrained environments described in Section 7.2.
P-DAO メッセージは、メイン DODAG の DODAGID として機能するルートのアドレスから送信されなければなりません (MUST)。これには、1 つ以上の RTO の後に 1 つの VIO が続くシーケンスが 1 つだけ含まれるか、または 1 つ以上の RTO の後に 1 つ以上の TIO が続く任意の数のシーケンスが含まれなければなりません (MUST)。前者はこの仕様の通常の表現であり、後者はセクション 7.2 で説明されている制約の少ない環境のバリエーションに対応します。
A P-DAO that creates or updates a protection path MUST be sent to a GUA or a ULA of the ingress of the protection path; it MUST contain the full list of hops in the protection path unless the protection path is being removed. A P-DAO that creates a new Track segment MUST be sent to a GUA or a ULA of the segment egress and MUST signal the full list of hops in a segment; a P-DAO that updates (including deletes) a section of a segment MUST be sent to the first node after the modified segment and MUST signal the full list of hops in the section starting at the node that immediately precedes the modified section.
保護パスを作成または更新する P-DAO は、保護パスの入口の GUA または ULA に送信されなければなりません (MUST)。保護パスが削除されない限り、保護パス内のホップの完全なリストを含める必要があります。新しいトラックセグメントを作成する P-DAO は、セグメント出口の GUA または ULA に送信されなければならず (MUST)、セグメント内のホップの完全なリストをシグナリングしなければなりません (MUST)。セグメントのセクションを更新（削除を含む）する P-DAO は、変更されたセグメントの後の最初のノードに送信されなければならず、変更されたセクションの直前のノードから始まるセクション内のホップの完全なリストをシグナリングしなければなりません（MUST）。
In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends the P-DAO to the Track ingress where the source routing state is applied, whereas in Storing Mode, the P-DAO is sent to the last node on the installed path and forwarded in the reverse direction, installing a Storing Mode state at each hop, as discussed in Section 6.4.2. In both cases, the Track ingress is the owner of the Track, and it generates the P-DAO-ACK when the installation is successful.
セクション 6.4.3 で説明したように、非ストレージ モードでは、ソース ルーティング ステートが適用されるトラック入口にルートが P-DAO を送信します。一方、ストレージ モードでは、セクション 6.4.2 で説明したように、P-DAO はインストールされたパス上の最後のノードに送信され、逆方向に転送され、各ホップにストレージ モード状態がインストールされます。どちらの場合も、トラック入力はトラックの所有者であり、インストールが成功すると P-DAO-ACK を生成します。
If the 'K' flag is present in the P-DAO, the P-DAO MUST be acknowledged using a P-DAO-ACK that is sent back to the address of the Root from which the P-DAO was received. In most cases, the first node of the protection path, segment, or updated section of the segment is the node that sends the acknowledgment. The exception to the rule is when an intermediate node in a segment fails to forward a Storing Mode P-DAO to the previous node in the SM-VIO.
P-DAO に「K」フラグが存在する場合、P-DAO の受信元のルートのアドレスに送り返される P-DAO-ACK を使用して P-DAO を確認しなければなりません (MUST)。ほとんどの場合、保護パス、セグメント、またはセグメントの更新されたセクションの最初のノードが確認応答を送信するノードです。このルールの例外は、セグメント内の中間ノードが SM-VIO 内の前のノードにストレージ モード P-DAO を転送できない場合です。
In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be present in the NSM-VIO; the state in the ingress is erased regardless. In all other cases, a VIO MUST contain at least one Via Address, and a Via Address MUST NOT be present more than once, which would create a loop.
パスなし非保存モード P-DAO では、SRH-6LoRH が NSM-VIO に存在してはなりません。入力側の状態は関係なく消去されます。それ以外の場合はすべて、VIO には少なくとも 1 つの Via アドレスが含まれていなければなりません。また、VIO アドレスが複数回存在してはなりません (ループが発生する可能性があります)。
A node that processes a VIO MAY verify whether any of these conditions happen, and when one does, it MUST ignore the P-DAO and reject it with a RPL rejection status of "Error in VIO" in the DAO-ACK; see Section 11.16.
VIO を処理するノードは、これらの条件のいずれかが発生するかどうかを検証してもよく (MAY)、発生した場合には、P-DAO を無視し、DAO-ACK 内の「VIO のエラー」という RPL 拒否ステータスで拒否しなければなりません (MUST)。セクション11.16を参照してください。
Errors, other than those discussed explicitly, that prevent the installation of the route are acknowledged with a RPL rejection status of "Unqualified Rejection" in the P-DAO-ACK.
明示的に説明されているエラー以外で、ルートのインストールを妨げるエラーは、P-DAO-ACK 内の「Unqualified Rejection」という RPL 拒否ステータスで確認されます。
As illustrated in Figure 18, a Storing Mode P-DAO installs a route along the segment signaled by the SM-VIO towards the Targets indicated in the Target Options. The segment is to be included in a DODAG indicated by the P-DAO Base Object, which may be the one formed by the main DODAG, or a Track associated with a Local RPL Instance.
図 18 に示すように、ストレージ モード P-DAO は、SM-VIO によって通知されたセグメントに沿って、ターゲット オプションで指定されたターゲットに向かうルートをインストールします。セグメントは、P-DAO ベース オブジェクトによって示される DODAG に含まれます。DODAG は、メイン DODAG によって形成されるもの、またはローカル RPL インスタンスに関連付けられたトラックである可能性があります。
------+---------
| Internet
|
+-----+
| | Border Router
| | (RPL Root)
+-----+ | P- ^ |
| | DAO | P-DAO-ACK |
o o o o | | |
o o o o Ingress o o o | ^ | Projected .
o o o o o \\ o o o | | P-DAO | Route .
o o o o \\ o o o o | ^ | .
o o o o o Egress o o v | P-DAO v .
o o LLN o o o |
o o o o o Loose Source Route Path |
o o o o v
Figure 18: Projecting a Route
図 18: ルートの投影
In order to install the relevant routing state along the segment, the Root sends a unicast P-DAO message to the Track egress router of the routing segment that is being installed. The P-DAO message contains an SM-VIO with a strict sequence of Via Addresses. The SM-VIO follows one or more RTOs indicating the Targets to which the Track leads. The SM-VIO contains a Segment Lifetime for which the state is to be maintained.
関連するルーティング状態をセグメントに沿ってインストールするために、ルートはユニキャスト P-DAO メッセージを、インストールされているルーティング セグメントのトラック出力ルーターに送信します。P-DAO メッセージには、厳密な順序の Via アドレスを持つ SM-VIO が含まれています。SM-VIO は、トラックが導くターゲットを示す 1 つ以上の RTO に従います。SM-VIO には、状態が維持されるセグメント ライフタイムが含まれています。
The Root sends the P-DAO directly to the egress node of the segment. In that P-DAO, the destination IP address matches the last Via Address in the SM-VIO. This is how the egress recognizes its role. In a similar fashion, the segment ingress node recognizes its role because it matches the first Via Address in the SM-VIO.
ルートは、P-DAO をセグメントの出力ノードに直接送信します。その P-DAO では、宛先 IP アドレスは SM-VIO の最後の Via アドレスと一致します。これは、出口がその役割を認識する方法です。同様に、セグメント入口ノードは、SM-VIO の最初の Via アドレスと一致するため、その役割を認識します。
The egress node of the segment is the only node in the path that does not install a route in response to the P-DAO; it is expected to be already able to route to the Target(s) based on its existing tables. If one of the Targets is not known, the node MUST answer to the Root with a P-DAO-ACK listing the unreachable Target(s) in an RTO and a rejection status of "Unreachable Target".
セグメントの出口ノードは、P-DAO に応答してルートをインストールしないパス内の唯一のノードです。既存のテーブルに基づいてターゲットにルーティングできることがすでに期待されています。いずれかのターゲットが不明な場合、ノードは RTO に到達不能なターゲットをリストした P-DAO-ACK と「到達不能なターゲット」の拒否ステータスでルートに応答しなければなりません (MUST)。
If the egress node can reach all the Targets, it forwards the P-DAO with unchanged content to its predecessor in the segment as indicated in the list of VIOs, and the message is recursively propagated unchanged along the sequence of routers indicated in the P-DAO, but in the reverse order, from egress to ingress.
出口ノードがすべてのターゲットに到達できる場合、VIO のリストに示されているように、内容が変更されていない P-DAO をセグメント内の先行ノードに転送します。メッセージは、P-DAO に示されている一連のルーターに沿って変更されずに、出口から入口まで逆の順序で再帰的に伝播されます。
The address of the predecessor to be used as the destination of the propagated DAO message is found in the Via Address list at the position preceding the one that contains the address of the propagating node, which is used as the source of the message.
伝播された DAO メッセージの宛先として使用される先行ノードのアドレスは、メッセージのソースとして使用される伝播ノードのアドレスを含むリストよりも前の位置にある Via Address リスト内で見つかります。
Upon receiving a propagated DAO, all except the egress router MUST install a route towards the DAO Target(s) via their successor in the SM-VIO. A router that cannot store the routes to all the Targets in a P-DAO MUST reject the P-DAO by sending a P-DAO-ACK to the Root with a rejection status of "Out of Resources" as opposed to forwarding the DAO to its predecessor in the list. The router MAY install additional routes towards the Via Addresses that appear in the SM-VIO after its own address, if any, but in case of a conflict or a lack of resource, the route(s) to the Target(s) MUST be installed in priority.
伝播された DAO を受信すると、出口ルータを除くすべてのルータは、SM-VIO の後続ルータを介して DAO ターゲットへのルートをインストールしなければなりません (MUST)。P-DAO 内のすべてのターゲットへのルートを保存できないルータは、DAO をリスト内の先行者に転送するのではなく、「リソース不足」という拒否ステータスでルートに P-DAO-ACK を送信することによって、P-DAO を拒否しなければなりません (MUST)。ルータは、SM-VIO 内で自身のアドレスの後に現れる Via アドレスへの追加ルートをインストールしてもよい (MAY)。ただし、競合またはリソース不足が発生した場合には、ターゲットへのルートを優先してインストールしなければならない (MUST)。
If a router cannot reach its predecessor in the SM-VIO, the router MUST send the P-DAO-ACK to the Root with a rejection status of "Predecessor Unreachable".
ルーターが SM-VIO 内の先行者に到達できない場合、ルーターは「先行者到達不能」という拒否ステータスを持つ P-DAO-ACK をルートに送信しなければなりません (MUST)。
The process continues until the P-DAO is propagated to the ingress router of the segment, which answers with a P-DAO-ACK to the Root. The Root always expects a P-DAO-ACK, either from the Track ingress with a positive status or from any node along the segment with a negative status. If the P-DAO-ACK is not received, the Root may retry the DAO with the same TrackID or tear down the route.
このプロセスは、P-DAO がセグメントの入口ルーターに伝播され、入口ルーターがルートに P-DAO-ACK で応答するまで続きます。ルートは常に、正のステータスのトラック入力から、または負のステータスのセグメントに沿った任意のノードからの P-DAO-ACK を期待します。P-DAO-ACK が受信されない場合、ルートは同じ TrackID で DAO を再試行するか、ルートを破棄する可能性があります。
As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a source-routed path within the Track indicated by the P-DAO Base Object towards the Targets indicated in the Target Options. The source-routed path requires a Source Routing Header, which implies an IP-in-IP encapsulation is needed to add the SRH to an existing packet. It is sent to the Track ingress, which creates a tunnel associated with the Track and connected routes over the tunnel to the Targets in the RTO. The tunnel encapsulation MUST incorporate a Routing Header via the list addresses listed in the VIO in the same order. The content of the NSM-VIO starting at the first SRH-6LoRH header MUST be used verbatim by the Track ingress when it encapsulates a packet to forward it over the Track.
図 19 に示すように、非保存モード P-DAO は、P-DAO ベース オブジェクトによって示されるトラック内に、ターゲット オプションで示されるターゲットに向かうソース ルーティング パスをインストールします。ソース ルーティング パスにはソース ルーティング ヘッダーが必要です。これは、SRH を既存のパケットに追加するために IP-in-IP カプセル化が必要であることを意味します。これはトラック入力に送信され、トラックに関連付けられたトンネルと、そのトンネルを介して RTO のターゲットに接続されたルートが作成されます。トンネルのカプセル化には、VIO に同じ順序でリストされたリスト アドレスを介してルーティング ヘッダーを組み込む必要があります。最初の SRH-6LoRH ヘッダーで始まる NSM-VIO の内容は、トラック上でパケットを転送するためにパケットをカプセル化するときに、トラック入力によってそのまま使用されなければなりません (MUST)。
------+---------
| Internet
|
+-----+
| | Border Router
| | (RPL Root)
+-----+ | P- ^ P-DAO-ACK
| Track | DAO |
o o o Ingress V |
o o o o o o X o X Source-
o o o o o o o X o o X Routed
o o o o o o X o X Segment
o o o o o o o o X X
Egress
o o o o o |
Target
o o LLN o
o o o o
Figure 19: Projecting a Non-Storing Route
図 19: 非保管ルートの投影
The next entry in the source-routed path must be either a neighbor of the previous entry or reachable as a Target via another P-Route, either Storing or Non-Storing, which implies that the nested P-Route has to be installed before the loose sequence is and that P-Routes must be installed from the last to the first along the datapath. For instance, a segment of a Track must be installed before the protection path(s) of the same Track that uses it, and stitched segments must be installed in order from the last to the first to reach the Targets.
ソース ルーティング パスの次のエントリは、前のエントリの隣接エントリであるか、別の P-Route (ストレージまたは非ストレージ) 経由でターゲットとして到達可能である必要があります。これは、ルーズ シーケンスの前にネストされた P-Route をインストールする必要があり、P-Route がデータパスに沿って最後から最初にインストールされる必要があることを意味します。たとえば、トラックのセグメントは、それを使用する同じトラックの保護パスより前にインストールする必要があり、ステッチされたセグメントは、ターゲットに到達するために最後から最初の順にインストールする必要があります。
If the next entry in the loose sequence is reachable over a Storing Mode P-Route, it MUST be the Target of a segment and the ingress of a next segment, which are both already set up; the segments are associated with the same Track, which avoids needing an additional encapsulation. For instance, in Section 3.5.1.3, segments A==>B-to-C and C==>D==>E-to-F must be installed with Storing Mode P-DAO messages 1 and 2 before the Track A-->C-->E-to-F that joins them can be installed with Non-Storing Mode P-DAO 3.
ルース シーケンスの次のエントリが保存モード P ルート経由で到達可能な場合、それはセグメントのターゲットおよび次のセグメントの入口でなければならず、両方ともすでに設定されています。セグメントは同じトラックに関連付けられているため、追加のカプセル化が必要なくなります。たとえば、セクション 3.5.1.3 では、セグメント A==>B-to-C および C==>D==>E-to-F は、それらを結合するトラック A-->C-->E-to-F を非保存モード P-DAO 3 でインストールする前に、保存モード P-DAO メッセージ 1 および 2 でインストールする必要があります。
Conversely, if it is reachable over a Non-Storing Mode P-Route, the next loose source-routed hop of the inner Track is a Target of a previously installed Track and the ingress of a next Track, which requires de- and re-encapsulation when switching the outer Tracks that join the loose hops. This is exemplified in Section 3.5.2.3 where Non-Storing Mode P-DAOs 1 and 2 install strict Tracks that Non-Storing Mode P-DAO 3 joins as a super Track. In such a case, packets are subject to double IP-in-IP encapsulation.
逆に、非保存モードの P ルート経由で到達可能な場合、内側のトラックの次のルーズ ソース ルート ホップは、以前にインストールされたトラックのターゲットであり、次のトラックの入口になります。これには、ルーズ ホップに参加する外側のトラックを切り替えるときに、カプセル化解除と再カプセル化が必要になります。これは、セクション 3.5.2.3 で例示されており、非保存モード P-DAO 1 および 2 は、非保存モード P-DAO 3 がスーパー トラックとして参加する厳密なトラックをインストールします。このような場合、パケットは二重の IP-in-IP カプセル化の対象になります。
A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO. Its function is to clean up an existing state as opposed to refreshing it or installing a new one. To tear down a Track, the Root must tear down all the Track segments and protection paths that compose it one by one.
ライフタイムが 0 の P-DAO は、パスなし DAO として解釈されます。その機能は、既存の状態を更新したり、新しい状態をインストールしたりするのではなく、既存の状態をクリーンアップすることです。トラックを破棄するには、ルートは、それを構成するすべてのトラック セグメントと保護パスを 1 つずつ破棄する必要があります。
Since the protection path state of a Track is located only on the ingress Node, the Root cleans up the protection path by sending an NSM-VIO to the ingress to indicate the TrackID and the P-RouteID of the protection path being removed, a Segment Lifetime of 0, and a newer Segment Sequence. The SRH-6LoRH with Via Addresses in the NSM-VIO is not needed; it SHOULD NOT be placed in the message and MUST be ignored by the receiver. Upon that NSM-VIO, the ingress node removes all state for that Track, if any, and replies positively anyway.
トラックの保護パス状態は入力ノード上にのみ存在するため、ルートは、削除される保護パスの TrackID と P-RouteID、セグメント ライフタイム 0、および新しいセグメント シーケンスを示す NSM-VIO を入力に送信することで保護パスをクリーンアップします。NSM-VIO の Via アドレスを持つ SRH-6LoRH は必要ありません。これをメッセージに含めるべきではなく、受信者は無視しなければなりません (MUST)。NSM-VIO が発生すると、イングレス ノードはそのトラックのすべての状態 (存在する場合) を削除し、とにかく肯定的に応答します。
The Root cleans up a section of a segment by sending an SM-VIO to the last node of the segment with an updated TrackID and P-RouteID, a Segment Lifetime of 0, and a newer Segment Sequence. The Via Addresses in the SM-VIO indicate the section of the segment being modified, from the first to the last node that is impacted. This can be the whole segment if it is totally removed or a sequence of one or more nodes that have been bypassed by a segment update.
ルートは、更新された TrackID と P-RouteID、セグメント ライフタイム 0、および新しいセグメント シーケンスを持つ SM-VIO をセグメントの最後のノードに送信することにより、セグメントのセクションをクリーンアップします。SM-VIO のビア アドレスは、影響を受ける最初のノードから最後のノードまで、変更されるセグメントのセクションを示します。これは、完全に削除された場合はセグメント全体、またはセグメントの更新によってバイパスされた 1 つ以上のノードのシーケンスである可能性があります。
The No-Path P-DAO is forwarded normally along the reverse list, even if the intermediate node does not find a segment state to clean up. This results in cleaning up the existing segment state, if any, as opposed to refreshing an existing one or installing a new one.
中間ノードがクリーンアップするセグメント状態を見つけられなかった場合でも、No-Path P-DAO は通常、逆方向リストに沿って転送されます。これにより、既存のセグメントの状態を更新したり、新しいセグメントをインストールしたりするのではなく、既存のセグメントの状態があればそれがクリーンアップされます。
Repathing a Track segment or protection path may cause jitter and packet misordering. For critical flows that require timely and/or in-order delivery, it might be necessary to deploy PREOF [RAW-ARCH] over a highly redundant Track. This specification allows the use of more than one protection path for a Track and 1+N packet redundancy.
トラック セグメントまたは保護パスのパスを変更すると、ジッターやパケットの順序の誤りが発生する可能性があります。タイムリーな配信や順序どおりの配信が必要な重要なフローの場合、冗長性の高いトラック上に PREOF [RAW-ARCH] を展開することが必要になる場合があります。この仕様により、トラックおよび 1+N パケット冗長性に対して複数の保護パスの使用が可能になります。
This section provides the steps to ensure that no packet is lost due to the operation itself. This is ensured by installing the new section from its last node to the first, so when an intermediate node installs a route along the new section, all the downstream nodes in the section have already installed their own. The disabled section is removed as well when the in-flight packets are forwarded along the new section.
このセクションでは、操作自体が原因でパケットが失われないようにするための手順を説明します。これは、新しいセクションを最後のノードから最初のノードまでインストールすることで確実に行われるため、中間ノードが新しいセクションに沿ってルートをインストールすると、セクション内のすべての下流ノードがすでに独自のルートをインストールしています。無効化されたセクションは、送信中のパケットが新しいセクションに沿って転送されるときにも削除されます。
To modify a section of a segment between the first node and a second downstream node (which can be the ingress and egress, respectively) while retaining those nodes in the segment, the Root sends an SM-VIO to the second node indicating the sequence of nodes in the new section of the segment. The SM-VIO indicates the TrackID and the P-RouteID of the segment being updated and a newer Segment Sequence. The P-DAO is propagated from the second to the first node, and on the way, it updates the state on the nodes that are common to the old and new section of the segment and creates a state in the new nodes.
最初のノードと 2 番目の下流ノード (それぞれ入口と出口) の間のセグメントのセクションを変更するために、これらのノードをセグメント内に保持したまま、ルートは 2 番目のノードに SM-VIO を送信し、セグメントの新しいセクション内のノードのシーケンスを示します。SM-VIO は、更新中のセグメントの TrackID と P-RouteID、および新しいセグメント シーケンスを示します。P-DAO は 2 番目のノードから最初のノードに伝播され、途中でセグメントの古いセクションと新しいセクションに共通するノード上の状態を更新し、新しいノードに状態を作成します。
When the state is updated in an intermediate node, that node might still receive packets that were in flight from the ingress to self over the old section of the segment. Since the remainder of the segment is already updated, the packets are forwarded along the new version of the segment from that node on.
中間ノードで状態が更新されると、そのノードは、セグメントの古いセクションを介して入力から自分自身へ送信中のパケットを受信する可能性があります。セグメントの残りの部分はすでに更新されているため、パケットはそのノードからセグメントの新しいバージョンに沿って転送されます。
After a reasonable amount of time, the Root tears down the remaining section(s) of the old segments as described in Section 6.5 to enable the deprecated sections to drain their traffic.
適切な時間が経過すると、セクション 6.5 で説明されているように、ルートは古いセグメントの残りのセクションを破棄し、非推奨のセクションがトラフィックを排出できるようにします。
This specification allows the Root to add protection paths to a Track by sending a Non-Storing Mode P-DAO to the ingress associated to the same TrackID and a new SegmentID. If the protection path is loose, then the segments that join the hops must be created first. It makes sense to add a new protection path before removing one that is becoming excessively lossy and switch to the new protection path before removing the old. Dropping a Track before the new one is installed would reroute the traffic via the Root; this may increase the latency beyond acceptable thresholds and overload the network near the Root. This may also cause loops in the case of stitched Tracks: The packets that cannot be injected in the second Track might be routed back and reinjected at the ingress of the first Track.
この仕様により、ルートは、同じ TrackID と新しい SegmentID に関連付けられたイングレスに非保存モード P-DAO を送信することで、トラックに保護パスを追加できます。保護パスが緩い場合は、ホップを結合するセグメントを最初に作成する必要があります。損失が過度に大きくなっている保護パスを削除する前に新しい保護パスを追加し、古い保護パスを削除する前に新しい保護パスに切り替えることが合理的です。新しいトラックがインストールされる前にトラックを削除すると、ルート経由でトラフィックが再ルーティングされます。これにより、待ち時間が許容可能なしきい値を超えて増加し、ルート付近のネットワークに過負荷がかかる可能性があります。これは、ステッチされたトラックの場合にもループを引き起こす可能性があります。2 番目のトラックに挿入できないパケットは、ルーティングされて最初のトラックの入口で再挿入される可能性があります。
It is also possible to update a protection path by sending a Non-Storing Mode P-DAO to the ingress with the same SegmentID, an incremented Segment Sequence, and the new complete list of hops in the NSM-VIO. Updating a live protection path means changing one or more of the intermediate loose hops, and it involves laying out new segments from and to the new loose hops before the NSM-VIO is issued for the new protection path.
同じセグメント ID、増分されたセグメント シーケンス、および NSM-VIO 内のホップの新しい完全なリストを使用して、非保存モード P-DAO を入力に送信することによって、保護パスを更新することもできます。ライブ保護パスの更新は、1 つ以上の中間ルーズ ホップを変更することを意味し、新しい保護パスに対して NSM-VIO が発行される前に、新しいルーズ ホップとの間で新しいセグメントをレイアウトする必要があります。
Packets that are in flight over the old version of the protection path still follow the old source route path over the old segments. After a reasonable time, the Root tears down those segments as described in Section 6.5 to enable the deprecated segments to drain their traffic.
古いバージョンの保護パスを経由するパケットは、依然として古いセグメント上の古いソース ルート パスをたどります。適切な時間が経過すると、ルートはセクション 6.5 で説明されているようにこれらのセグメントを破棄し、非推奨のセグメントがトラフィックを排出できるようにします。
When injecting a packet in a Track, the ingress router must encapsulate the packet using IP-in-IP to add the Source Routing Header with the final destination set to the Track egress.
パケットをトラックに挿入する場合、イングレス ルーターは IP-in-IP を使用してパケットをカプセル化し、最終宛先がトラック出力に設定されたソース ルーティング ヘッダーを追加する必要があります。
All properties of a Track's operations are inherited from the main Instance that is used to install the Track. For instance, the use of compression per [RFC8138] is determined by whether it is used in the RPL main DODAG, e.g., by setting the 'T' flag [RFC9035] in the RPL Configuration option.
トラックの操作のすべてのプロパティは、トラックのインストールに使用されるメイン インスタンスから継承されます。たとえば、[RFC8138] に基づく圧縮の使用は、RPL メイン DODAG で使用されるかどうか、たとえば RPL 設定オプションで「T」フラグ [RFC9035] を設定することによって決定されます。
When the Track ingress places a packet in a Track, it encapsulates it with an additional IPv6 header, a Routing Header, and an IPv6 Hop-by-Hop Option Header that contains the RPI as follows:
トラック入力がパケットをトラックに配置すると、次のように、追加の IPv6 ヘッダー、ルーティング ヘッダー、および RPI を含む IPv6 ホップバイホップ オプション ヘッダーでパケットをカプセル化します。
* In the uncompressed form, the source of the packet is the address that this router uses as the DODAGID for the Track, the destination is the first Via Address in the NSM-VIO, and the RH is an SRH [RFC6554] that contains the list of the remaining Via Addresses, ending with the Track egress.
* 非圧縮形式では、パケットの送信元はこのルータがトラックの DODAGID として使用するアドレス、宛先は NSM-VIO の最初の経由アドレス、RH はトラック出力で終わる残りの経由アドレスのリストを含む SRH [RFC6554] です。
* In a network where 6LoWPAN header compression [RFC6282] is in use, it is preferred to implement "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] and compress the RPL artifacts as indicated in [RFC8138].
* 6LoWPAN ヘッダ圧縮 [RFC6282] が使用されているネットワークでは、「IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch」[RFC8025] を実装し、[RFC8138] で示されているように RPL アーティファクトを圧縮することが好ましい。
In that case, the RPL Source Route Header is the exact copy of the (chain of) SRH-6LoRH found in the NSM-VIO, also ending with the Track egress. The RPI-6LoRH is appended next, followed by an IP-in-IP 6LoRH header that indicates the ingress router in the Encapsulator Address field; see a similar case in Figure 20 of [RFC8138].
その場合、RPL ソース ルート ヘッダーは、NSM-VIO で見つかった SRH-6LoRH (のチェーン) の正確なコピーであり、これもトラック出力で終わります。次に RPI-6LoRH が追加され、その後に Encapsulator Address フィールド内のイングレス ルーターを示す IP-in-IP 6LoRH ヘッダーが追加されます。[RFC8138] の図 20 の同様のケースを参照してください。
To signal the Track in the packet, this specification leverages the RPL forwarding model as follows:
パケット内のトラックに信号を送るために、この仕様では次のように RPL 転送モデルを利用します。
* In the data packets, the Track DODAGID and the TrackID MUST be respectively signaled as the IPv6 source address, and the RPLInstanceID field of the RPI MUST be placed in the outer chain of IPv6 headers.
* データパケットでは、Track DODAGID と TrackID をそれぞれ IPv6 ソースアドレスとしてシグナリングしなければならず、RPI の RPLInstanceID フィールドは IPv6 ヘッダーの外側チェーンに配置しなければなりません。
The RPI carries a Local RPLInstanceID called the TrackID, which, in association with the DODAGID, indicates the Track along which the packet is forwarded.
RPI は、TrackID と呼ばれるローカル RPLInstanceID を伝送します。これは、DODAGID と関連付けられて、パケットが転送されるトラックを示します。
The 'D' flag in the RPLInstanceID MUST be set to 0 to indicate that the source address in the IPv6 header is set to the DODAGID (see more in Section 6.3).
RPLInstanceID の「D」フラグは、IPv6 ヘッダーの送信元アドレスが DODAGID に設定されていることを示すために 0 に設定されなければなりません (セクション 6.3 を参照)。
* This specification conforms to the principles of [RFC9008] with regard to packet forwarding and encapsulation along a Track as follows:
* この仕様は、次のようにトラックに沿ったパケット転送とカプセル化に関する [RFC9008] の原則に準拠しています。
- With this specification, the Track is a RPL DODAG. From the perspective of that DODAG, the Track ingress is the Root, the Track egress is a RPL-Aware 6LR, and neighbors of the Track egress that can be reached via the Track, but are external to it, are external destinations and treated as RPL-Unaware Leaves (RULs). The encapsulation rules in [RFC9008] apply.
- この仕様では、トラックは RPL DODAG です。DODAG の観点から見ると、トラック入口はルートであり、トラック出口は RPL 対応 6LR であり、トラック経由で到達できるがトラックの外部にあるトラック出口の近隣は外部宛先であり、RPL 非対応リーブ (RUL) として扱われます。[RFC9008] のカプセル化規則が適用されます。
- If the Track ingress is the originator of the packet and the Track egress is the destination of the packet, there is no need for an encapsulation.
- トラック入力がパケットの発信元であり、トラック出力がパケットの宛先である場合、カプセル化の必要はありません。
- Thus, the Track ingress must encapsulate the traffic that it did not originate, and it must include an RPI in the encapsulation to signal the TrackID.
- したがって、Track イングレスは、それが発信したものではないトラフィックをカプセル化する必要があり、TrackID を通知するためにカプセル化に RPI を含める必要があります。
A packet that is being routed over the RPL Instance associated to a first Non-Storing Mode Track MAY be placed recursively in a second Track to cover one loose hop of the first Track, as discussed in more detail in Section 3.5.2.3. On the other hand, a Storing Mode segment must be strict, and a packet that it placed in a Storing Mode segment MUST follow that segment till the segment egress.
セクション 3.5.2.3 で詳しく説明するように、最初の非保存モード トラックに関連付けられた RPL インスタンス上でルーティングされているパケットは、最初のトラックの 1 つのルーズ ホップをカバーするために 2 番目のトラックに再帰的に配置されてもよい(MAY)。一方、Storing Mode セグメントは厳密である必要があり、Storing Mode セグメントに配置されたパケットは、セグメントが出力されるまでそのセグメントに従わなければなりません (MUST)。
It is known that a packet is forwarded along a Track by the source address and the RPI in the encapsulation. The TrackID is used to identify the RIB entries associated to that Track, which, in intermediate nodes, correspond to the P-Routes for the segments of the Track that the forwarding router is aware of. Packet processing uses the following precedence: 1) self-delivery or Routing Header handling when one is present, 2) delivery to direct neighbors, 3) delivery to indirect neighbors, 4) routing along a segment along the Track, and 5) injecting the packet in another Track, as a last resort.
カプセル化では、パケットは送信元アドレスと RPI によってトラックに沿って転送されることが知られています。TrackID は、そのトラックに関連付けられた RIB エントリを識別するために使用されます。RIB エントリは、中間ノードにおいて、転送ルータが認識しているトラックのセグメントの P-Route に対応します。パケット処理では、次の優先順位が使用されます。1) 自己配信またはルーティング ヘッダーが存在する場合の処理、2) 直接の近隣への配信、3) 間接的な近隣への配信、4) トラックに沿ったセグメントに沿ったルーティング、5) 最後の手段としてのパケットの別のトラックへの挿入。
To achieve this, the packet handling logic MUST happen in the following order:
これを実現するには、パケット処理ロジックが次の順序で実行される必要があります。
* If the destination of the packet is self:
* パケットの宛先が自分自身の場合:
1. If the header chain contains a RPL Source Route Header that is not fully consumed, then the packet is forwarded along the Track as prescribed by [RFC6554], meaning that the next entry in the Routing Header becomes the destination.
1. ヘッダー チェーンに完全に消費されていない RPL ソース ルート ヘッダーが含まれている場合、パケットは [RFC6554] の規定に従ってトラックに沿って転送されます。これは、ルーティング ヘッダーの次のエントリが宛先になることを意味します。
2. Otherwise, if the packet was encapsulated, then the packet is decapsulated and the forwarding process recurses; else, the packet is delivered to the stack.
2. それ以外の場合、パケットがカプセル化されている場合、パケットはカプセル化解除され、転送プロセスが再帰されます。それ以外の場合、パケットはスタックに配信されます。
* Otherwise, the packet is forwarded as follows:
* それ以外の場合、パケットは次のように転送されます。
1. If the destination of the packet is a direct neighbor, e.g., installed by IPv6 Neighbor Discovery, then the packet MUST be forwarded to that neighbor.
1. パケットの宛先が、例えば IPv6 近隣探索によってインストールされた直接の近隣である場合、パケットはその近隣に転送されなければなりません (MUST)。
2. Else, if the destination of the packet is an indirect neighbor, e.g., installed by a multicast DAO message from a common neighbor (see Section 4.1.4), then the packet MUST be forwarded to the common neighbor.
2. それ以外の場合、パケットの宛先が間接的な近隣者である場合、たとえば、共通の近隣者からのマルチキャスト DAO メッセージによってインストールされた場合 (セクション 4.1.4 を参照)、パケットは共通の近隣者に転送されなければなりません (MUST)。
3. Else, if there is a RIB entry for the same Track (e.g., installed by an SM-VIO in a DAO message with the destination as the target) and the next hop in the RIB entry is a direct neighbor, then the packet is passed to that neighbor.
3. そうでない場合、同じトラックに RIB エントリがあり (たとえば、宛先をターゲットとする DAO メッセージ内の SM-VIO によってインストールされる)、RIB エントリ内の次のホップが直接の隣接ホップである場合、パケットはその隣接に渡されます。
4. Else, if there is a RIB entry for the different Track (e.g., installed by an NSM-VIO in a DAO message with the destination as the target), then the packet is encapsulated to be forwarded along that Track and the forwarding process recurses; otherwise, the packet is dropped.
4. それ以外の場合、異なるトラックの RIB エントリがある場合 (たとえば、宛先をターゲットとする DAO メッセージ内の NSM-VIO によってインストールされる)、パケットはそのトラックに沿って転送されるようにカプセル化され、転送プロセスが再帰されます。それ以外の場合、パケットはドロップされます。
5. To avoid loops, and as opposed to packets that were not encapsulated, a packet that was decapsulated from a Track MUST NOT be routed along the default route of the main DODAG; this would mean that the end-to-end path is uncontrolled. The node that discovers the fault MUST discard the packet.
5. ループを回避するために、カプセル化されていないパケットとは対照的に、トラックからカプセル化解除されたパケットをメイン DODAG のデフォルト ルートに沿ってルーティングしてはなりません (MUST NOT)。これは、エンドツーエンドのパスが制御されていないことを意味します。障害を発見したノードはパケットを破棄しなければなりません(MUST)。
The node that drops a packet in any of the steps above MUST send an ICMPv6 error message [RFC4443] to the Root, with a new code "Error in P-Route" (see Section 11.15). The Root can then repair by updating the broken segment and/or Tracks. In the case of a broken segment, the Root removes the leftover sections of the segment using SM-VIOs with a lifetime of 0, indicating the section where one or more nodes are being removed (see Section 6.6).
上記のいずれかの手順でパケットをドロップしたノードは、新しいコード「Error in P-Route」(セクション 11.15 を参照) を付けて ICMPv6 エラー メッセージ [RFC4443] をルートに送信しなければなりません (MUST)。ルートは、壊れたセグメントやトラックを更新することで修復できます。セグメントが壊れた場合、ルートはライフタイム 0 の SM-VIO を使用してセグメントの残りのセクションを削除します。これは、1 つ以上のノードが削除されるセクションを示します (セクション 6.6 を参照)。
In case of a permanent forwarding error along a source route path, the node that fails to forward SHOULD send an ICMP error with the code "Error in Source Routing Header" back to the source of the packet, as described in Section 11.2.2.3 of [RPL]. Upon receiving this message, the encapsulating node SHOULD stop using the source route path for a reasonable period of time, which depends on the deployment, and it SHOULD send an ICMP message with the code "Error in P-Route" to the Root. Failure to follow these steps may result in packet loss and wasted resources along the source route path that is broken.
ソースルートパスに沿った永続的な転送エラーの場合、転送に失敗したノードは、[RPL] のセクション 11.2.2.3 で説明されているように、コード「ソースルーティングヘッダーのエラー」を含む ICMP エラーをパケットのソースに送り返す必要があります (SHOULD)。このメッセージを受信すると、カプセル化ノードは、デプロイメントに応じて適切な期間、ソース ルート パスの使用を停止する必要があり (SHOULD)、コード「Error in P-Route」を含む ICMP メッセージをルートに送信する必要があります (SHOULD)。これらの手順に従わないと、パケット損失が発生し、壊れたソース ルート パスに沿ってリソースが無駄に浪費される可能性があります。
Either way, the ICMP message MUST be throttled in case of consecutive occurrences. It MUST be sourced at the ULA or GUA that is used in this Track for the source node, so the Root can establish where the error happened.
いずれにせよ、連続して発生する場合には、ICMP メッセージを抑制しなければなりません。ルートがエラーが発生した場所を確立できるように、ソース ノードのこのトラックで使用される ULA または GUA をソースとする必要があります。
The portion of the invoking packet that is sent back in the ICMP message SHOULD record at least up to the RH if one is present, and the hop of the RH SHOULD be consumed by this node so that the destination in the IPv6 header is the next hop that this node could not reach. If a 6LoRH [RFC8138] is used to carry the IPv6 routing information in the outer header, then the whole 6LoRH information SHOULD be present in the ICMP message.
ICMP メッセージで送り返される呼び出し側パケットの部分は、存在する場合には少なくとも RH まで記録すべきであり (SHOULD)、IPv6 ヘッダーの宛先がこのノードが到達できなかったネクストホップになるように、RH のホップはこのノードによって消費されるべきです(SHOULD)。6LoRH [RFC8138] が外側ヘッダーで IPv6 ルーティング情報を運ぶために使用される場合、6LoRH 情報全体が ICMP メッセージに存在する必要があります (SHOULD)。
When the main DODAG in a 6LoWPAN LLN is operated in Non-Storing Mode and the data packets are compressed using [RFC8138], a typical packet that circulates in the main DODAG is formatted as shown in Figure 20, representing the case where an IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]):
6LoWPAN LLN のメイン DODAG が非保存モードで動作し、データ パケットが [RFC8138] を使用して圧縮される場合、メイン DODAG 内を循環する典型的なパケットは図 20 に示すようにフォーマットされ、IP-in-IP カプセル化が必要な場合を表します ([RFC9008] の表 19 を参照)。
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
| Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
<= RFC 6282 =>
<================ Inner packet ==================== = =
Figure 20: A Packet as Forwarded Along the Main DODAG
図 20: メイン DODAG に沿って転送されるパケット
Since there is no page switch between the encapsulated packet and the encapsulation, the first octet of the compressed packet that acts as the page selector is actually removed at encapsulation; therefore, the inner packet used in the descriptions below starts with the SRH-6LoRH and is exactly the packet represented in Figure 20, from the second octet onward.
カプセル化されたパケットとカプセル化の間にはページ切り替えがないため、ページ セレクターとして機能する圧縮パケットの最初のオクテットは、カプセル化時に実際に削除されます。したがって、以下の説明で使用される内部パケットは SRH-6LoRH で始まり、2 オクテット以降は図 20 に示されているパケットとまったく同じになります。
When encapsulating the inner packet to place in the Track, the first header that the ingress appends at the head of the inner packet is an IP-in-IP 6LoRH header; in that header, the encapsulator address, which maps to the IPv6 source address in the uncompressed form, contains a GUA or ULA IPv6 address of the ingress node that serves as the DODAGID for the Track, expressed in a compressed form using the DODAGID of the main DODAG as a reference for the compression. If the address is compressed to 2 bytes, the resulting value for the Length field (shown in Figure 21) is 3, meaning that the SRH-6LoRH as a whole is 5 octets long.
内部パケットをカプセル化してトラックに配置する場合、入力側が内部パケットの先頭に追加する最初のヘッダーは IP-in-IP 6LoRH ヘッダーです。そのヘッダーでは、非圧縮形式で IPv6 ソース アドレスにマップされるカプセル化アドレスに、トラックの DODAGID として機能する入口ノードの GUA または ULA IPv6 アドレスが含まれており、圧縮の参照としてメイン DODAG の DODAGID を使用して圧縮形式で表現されます。アドレスが 2 バイトに圧縮された場合、長さフィールドの結果の値 (図 21 を参照) は 3 になります。これは、SRH-6LoRH 全体の長さが 5 オクテットであることを意味します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
Figure 21: The IP-in-IP 6LoRH Header
図 21: IP-in-IP 6LoRH ヘッダー
At the head of the resulting sequence of bytes, the Track ingress then adds a P-RPI-6LoRH header to transport the RPI in its compressed form as illustrated in Figure 12. The RPI carries the TrackID as RPLInstanceID. Combined with the IP-in-IP 6LoRH header, this allows identifying the Track without ambiguity.
結果のバイト シーケンスの先頭に、図 12 に示すように、Track イングレスは P-RPI-6LoRH ヘッダーを追加して、RPI を圧縮形式で転送します。RPI は、TrackID を RPLInstanceID として伝送します。IP-in-IP 6LoRH ヘッダーと組み合わせると、曖昧さなくトラックを識別できます。
The SRH-6LoRH is then added at the head of the resulting sequence of bytes as a verbatim copy of the content of the SM-VIO that signaled the selected protection path.
SRH-6LoRH は、選択された保護パスを通知した SM-VIO の内容の逐語的なコピーとして、結果のバイト シーケンスの先頭に追加されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Where N = Size + 1
Figure 22: The SRH-6LoRH Header
図 22: SRH-6LoRH ヘッダー
The format of the resulting encapsulated packet, which is in compressed form per [RFC8138], is illustrated in Figure 23:
[RFC8138] に従って圧縮された、結果として得られるカプセル化されたパケットのフォーマットを図 23 に示します。
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
| Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
Signals : Loose Hops : TrackID : Track DODAGID :
Figure 23: A Packet as Forwarded Along a Track
図 23: トラックに沿って転送されるパケット
This specification expects that the main DODAG is operated in Non-Storing Mode. The reasons for that limitation are mostly related to LLN operations, power, and spectrum conservation:
この仕様では、メイン DODAG が非保存モードで動作することを想定しています。この制限の理由は主に、LLN の動作、電力、スペクトルの保存に関連しています。
* In Non-Storing Mode, the Root already knows the DODAG topology, so the additional topological information is reduced to the siblings.
* 非保存モードでは、ルートはすでに DODAG トポロジを認識しているため、追加のトポロジ情報は兄弟に限定されます。
* The downward routes are updated with unicast messages to the Root, which ensures that the Root can reach back to the LLN nodes after a repair faster than in the case of Storing Mode. Also, the Root can control the use of path diversity in the DODAG to reach the LLN nodes. For both reasons, Non-Storing Mode provides better capabilities for the Root to maintain the P-Routes.
* 下向きルートはルートへのユニキャスト メッセージで更新され、修復後にルートが保存モードの場合よりも早く LLN ノードに到達できるようになります。また、ルートは、LLN ノードに到達するために DODAG でのパス ダイバーシティの使用を制御できます。両方の理由により、非保存モードは、ルートが P ルートを維持するためのより優れた機能を提供します。
* When the main DODAG is operated in Non-Storing Mode, P-Routes enable loose source routing, which is only an advantage in that mode. Storing Mode does not use Source Routing Headers and does not derive the same benefits from this capability.
* メイン DODAG が非保存モードで動作している場合、P ルートにより緩やかなソース ルーティングが可能になりますが、これはそのモードでの利点にすぎません。保存モードはソース ルーティング ヘッダーを使用しないため、この機能から同じ利点は得られません。
On the other hand, since RPL is a Layer 3 routing protocol, its applicability extends beyond LLNs to a generic IP network. RPL requires fewer resources than alternative IGPs such as OSPF, IS-IS, the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or RIP when using routing stretch rather than the shortest path routes to a destination that those protocols compute. P-Routes add the capability to install the shortest and/or constrained routes to special destinations as discussed in Appendix A.9.4 of "An Autonomic Control Plane (ACP)" [RFC8994].
一方、RPL はレイヤ 3 ルーティング プロトコルであるため、その適用範囲は LLN を超えて汎用 IP ネットワークにまで広がります。RPL は、OSPF、IS-IS、Enhanced Interior Gateway Routing Protocol（EIGRP）、BABEL、RIP などの代替 IGP よりも、これらのプロトコルが計算する宛先への最短パス ルートではなくルーティング ストレッチを使用する場合に必要なリソースが少なくなります。P ルートは、「自律制御プレーン (ACP)」[RFC8994] の付録 A.9.4 で説明されているように、特別な宛先への最短および/または制約されたルートをインストールする機能を追加します。
In a powered and wired network, when enough memory to store the needed routes is available, the RPL Storing Mode proposes a better trade-off than the Non-Storing Mode, as it reduces the routing stretch and lowers the load on the Root. In that case, the control path between the Root and the RPL nodes can be maintained more aggressively and with more redundancy than in LLNs, and the nodes can be reached to maintain the P-Routes at most times for a finer and more reactive control.
電力供給された有線ネットワークでは、必要なルートを保存するのに十分なメモリが利用可能な場合、RPL ストレージ モードは、ルーティングのストレッチを減らし、ルートの負荷を下げるため、非ストレージ モードよりも優れたトレードオフを提案します。その場合、ルート ノードと RPL ノード間の制御パスは、LLN よりも積極的に、より冗長性を持って維持でき、ほとんどの場合、ノードに到達して P ルートを維持できるため、より細かく、より反応的な制御が可能になります。
This section specifies the additions that are needed to support P-Routes when the main DODAG is operated in Storing Mode. As long as the RPI can be processed adequately by the data plane, the changes in this specification are limited to the DAO message. The Track structure, routes, and forwarding operations remain the same. Since there is no capability negotiation, the expectation is that all the nodes in the network support this specification in the same fashion or are configured the same way through management.
このセクションでは、メイン DODAG が保存モードで動作している場合に P-Route をサポートするために必要な追加を指定します。RPI がデータ プレーンによって適切に処理できる限り、この仕様の変更は DAO メッセージに限定されます。トラックの構造、ルート、転送操作は変わりません。機能ネゴシエーションがないため、ネットワーク内のすべてのノードが同じ方法でこの仕様をサポートするか、管理を通じて同じ方法で設定されることが期待されます。
In Storing Mode, the Root misses the Child-to-Parent relationship that forms the main DODAG as well as the sibling information. To provide that knowledge, the nodes in the network MUST send additional DAO messages that are unicast to the Root just like Non-Storing DAO messages are.
保存モードでは、ルートは、メインの DODAG を形成する子から親への関係および兄弟情報を失います。その知識を提供するために、ネットワーク内のノードは、非保存 DAO メッセージと同様に、ルートにユニキャストされる追加の DAO メッセージを送信しなければなりません (MUST)。
In the DAO message, the originating router advertises a set of neighbor nodes using SIOs, regardless of the relative position in the DODAG of the advertised node versus this router.
DAO メッセージでは、発信元ルーターは、DODAG 内でのアドバタイズされたノードとこのルーターとの相対位置に関係なく、SIO を使用して隣接ノードのセットをアドバタイズします。
The DAO message MUST be formed as follows:
DAO メッセージは次のように形成されなければなりません。
* The originating router is identified by the source address of the DAO. That address MUST be the one that this router registers to the neighbor routers so the Root can correlate the DAOs from those routers when they advertise this router as their neighbor. The DAO contains one or more sequences of one TIO and one or more SIOs. There is no RPL Target Option so that the Root is not confused into adding a Storing Mode route to the Target.
* 発信元ルーターは、DAO の送信元アドレスによって識別されます。そのアドレスは、ルートがこのルーターを近隣ルーターとしてアドバタイズするときに、これらのルーターからの DAO を関連付けることができるように、このルーターが近隣ルーターに登録するものでなければなりません。DAO には、1 つの TIO と 1 つ以上の SIO の 1 つ以上のシーケンスが含まれます。RPL ターゲット オプションがないため、ルートがターゲットに保存モード ルートを追加する際に混乱することはありません。
* The TIO is formed as in Storing Mode, and the Parent Address is not present. The Path Sequence and Path Lifetime fields are aligned with the values used in the Address Registration of the node(s) advertised in the SIO, as explained in Section 9.1 of [RFC9010]. Having similar values in all nodes allows factorizing the TIO for multiple SIOs as done in [RPL].
* TIO はストレージ モードと同様に形成され、親アドレスは存在しません。[RFC9010] のセクション 9.1 で説明されているように、Path Sequence フィールドと Path Lifetime フィールドは、SIO でアドバタイズされるノードのアドレス登録で使用される値と一致します。すべてのノードで同様の値を持つことにより、[RPL] で行われたように複数の SIO の TIO を因数分解することができます。
* The TIO is followed by one or more SIOs that provide an address (ULA or GUA) of the advertised neighbor node.
* TIO の後には、アドバタイズされた隣接ノードのアドレス (ULA または GUA) を提供する 1 つ以上の SIO が続きます。
However, the RPL routing information headers may not be supported on all types of routed network infrastructures, especially not in high-speed routers. When the RPI is not supported in the data plane, there cannot be Local RPL Instances and RPL can only operate as a single topology (the main DODAG). The RPL Instance is the one that runs the main DODAG, and the ingress node that encapsulates the RPL Instance is not the Root. The routes along the Tracks are alternate routes to those available along the main DODAG. They MAY conflict with routes to children and MUST take precedence in the routing table. The Targets MUST be adjacent to the Track egress to avoid loops that may form if the packet is reinjected in the main DODAG.
ただし、RPL ルーティング情報ヘッダーは、すべてのタイプのルーティングされたネットワーク インフラストラクチャ、特に高速ルーターではサポートされていない可能性があります。RPI がデータ プレーンでサポートされていない場合、ローカル RPL インスタンスは存在できず、RPL は単一のトポロジ (メイン DODAG) としてのみ動作します。RPL インスタンスはメイン DODAG を実行するインスタンスであり、RPL インスタンスをカプセル化するイングレス ノードはルートではありません。トラックに沿ったルートは、主要な DODAG に沿って利用可能なルートの代替ルートです。これらは子へのルートと競合する可能性があり、ルーティング テーブルで優先されなければなりません。パケットがメイン DODAG に再注入された場合に形成される可能性のあるループを回避するために、ターゲットはトラック出力に隣接していなければなりません。
This specification builds Tracks with parallel or interleaved protection paths as opposed to a more complex DODAG with interconnections at any place desirable. The reason for that limitation is related to constrained node operations and the capability to store a large amount of topological information and compute complex paths:
この仕様は、任意の場所に相互接続するより複雑な DODAG とは対照的に、並列またはインターリーブされた保護パスを備えたトラックを構築します。この制限の理由は、制約されたノード操作と、大量のトポロジ情報を保存し、複雑なパスを計算する機能に関連しています。
* With this specification, the node in the LLN has no topological awareness and does not need to maintain dynamic information about the link quality and availability.
* この仕様では、LLN 内のノードはトポロジーを認識せず、リンクの品質と可用性に関する動的な情報を維持する必要がありません。
* The Root has complete topological information and statistical metrics that allow it, or its PCE, to perform a global optimization of all Tracks in its DODAG. Based on that information, the Root computes the protection path and produces the source route paths.
* ルートには、ルートまたはその PCE が DODAG 内のすべてのトラックのグローバルな最適化を実行できるようにする完全なトポロジー情報と統計メトリックがあります。その情報に基づいて、ルートは保護パスを計算し、ソース ルート パスを生成します。
* The node merely selects one of the proposed paths and applies the associated pre-computed Routing Header in the encapsulation. This alleviates both the complexity of computing a path and the compressed form of the Routing Header.
* ノードは、提案されたパスの 1 つを選択するだけで、関連する事前に計算されたルーティング ヘッダーをカプセル化に適用します。これにより、パスの計算の複雑さとルーティング ヘッダーの圧縮形式の両方が軽減されます。
The RAW architecture [RAW-ARCH] actually expects the PLR at the Track ingress to react to changes in the forwarding conditions along the Track and reroute packets to maintain the required degree of reliability. To achieve this, the PLR needs the full richness of a DODAG to form any path that could meet the SLO.
RAW アーキテクチャ [RAW-ARCH] は、実際には、トラック入口の PLR がトラックに沿った転送条件の変化に反応し、必要な程度の信頼性を維持するためにパケットを再ルーティングすることを期待しています。これを達成するには、PLR は SLO を満たすパスを形成するために DODAG の機能を最大限に活用する必要があります。
This section specifies the additions that are needed to turn the Track into a full DODAG and enable the main Root to provide the necessary topological information to the Track ingress. The expectation is that the PLR's metrics will be in a different order than the PCE's metrics because of the difference in the timescale between routing and forwarding; see more in [RAW-ARCH]. It follows that the PLR will learn the metrics it needs from an alternate source, e.g., OAM frames.
このセクションでは、トラックを完全な DODAG に変換し、メイン ルートが必要なトポロジー情報をトラック入口に提供できるようにするために必要な追加を指定します。ルーティングと転送のタイムスケールの違いにより、PLR のメトリックは PCE のメトリックとは異なる順序になることが予想されます。詳細については、[RAW-ARCH] を参照してください。したがって、PLR は、OAM フレームなどの代替ソースから必要なメトリックを学習することになります。
To pass the topological information to the ingress, the Root uses a P-DAO message that contains sequences of Targets and TIOs that collectively represent the Track, expressed in the same fashion as in classical Non-Storing Mode. The difference is that the Root is the source as opposed to the destination, and the Root can report information on many Targets, possibly the full Track, with one P-DAO.
トポロジ情報をイングレスに渡すために、ルートは P-DAO メッセージを使用します。このメッセージには、集合的にトラックを表すターゲットと TIO のシーケンスが含まれており、従来の非保存モードと同じ方法で表現されます。違いは、ルートは宛先ではなくソースであり、ルートは 1 つの P-DAO で多くのターゲット (場合によってはトラック全体) に関する情報をレポートできることです。
Note that the Path Sequence and Lifetime in the TIO are selected by the Root and that the Target/Transit information tuples in the P-DAO are not those received by the Root in the DAO messages about the said Targets. The Track may follow sibling routes and does not need to be congruent with the main DODAG.
TIO のパス シーケンスとライフタイムはルートによって選択され、P-DAO のターゲット/トランジット情報タプルは、前記ターゲットに関する DAO メッセージでルートによって受信されたものではないことに注意してください。トラックは兄弟ルートをたどることができ、メインの DODAG と一致している必要はありません。
This document provides a set of tools that may or may not be needed by an implementation depending on the type of application it serves. This section describes profiles that can be implemented separately, e.g., using only a portion of this specification to meet a particular use case, and can be used to discriminate what an implementation can and cannot do.
このドキュメントでは、サービスを提供するアプリケーションの種類に応じて、実装で必要になる場合とそうでない場合がある一連のツールを提供します。このセクションでは、個別に実装できるプロファイルについて説明します。たとえば、特定のユースケースを満たすためにこの仕様の一部のみを使用するなど、実装でできることとできないことを区別するために使用できます。
Profiles 0 to 2 operate in the main Instance and do not require the support of Local RPL Instances or the indication of the RPL Instance in the data plane. Profile 3 and above leverage Local RPL Instances to build arbitrary Tracks rooted at the Track ingress, using the namespace of the Track ingress for the TrackID.
プロファイル 0 ～ 2 はメイン インスタンスで動作し、ローカル RPL インスタンスのサポートやデータ プレーンでの RPL インスタンスの指示を必要としません。プロファイル 3 以降では、ローカル RPL インスタンスを利用して、TrackID の Track Ingress の名前空間を使用して、Track Ingress をルートとする任意の Track を構築します。
Profiles 0 and 1 are REQUIRED by all implementations that may be used in LLNs; Profile 1 leverages Storing Mode to reduce the size of the RPL Source Route Header in the most common LLN deployments. Profile 2 is RECOMMENDED in a high-speed (e.g., wired) environment to enable Traffic Engineering and network automation. All the other profile/ environment combinations are OPTIONAL.
プロファイル 0 と 1 は、LLN で使用されるすべての実装で必須です。プロファイル 1 は、保存モードを利用して、最も一般的な LLN 導入における RPL ソース ルート ヘッダーのサイズを削減します。プロファイル 2 は、トラフィック エンジニアリングとネットワーク自動化を可能にする高速 (有線など) 環境で推奨されます。他のプロファイルと環境の組み合わせはすべてオプションです。
Profile 0:
プロファイル 0:
Profile 0 is the legacy support of [RPL] Non-Storing Mode, with default routing Northwards (up) and strict source routing Southwards (down the main DODAG). It provides the minimal common functionality that must be implemented as a prerequisite to all the Track-supporting profiles. The other profiles extend Profile 0 with selected capabilities that this specification introduces.
プロファイル 0 は、[RPL] 非ストレージ モードのレガシー サポートであり、デフォルトの北方向 (上方向) へのルーティングと、南方向 (メイン DODAG の下方向) への厳密なソース ルーティングを備えています。これは、すべての Track サポート プロファイルの前提条件として実装する必要がある最小限の共通機能を提供します。他のプロファイルは、この仕様で導入される選択された機能でプロファイル 0 を拡張します。
Profile 1 (Storing Mode P-Route segments along the main DODAG):
プロファイル 1 (メイン DODAG に沿ったモード P ルート セグメントの保存):
Profile 1 does not create new paths; compared to Profile 0, it combines Storing and Non-Storing Modes to balance the size of the Routing Header in the packet and the amount of state in the intermediate routers in a Non-Storing Mode RPL DODAG.
プロファイル 1 は新しいパスを作成しません。プロファイル 0 と比較して、ストレージ モードと非ストレージ モードを組み合わせて、パケット内のルーティング ヘッダーのサイズと非ストレージ モード RPL DODAG の中間ルーターの状態量のバランスをとります。
Profile 2 (Non-Storing Mode P-Route segments along the main DODAG):
プロファイル 2 (メイン DODAG に沿った非保管モード P ルート セグメント):
Profile 2 extends Profile 0 with strict source-routed Non-Storing Mode P-Routes along the main DODAG, which is the same as Profile 1 but using NSM-VIOs as opposed to SM-VIOs. Profile 2 provides the same capability to compress the SRH in packets down the main DODAG as Profile 1, but it requires an encapsulation in order to insert an additional SRH between the loose source routing hops. With Profile 2, the Tracks MUST be installed as subTracks of the main DODAG, and the main Instance MUST be used as the TrackID. Note that the ingress node encapsulates but is not the Root, as it does not own the DODAGID.
プロファイル 2 は、メイン DODAG に沿った厳密なソース ルーティングの非ストレージ モード P ルートを使用してプロファイル 0 を拡張します。これはプロファイル 1 と同じですが、SM-VIO ではなく NSM-VIO を使用します。プロファイル 2 は、メイン DODAG を通過するパケット内の SRH を圧縮するプロファイル 1 と同じ機能を提供しますが、ルーズ ソース ルーティング ホップ間に追加の SRH を挿入するためにカプセル化が必要です。プロファイル 2 では、トラックはメイン DODAG のサブトラックとしてインストールされなければならず、メイン インスタンスは TrackID として使用されなければなりません。入力ノードはカプセル化しますが、DODAGID を所有していないため、ルートではないことに注意してください。
Profile 3:
プロフィール 3:
In order to form the best path possible, this profile requires the support of an SIO to inform the Root of additional possible hops. Profile 3 extends Profile 1 with additional Storing Mode P-Routes that install segments that do not follow the main DODAG. If the segment ingress (in the SM-VIO) is the same as the IPv6 address of the Track ingress (in the Projected DAO Base Object), the P-DAO creates an implicit Track between the segment ingress and the segment egress.
可能な限り最適なパスを形成するために、このプロファイルでは、追加の可能なホップをルートに通知するための SIO のサポートが必要です。プロファイル 3 は、メイン DODAG に従わないセグメントをインストールする追加の保存モード P ルートでプロファイル 1 を拡張します。(SM-VIO 内の) セグメント イングレスが (投影された DAO ベース オブジェクト内の) トラック イングレスの IPv6 アドレスと同じである場合、P-DAO はセグメント イングレスとセグメント エグレスの間に暗黙的なトラックを作成します。
Profile 4:
プロファイル 4:
Profile 4 extends Profile 2 with strict source-routed Non-Storing Mode P-Routes to form forward Tracks that are inside the main DODAG but do not necessarily follow it. A Track is formed as one or more strict source-routed paths between the Root that is the Track ingress and the Track egress that is the last node.
プロファイル 4 は、厳密なソース ルーティングの非保存モード P ルートを使用してプロファイル 2 を拡張し、メイン DODAG 内にあるが必ずしもそれに従うわけではない前方トラックを形成します。トラックは、トラックの入口であるルートと最後のノードであるトラックの出口との間の 1 つ以上の厳密なソース ルーティング パスとして形成されます。
Profile 5:
プロファイル 5:
Profile 5 combines Profile 4 with Profile 1 and enables loose source routing between the ingress and the egress of the Track. As in Profile 1, Storing Mode P-Routes form the connections in the loose source route.
プロファイル 5 は、プロファイル 4 とプロファイル 1 を組み合わせて、トラックの入力と出力の間の緩やかなソース ルーティングを有効にします。プロファイル 1 と同様に、ストレージ モード P ルートはルーズ ソース ルート内の接続を形成します。
Profile 6:
プロファイル 6:
Profile 6 combines Profile 4 with Profile 2 and enables loose source routing between the ingress and the egress of the Track.
プロファイル 6 は、プロファイル 4 とプロファイル 2 を組み合わせて、トラックの入力と出力の間の緩やかなソース ルーティングを有効にします。
Profile 7:
プロファイル 7:
Profile 7 implements Profile 5 in a main DODAG that is operated in Storing Mode as presented in Section 7.1. As in Profiles 1 and 2, the TrackID is the RPLInstanceID of the main DODAG. Longest match rules decide whether a packet is sent along the main DODAG or rerouted in a Track.
プロファイル 7 は、セクション 7.1 で示されているように、保存モードで動作するメイン DODAG にプロファイル 5 を実装します。プロファイル 1 および 2 と同様、TrackID はメイン DODAG の RPLInstanceID です。最長一致ルールにより、パケットがメイン DODAG に沿って送信されるか、トラック内で再ルーティングされるかが決まります。
Profile 8:
プロファイル 8:
Profile 8 is offered in preparation of the RAW work and for use cases where an arbitrary node in the network can afford the same code complexity as the RPL Root in a traditional deployment. It offers a full DODAG visibility to the Track ingress, as specified in Section 7.2, in a Non-Storing Mode main DODAG.
プロファイル 8 は、RAW 作業の準備として、またネットワーク内の任意のノードが従来の展開における RPL ルートと同じコードの複雑さを許容できるユースケースのために提供されます。これは、セクション 7.2 で指定されているように、非保存モードのメイン DODAG で追跡イングレスに対する完全な DODAG 可視性を提供します。
Profile 9:
プロファイル 9:
Profile 9 combines Profiles 7 and 8, operating the Track as a full DODAG within a Storing Mode main DODAG, using only the main DODAG RPLInstanceID as the TrackID.
プロファイル 9 はプロファイル 7 と 8 を組み合わせたもので、メイン DODAG RPLInstanceID のみをトラック ID として使用し、ストレージ モードのメイン DODAG 内の完全な DODAG としてトラックを操作します。
This specification can operate in a mixed network where some nodes support it and some do not. There are restrictions, though. All nodes that need to process a P-DAO MUST support this specification. As discussed in Section 3.7.1, how the Root knows the node capabilities and whether they support this specification are out of scope.
この仕様は、一部のノードがサポートし、一部のノードがサポートしていない混合ネットワークでも動作できます。ただし制限があります。P-DAO を処理する必要があるすべてのノードは、この仕様をサポートしなければなりません (MUST)。セクション 3.7.1 で説明したように、ルートがノードの機能をどのように認識するか、およびルートがこの仕様をサポートしているかどうかは範囲外です。
This specification defines the 'D' flag in the RPL DODAG Configuration option (see Section 4.1.7) to signal that the RPL nodes can request the creation of Tracks. The requester may not know whether the Track can effectively be constructed or whether enough nodes along the preferred paths support this specification. Therefore, it makes sense to only set the 'D' flags in the DIO when the conditions for success are in place, in particular when all the nodes that could be on the path of the Tracks are upgraded.
この仕様では、RPL DODAG 構成オプション (セクション 4.1.7 を参照) で「D」フラグを定義し、RPL ノードがトラックの作成を要求できることを示します。要求者は、トラックを効果的に構築できるかどうか、または優先パスに沿った十分なノードがこの仕様をサポートしているかどうかを知らない可能性があります。したがって、成功の条件が整っている場合、特にトラックのパス上にある可能性のあるすべてのノードがアップグレードされる場合にのみ、DIO に「D」フラグを設定するのが合理的です。
It is worth noting that per [RPL], every node in the LLN is RPL-aware and can inject any RPL-based attack in the network. This specification uses messages that are already present in RPL [RPL] with optional secured versions. The same secured versions may be used with this specification, and whatever security is deployed for a given network also applies to the flows in this specification.
[RPL] に従って、LLN 内のすべてのノードが RPL を認識し、ネットワークに RPL ベースの攻撃を注入できることに注意してください。この仕様では、RPL [RPL] にすでに存在するメッセージを、オプションの保護されたバージョンとともに使用します。この仕様では同じセキュリティで保護されたバージョンを使用でき、特定のネットワークに展開されているセキュリティはすべて、この仕様のフローにも適用されます。
The LLN nodes depend on the RPL Root and RANs for their operation. A trust model is necessary to ensure that the right devices are acting in these roles, avoiding sinkhole attacks (as is done in Section 7 of [RFC7416]). This trust model could be, at a minimum, based on a Layer 2 secure joining and link-layer security. This is a generic 6LoWPAN requirement; see Req-5.1 in Appendix B.5 of [RFC8505].
LLN ノードは、その動作に関して RPL ルートと RAN に依存します。信頼モデルは、適切なデバイスがこれらの役割で動作していることを保証し、([RFC7416] のセクション 7 で行われているように) シンクホール攻撃を回避するために必要です。この信頼モデルは、少なくとも、レイヤ 2 の安全な結合とリンク層のセキュリティに基づくことができます。これは一般的な 6LoWPAN 要件です。[RFC8505] の付録 B.5 の Req-5.1 を参照してください。
In a general manner, the Security Considerations in [RPL] and [RFC7416] apply to this specification as well. In particular, link-layer security is needed to prevent denial-of-service attacks, whereby a rogue router creates a high churn in the RPL network by constantly injecting forged P-DAO messages and using up all the available storage in the attacked routers.
一般的に、[RPL] および [RFC7416] のセキュリティに関する考慮事項は、この仕様にも適用されます。特に、サービス拒否攻撃を防ぐには、リンク層のセキュリティが必要です。サービス拒否攻撃では、不正なルーターが、偽造した P-DAO メッセージを絶えず挿入し、攻撃されたルーターで利用可能なストレージをすべて使い果たすことで、RPL ネットワークに大きな混乱を引き起こします。
When applied to radio LLNs such as IEEE Std 802.15.4, the lower-layer frame protection can be leveraged with an appropriate join protocol. The 6TiSCH Constrained Join Protocol (CoJP) [RFC9031] uses the RPL Root as 6LBR. The join protocol could be extended to provide additional key material for pledges to 6LBR communication when additional end-to-end security is desired beyond the hop-by-hop security from the lower layer.
IEEE Std 802.15.4 などの無線 LLN に適用すると、適切な参加プロトコルを使用して下位層のフレーム保護を活用できます。6TiSCH Constrained Join Protocol (CoJP) [RFC9031] は、RPL ルートを 6LBR として使用します。下位層からのホップバイホップのセキュリティを超えて追加のエンドツーエンドのセキュリティが必要な場合、参加プロトコルを拡張して、6LBR 通信へのプレッジに追加の鍵マテリアルを提供することができます。
With this specification, the Root MAY generate P-DAO messages but other nodes MUST NOT do so. P-DAO-REQ messages MUST be sent to the Root. This specification expects that the communication with the Root is authenticated but does not enforce which method is used.
この仕様では、ルートは P-DAO メッセージを生成してもよいですが、他のノードは生成してはなりません (MUST NOT)。P-DAO-REQ メッセージはルートに送信されなければなりません。この仕様では、ルートとの通信が認証されることを想定していますが、どの方法が使用されるかは強制されません。
Additionally, the trust model could include a role validation (e.g., using a role-based authorization) to ensure that the node that claims to be a RPL Root is entitled to do so. That trust should propagate from egress to ingress in the case of a Storing Mode P-DAO.
さらに、信頼モデルには、RPL ルートであると主張するノードにそうする資格があることを確認するための役割検証 (たとえば、役割ベースの承認の使用) を含めることができます。ストレージ モード P-DAO の場合、その信頼は出力から入力に伝播する必要があります。
This specification suggests some validation of the VIO to prevent basic loops, i.e., by avoiding a node that appears twice. But that is only a minimal protection. Arguably, an attacker that can inject P-DAOs can reroute any traffic and rapidly deplete critical resources such as the spectrum and battery in the LLN.
この仕様では、基本的なループを防止するために、つまり 2 回出現するノードを避けるために、VIO を何らかの検証することを提案しています。しかし、それは最小限の保護にすぎません。おそらく、P-DAO を挿入できる攻撃者は、あらゆるトラフィックのルーティングを変更し、LLN 内のスペクトルやバッテリーなどの重要なリソースを急速に枯渇させることができます。
IANA has assigned a flag in the "DODAG Configuration Option Flags for MOP 0..6" registry [RFC9008] under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL] as follows:
IANA は、「Routing Protocol for Low Power and Lossy Networks (RPL)」レジストリ グループ [IANA-RPL] の下の「DODAG Configuration Option Flags for MOP 0..6」レジストリ [RFC9008] に次のようにフラグを割り当てました。
+============+==============================+===========+
| Bit Number | Capability Description | Reference |
+============+==============================+===========+
| 0 | Projected Routes Support (D) | RFC 9914 |
+------------+------------------------------+-----------+
Table 21: New DODAG Configuration Option Flag
表 21: 新しい DODAG 構成オプション フラグ
IANA has added this RFC as an additional reference for MOP 7 in the "Mode of Operation" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL].
IANA は、この RFC を MOP 7 の追加参照として、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下の「動作モード」レジストリに追加しました。
IANA has updated the "Elective 6LoWPAN Routing Header Type" registry [RFC8138] under the "IPv6 Low Power Personal Area Network Parameters" registry group [IANA-6LO] as follows:
IANA は、「IPv6 Low Power Personal Area Network Parameters」レジストリ グループ [IANA-6LO] の下にある「Elective 6LoWPAN Routing Header Type」レジストリ [RFC8138] を次のように更新しました。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 8 | P-RPI-6LoRH | RFC 9914 |
+-------+-------------+-----------+
Table 22: New Elective 6LoWPAN Routing Header Type
表 22: 新しい選択的 6LoWPAN ルーティング ヘッダー タイプ
IANA has updated the "Critical 6LoWPAN Routing Header Type" registry [RFC8138] under the "IPv6 Low Power Personal Area Network Parameters" registry group [IANA-6LO] as follows:
IANA は、「IPv6 Low Power Personal Area Network Parameters」レジストリ グループ [IANA-6LO] の下にある「Critical 6LoWPAN Routing Header Type」レジストリ [RFC8138] を次のように更新しました。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 8 | P-RPI-6LoRH | RFC 9914 |
+-------+-------------+-----------+
Table 23: New Critical 6LoWPAN Routing Header Type
表 23: 新しいクリティカル 6LoWPAN ルーティング ヘッダー タイプ
IANA has created the "RPL Option Flags" registry, for the 8-bit RPL Option flags field as detailed in Figure 11, under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities:
IANA は、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に、図 11 に示す 8 ビット RPL オプション フラグ フィールド用の「RPL オプション フラグ」レジストリを作成しました。ビットには 0 (左端) から 7 までのインデックスが付けられます。各ビットは次の品質で追跡されます。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとして数えます）
* Indication when set
* 設定時の表示
* Reference
* 参照
The registration procedure is Standards Action [RFC8126]. The initial allocation is as indicated in Table 24:
登録手順は Standards Action [RFC8126] です。初期割り当ては表 24 に示すとおりです。
+============+======================+===========+
| Bit Number | Indication When Set | Reference |
+============+======================+===========+
| 0 | Down (O) | [RFC6553] |
+------------+----------------------+-----------+
| 1 | Rank-Error (R) | [RFC6553] |
+------------+----------------------+-----------+
| 2 | Forwarding-Error (F) | [RFC6553] |
+------------+----------------------+-----------+
| 3 | Projected-Route (P) | RFC 9914 |
+------------+----------------------+-----------+
| 4..255 | Unassigned | |
+------------+----------------------+-----------+
Table 24: Initial P-DAO-REQ Flags
表 24: 初期 P-DAO-REQ フラグ
IANA has updated the "RPL Control Codes" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL] as indicated in Table 25:
IANA は、表 25 に示すように、「Routing Protocol for Low Power and Lossy Networks (RPL)」レジストリ グループ [IANA-RPL] の下の「RPL Control Codes」レジストリを更新しました。
+======+================================================+===========+
| Code | Description | Reference |
+======+================================================+===========+
| 0x09 | Projected DAO Request (P-DAO-REQ) | RFC 9914 |
+------+------------------------------------------------+-----------+
| 0x0A | Projected DAO Request | RFC 9914 |
| | Acknowledgment (PDR-ACK) | |
+------+------------------------------------------------+-----------+
Table 25: New RPL Control Codes
表 25: 新しい RPL 制御コード
IANA has updated the "RPL Control Message Options" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL] as indicated in Table 26:
IANA は、表 26 に示すように、「Routing Protocol for Low Power and Lossy Networks (RPL)」レジストリ グループ [IANA-RPL] の下の「RPL Control Message Options」レジストリを更新しました。
+=======+==============================================+===========+
| Value | Meaning | Reference |
+=======+==============================================+===========+
| 0x0F | Stateful Storing Mode VIO (SM-VIO) | RFC 9914 |
+-------+----------------------------------------------+-----------+
| 0x10 | Source-Routed Non-Storing Mode VIO (NSM-VIO) | RFC 9914 |
+-------+----------------------------------------------+-----------+
| 0x11 | Sibling Information Option (SIO) | RFC 9914 |
+-------+----------------------------------------------+-----------+
Table 26: RPL Control Message Options
表 26: RPL 制御メッセージのオプション
IANA has created the "Projected DAO Request (P-DAO-REQ) Flags" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities:
IANA は、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に「Projected DAO Request (P-DAO-REQ) Flags」レジストリを作成しました。ビットには 0 (左端) から 7 までのインデックスが付けられます。各ビットは次の品質で追跡されます。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとして数えます）
* Capability description
* 機能の説明
* Reference
* 参照
The registration procedure is Standards Action [RFC8126]. The initial allocation is as indicated in Table 27:
登録手順は Standards Action [RFC8126] です。初期割り当ては表 27 に示すとおりです。
+============+========================================+===========+
| Bit Number | Capability Description | Reference |
+============+========================================+===========+
| 0 | PDR-ACK requested (K) | RFC 9914 |
+------------+----------------------------------------+-----------+
| 1 | Requested path should be redundant (R) | RFC 9914 |
+------------+----------------------------------------+-----------+
| 2..255 | Unassigned | |
+------------+----------------------------------------+-----------+
Table 27: Initial P-DAO-REQ Flags
表 27: 初期 P-DAO-REQ フラグ
IANA has created the "Projected DAO Request Acknowledgment (PDR-ACK) Flags" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities:
IANA は、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に「Projected DAO Request Acknowledgment (PDR-ACK) Flags」レジストリを作成しました。ビットには 0 (左端) から 7 までのインデックスが付けられます。各ビットは次の品質で追跡されます。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとして数えます）
* Capability description
* 機能の説明
* Reference
* 参照
The registration procedure is Standards Action [RFC8126]. At the time of publication of this document, no bit has been assigned in this registry.
登録手順は Standards Action [RFC8126] です。このドキュメントの発行時点では、このレジストリにはビットが割り当てられていません。
IANA has created the "PDR-ACK Acceptance Status Values" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL]. Each value is tracked with the following qualities:
IANA は、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に「PDR-ACK Acceptance Status Values」レジストリを作成しました。各値は次の品質で追跡されます。
* Value
* 価値
* Meaning
* 意味
* Reference
* 参照
The possible values are expressed as a 6-bit unsigned integer (0..63). The registration procedure is Standards Action [RFC8126]. The initial allocation is as indicated in Table 28:
可能な値は 6 ビットの符号なし整数 (0..63) として表されます。登録手順は Standards Action [RFC8126] です。初期割り当ては表 28 に示すとおりです。
+=======+========================+===========+
| Value | Meaning | Reference |
+=======+========================+===========+
| 0 | Unqualified Acceptance | RFC 9914 |
+-------+------------------------+-----------+
| 1..63 | Unassigned | |
+-------+------------------------+-----------+
Table 28: Acceptance Values of the PDR-ACK Status
表 28: PDR-ACK ステータスの許容値
IANA has created the "PDR-ACK Rejection Status Values" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL]. Each value is tracked with the following qualities:
IANA は、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に「PDR-ACK Rejection Status Values」レジストリを作成しました。各値は次の品質で追跡されます。
* Value
* 価値
* Meaning
* 意味
* Reference
* 参照
The possible values are expressed as a 6-bit unsigned integer (0..63). The registration procedure is Standards Action [RFC8126]. The initial allocation is as indicated in Table 29:
可能な値は 6 ビットの符号なし整数 (0..63) として表されます。登録手順は Standards Action [RFC8126] です。初期割り当ては表 29 に示すとおりです。
+=======+=======================+===========+
| Value | Meaning | Reference |
+=======+=======================+===========+
| 0 | Unqualified Rejection | RFC 9914 |
+-------+-----------------------+-----------+
| 1 | Transient Failure | RFC 9914 |
+-------+-----------------------+-----------+
| 2..63 | Unassigned | |
+-------+-----------------------+-----------+
Table 29: PDR-ACK Rejection Status Values
表 29: PDR-ACK 拒否ステータスの値
IANA has created the "Via Information Options (VIO) Flags" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities:
IANA は、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に「Via Information Options (VIO) Flags」レジストリを作成しました。ビットには 0 (左端) から 7 までのインデックスが付けられます。各ビットは次の品質で追跡されます。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとして数えます）
* Capability description
* 機能の説明
* Reference
* 参照
The registration procedure is Standards Action [RFC8126]. At the time of publication of this document, no bit has been assigned in this registry (see more in Section 5.3).
登録手順は Standards Action [RFC8126] です。この文書の発行時点では、このレジストリにはビットが割り当てられていません (詳細はセクション 5.3 を参照)。
IANA has created the "Sibling Information Option (SIO) Flags" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to 4. Each bit is tracked with the following qualities:
IANA は、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に「兄弟情報オプション (SIO) フラグ」レジストリを作成しました。ビットには 0 (左端) から 4 までのインデックスが付けられます。各ビットは次の品質で追跡されます。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとして数えます）
* Capability description
* 機能の説明
* Reference
* 参照
The registration procedure is Standards Action [RFC8126]. The initial allocation is as indicated in Table 30 (see more in Figure 17):
登録手順は Standards Action [RFC8126] です。初期割り当ては表 30 に示すとおりです (詳細は図 17 を参照)。
+============+=========================================+===========+
| Bit Number | Capability Description | Reference |
+============+=========================================+===========+
| 0 | 'S' flag: Sibling in same DODAG as self | RFC 9914 |
+------------+-----------------------------------------+-----------+
| 1 | 'B' flag: Connectivity to the sibling | RFC 9914 |
| | is roughly symmetrical | |
+------------+-----------------------------------------+-----------+
| 2..4 | Unassigned | |
+------------+-----------------------------------------+-----------+
Table 30: Initial SIO Flags
表 30: 初期 SIO フラグ
IANA has updated the "Destination Advertisement Object (DAO) Flags" registry, created in Section 20.11 of [RPL], under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL] as indicated in Table 31 (see more in Section 4.1.1):
IANA は、表 31 に示すように、[RPL] のセクション 20.11 で作成された「Destination Advertising Object (DAO) Flags」レジストリを、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に更新しました (詳細はセクション 4.1.1 を参照)。
+============+========================+===========+
| Bit Number | Capability Description | Reference |
+============+========================+===========+
| 2 | Projected DAO (P) | RFC 9914 |
+------------+------------------------+-----------+
Table 31: New Destination Advertisement Object (DAO) Flag
表 31: 新しい宛先アドバタイズメント オブジェクト (DAO) フラグ
IANA has updated the "Destination Advertisement Object (DAO) Acknowledgment Flags" registry, created in Section 20.12 of [RPL], under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL] as indicated in Table 32 (see more in Section 4.1.2):
IANA は、表 32 に示すように、[RPL] のセクション 20.12 で作成された「Destination Advertising Object (DAO) Acknowledgment Flags」レジストリを、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ [IANA-RPL] の下に更新しました (詳細はセクション 4.1.2 を参照)。
+============+==================================+===========+
| Bit Number | Capability Description | Reference |
+============+==================================+===========+
| 1 | Projected DAO Acknowledgment (P) | RFC 9914 |
+------------+----------------------------------+-----------+
Table 32: New Destination Advertisement Object Acknowledgment Flag
表 32: 新しい宛先アドバタイズメントオブジェクト確認フラグ
In some cases, RPL will return an ICMPv6 error message when a message cannot be forwarded along a P-Route.
場合によっては、メッセージを P-Route に沿って転送できない場合、RPL は ICMPv6 エラー メッセージを返します。
Per this specification, IANA has updated the "Type 1 - Destination Unreachable" registry, in the "ICMPv6 'Code' Fields" registry, under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group [IANA-ICMP] as indicated in Table 33.
この仕様に従って、IANA は、表 33 に示すように、「インターネット制御メッセージ プロトコル バージョン 6 (ICMPv6) パラメーター」レジストリ グループ [IANA-ICMP] の下にある「ICMPv6 'Code' Fields」レジストリ内の「Type 1 - Destination Unreachable」レジストリを更新しました。
+======+==================+===========+
| Code | Name | Reference |
+======+==================+===========+
| 9 | Error in P-Route | RFC 9914 |
+------+------------------+-----------+
Table 33: New ICMPv6 Error Code
表 33: 新しい ICMPv6 エラー コード
IANA has updated the "RPL Rejection Status" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group [IANA-RPL] as indicated in Table 34:
IANA は、表 34 に示すように、「Routing Protocol for Low Power and Lossy Networks (RPL)」レジストリ グループ [IANA-RPL] の下の「RPL Rejection Status」レジストリを更新しました。
+=======+=========================+===========+
| Value | Meaning | Reference |
+=======+=========================+===========+
| 2 | Out of Resources | RFC 9914 |
+-------+-------------------------+-----------+
| 3 | Error in VIO | RFC 9914 |
+-------+-------------------------+-----------+
| 4 | Predecessor Unreachable | RFC 9914 |
+-------+-------------------------+-----------+
| 5 | Unreachable Target | RFC 9914 |
+-------+-------------------------+-----------+
| 6..63 | Unassigned | |
+-------+-------------------------+-----------+
Table 34: RPL Rejection Status Values
表 34: RPL 拒否ステータスの値
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes, and IPv6-
in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>.
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.
[RAW-ARCH] Thubert, P., Ed., "Reliable and Available Wireless (RAW)
Architecture", RFC 9912, DOI 10.17487/RFC9912, April 2026,
<https://www.rfc-editor.org/info/rfc9912>.
[INT-ARCH] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On
Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6
Network", RFC 8930, DOI 10.17487/RFC8930, November 2020,
<https://www.rfc-editor.org/info/rfc8930>.
[RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Selective Fragment Recovery",
RFC 8931, DOI 10.17487/RFC8931, November 2020,
<https://www.rfc-editor.org/info/rfc8931>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>.
[RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M.
Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
RFC 9031, DOI 10.17487/RFC9031, May 2021,
<https://www.rfc-editor.org/info/rfc9031>.
[RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration Option for
the 6LoWPAN Routing Header", RFC 9035,
DOI 10.17487/RFC9035, April 2021,
<https://www.rfc-editor.org/info/rfc9035>.
[RFC9450] Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F.
Theoleyre, "Reliable and Available Wireless (RAW) Use
Cases", RFC 9450, DOI 10.17487/RFC9450, August 2023,
<https://www.rfc-editor.org/info/rfc9450>.
[NEW-TAGS] Kühlewind, M. and S. Krishnan, "Definition of new tags for
relations between RFCs", Work in Progress, Internet-Draft,
draft-kuehlewind-rswg-updates-tag-02, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind-
rswg-updates-tag-02>.
[IANA-6LO] IANA, "IPv6 Low Power Personal Area Network Parameters",
<https://www.iana.org/assignments/_6lowpan-parameters>.
[IANA-RPL] IANA, "Routing Protocol for Low Power and Lossy Networks
(RPL)", <https://www.iana.org/assignments/rpl/>.
[IANA-ICMP]
IANA, "Internet Control Message Protocol version 6
(ICMPv6) Parameters",
<https://www.iana.org/assignments/icmpv6-parameters/>.
The authors wish to acknowledge JP. Vasseur, Remy Liubing, James Pylakutty, and Patrick Wetterwald for their contributions to the ideas developed here. Many thanks to Dominique Barthel and S.V.R. Anand for their global contribution to 6TiSCH, RAW, and this RFC, as well as text suggestions that were incorporated. Also, special thanks to Remous-Aris Koutsiamanis, Li Zhao, Dominique Barthel, and Toerless Eckert for their in-depth reviews, with many excellent suggestions that improved the readability and the content of the specification. Many thanks to Remous-Aris Koutsiamanis for his review during WG Last Call and to Maria Ines Robles for her thorough shepherd review. Many thanks to Warren Kumari, Ran Chen, Murray Kucherawy, Roman Danyliw, Klaas Wierenga, Deb Cooley, Éric Vyncke, Gunter Van de Velde, Sue Hares, and John Scudder for their comments and suggestions during the IETF Last Call and IESG review cycle.
著者らは JP に感謝の意を表します。ここで開発されたアイデアへの貢献に対して、Vasseur、Remy Liubing、James Pylakutty、Patrick Wetterwald に感謝します。Dominique Barthel と S.V.R. に感謝します。Anand は、6TiSCH、RAW、およびこの RFC への世界的な貢献と、組み込まれたテキストの提案に感謝します。また、読みやすさと仕様の内容を改善する多くの優れた提案を提供してくれた詳細なレビューを提供してくれた Remous-Aris Koutsiamanis、Li Zhao、Dominique Barthel、Toerless Eckert に特に感謝します。WG Last Call 中にレビューをしてくれた Remous-Aris Koutsiamanis と、徹底したシェパード レビューをしてくれた Maria Ines Robles に多大な感謝を申し上げます。IETF Last Call および IESG レビュー サイクル中にコメントと提案をくださった Warren Kumari、Ran Chen、Murray Kucherawy、Roman Danyliw、Klaas Wierenga、Deb Cooley、Éric Vyncke、Gunter Van de Velde、Sue Hares、John Scudder に多大な感謝を申し上げます。
Pascal Thubert (editor)
Independent
06330 Roquefort-les-Pins
France
Email: pascal.thubert@gmail.com
Rahul Arvind Jadhav
AccuKnox
Kundalahalli Village, Whitefield
Bangalore 560037
Karnataka
India
Phone: +91-080-49160700
Email: rahul.ietf@gmail.com
Michael C. Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/