| < draft-ietf-roll-dao-projection-24.txt | draft-ietf-roll-dao-projection-25.txt > | |||
|---|---|---|---|---|
| ROLL P. Thubert, Ed. | ROLL P. Thubert, Ed. | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Standards Track R.A. Jadhav | Intended status: Standards Track R.A. Jadhav | |||
| Expires: 29 August 2022 Huawei Tech | Expires: 24 September 2022 Huawei Tech | |||
| M. Richardson | M. Richardson | |||
| Sandelman | Sandelman | |||
| 25 February 2022 | 23 March 2022 | |||
| Root initiated routing state in RPL | Root initiated routing state in RPL | |||
| draft-ietf-roll-dao-projection-24 | draft-ietf-roll-dao-projection-25 | |||
| Abstract | Abstract | |||
| This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a | THIS RFC extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL | |||
| RPL Root to install and maintain Projected Routes within its DODAG, | Root to install and maintain Projected Routes within its DODAG, along | |||
| along a selected set of nodes that may or may not include self, for a | a selected set of nodes that may or may not include self, for a | |||
| chosen duration. This potentially enables routes that are more | chosen duration. This potentially enables routes that are more | |||
| optimized or resilient than those obtained with the classical | optimized or resilient than those obtained with the classical | |||
| distributed operation of RPL, either in terms of the size of a | distributed operation of RPL, either in terms of the size of a | |||
| Routing Header or in terms of path length, which impacts both the | Routing Header or in terms of path length, which impacts both the | |||
| latency and the packet delivery ratio. | latency and the packet delivery ratio. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 29 August 2022. | This Internet-Draft will expire on 24 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
| 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5 | 2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 6 | 2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 6 | 2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 6 | 2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 9 | 3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 9 | 3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 10 | |||
| 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 10 | 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 11 | |||
| 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 | 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 11 | 3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 12 | |||
| 3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 13 | 3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 13 | |||
| 3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 14 | 3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 15 | 3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 15 | |||
| 3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 15 | 3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 16 | |||
| 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16 | 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16 | |||
| 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 17 | 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 18 | |||
| 3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24 | 3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24 | |||
| 3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31 | 3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31 | |||
| 3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33 | 3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33 | |||
| 3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33 | 3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33 | |||
| 3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33 | 3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33 | |||
| 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35 | 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35 | |||
| 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35 | 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35 | |||
| 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36 | 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36 | |||
| 4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 38 | 4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 38 | |||
| 4.1.3. Via Information Option . . . . . . . . . . . . . . . 39 | 4.1.3. Via Information Option . . . . . . . . . . . . . . . 39 | |||
| skipping to change at page 3, line 41 ¶ | skipping to change at page 3, line 41 ¶ | |||
| 11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 72 | 11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 72 | |||
| 11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 73 | 11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 73 | |||
| 11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 73 | 11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 73 | |||
| 11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 73 | 11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 73 | |||
| 11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 74 | 11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 74 | |||
| 11.6. RPL Control Message Options . . . . . . . . . . . . . . 74 | 11.6. RPL Control Message Options . . . . . . . . . . . . . . 74 | |||
| 11.7. SubRegistry for the Projected DAO Request Flags . . . . 75 | 11.7. SubRegistry for the Projected DAO Request Flags . . . . 75 | |||
| 11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 75 | 11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 75 | |||
| 11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 76 | 11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 76 | |||
| 11.10. Subregistry for the PDR-ACK Rejection Status Values . . 76 | 11.10. Subregistry for the PDR-ACK Rejection Status Values . . 76 | |||
| 11.11. SubRegistry for the Via Information Options Flags . . . 76 | 11.11. SubRegistry for the Via Information Options Flags . . . 77 | |||
| 11.12. SubRegistry for the Sibling Information Option Flags . . 77 | 11.12. SubRegistry for the Sibling Information Option Flags . . 77 | |||
| 11.13. Destination Advertisement Object Flag . . . . . . . . . 77 | 11.13. Destination Advertisement Object Flag . . . . . . . . . 77 | |||
| 11.14. Destination Advertisement Object Acknowledgment Flag . . 78 | 11.14. Destination Advertisement Object Acknowledgment Flag . . 78 | |||
| 11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 78 | 11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 78 | |||
| 11.16. RPL Rejection Status values . . . . . . . . . . . . . . 78 | 11.16. RPL Rejection Status values . . . . . . . . . . . . . . 78 | |||
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 | |||
| 13. Normative References . . . . . . . . . . . . . . . . . . . . 79 | 13. Normative References . . . . . . . . . . . . . . . . . . . . 79 | |||
| 14. Informative References . . . . . . . . . . . . . . . . . . . 81 | 14. Informative References . . . . . . . . . . . . . . . . . . . 81 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 | |||
| skipping to change at page 4, line 44 ¶ | skipping to change at page 4, line 44 ¶ | |||
| extensions that enable the Root to translates the computed paths into | extensions that enable the Root to translates the computed paths into | |||
| RPL and install them as Projected Routes (aka P-Routes) inside the | RPL and install them as Projected Routes (aka P-Routes) inside the | |||
| DODAG on behalf of a PCE. | DODAG on behalf of a PCE. | |||
| 2. Terminology | 2. Terminology | |||
| 2.1. Requirements Language | 2.1. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in THIS RFC are to be interpreted as described in BCP 14 | |||
| 14 [RFC2119][RFC8174] when, and only when, they appear in all | [RFC2119][RFC8174] when, and only when, they appear in all capitals, | |||
| capitals, as shown here. | as shown here. | |||
| In addition, the terms "Extends" and "Amends" are used as per | In addition, the terms "Extends" and "Amends" are used as per | |||
| [I-D.kuehlewind-update-tag] section 3. | [I-D.kuehlewind-update-tag] section 3. | |||
| 2.2. References | 2.2. References | |||
| In this document, readers will encounter terms and concepts that are | In THIS RFC, readers will encounter terms and concepts that are | |||
| discussed in the "Routing Protocol for Low Power and Lossy Networks" | discussed in the "Routing Protocol for Low Power and Lossy Networks" | |||
| [RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic | [RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic | |||
| Networking Architecture" [RFC8655], the "Reliable and Available | Networking Architecture" [RFC8655], the "Reliable and Available | |||
| Wireless (RAW) Architecture" [RAW-ARCHI], and "Terminology in Low | Wireless (RAW) Architecture" [RAW-ARCHI], and "Terminology in Low | |||
| power And Lossy Networks" [RFC7102]. | power And Lossy Networks" [RFC7102]. | |||
| 2.3. Glossary | 2.3. Glossary | |||
| This document often uses the following acronyms: | THIS RFC often uses the following acronyms: | |||
| CMO: Control Message Option | CMO: Control Message Option | |||
| DAO: destination Advertisement Object | DAO: destination Advertisement Object | |||
| DAG: Directed Acyclic Graph | DAG: Directed Acyclic Graph | |||
| DODAG: destination-Oriented Directed Acyclic Graph; A DAG with only | DODAG: destination-Oriented Directed Acyclic Graph; A DAG with only | |||
| one vertex (i.e., node) that has no outgoing edge (i.e., link) | one vertex (i.e., node) that has no outgoing edge (i.e., link) | |||
| GUA: IPv6 Global Unicast Address | GUA: IPv6 Global Unicast Address | |||
| LLN: Low-Power and Lossy Network | LLN: Low-Power and Lossy Network | |||
| MOP: RPL Mode of Operation | MOP: RPL Mode of Operation | |||
| P-DAO: Projected DAO | P-DAO: Projected DAO | |||
| skipping to change at page 8, line 27 ¶ | skipping to change at page 8, line 27 ¶ | |||
| A single P-DAO that fully defines a Track, e.g., a Serial Track | A single P-DAO that fully defines a Track, e.g., a Serial Track | |||
| installed with a single Storing Mode Via Information option (SM-VIO). | installed with a single Storing Mode Via Information option (SM-VIO). | |||
| 2.4.5.5. Stitching | 2.4.5.5. Stitching | |||
| This specification using the term stitching to indicate that a track | This specification using the term stitching to indicate that a track | |||
| is piped to another one, meaning that traffic out of the first is | is piped to another one, meaning that traffic out of the first is | |||
| injected in the other. | injected in the other. | |||
| 2.4.5.6. subTrack | 2.4.5.6. Leg | |||
| A Track within a Track. As the Non-Storing Mode Via Information | An end-to-end East-West serial path. A leg can be a serial Track by | |||
| option (NSM-VIO) can only signal a loose sequence of nodes, it takes | itself or a subTrack of a complex Track with the same Ingress and | |||
| a number of them to signal a complex Track. Each NSM-VIO for the | Egress Nodes. With this specification, a Leg is is installed by the | |||
| same TrackId but a different Segment ID signals a different subTracks | Root of the main DODAG using a Non-Storing Mode P-DAO message, and it | |||
| that the Track Ingress adds to the topology. | is expressed as a loose sequence of nodes that are joined by Track | |||
| Segments. | ||||
| 2.4.5.7. Leg | 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 Leg to signal the structure of a complex Track. | ||||
| An end-to-end East-West serial path that can be a Track by itself or | Each NSM-VIO for the same TrackId but a different Segment ID signals | |||
| a subTrack of a complex Track. With this specification, a Leg is is | a different leg that the Track Ingress adds to the topology. | |||
| installed by the Root of the main DODAG using Non-Storing Mode P-DAO | ||||
| messages, and it is expressed as a loose sequence of nodes that are | 2.4.5.7. subTrack | |||
| joined by Track Segments. | ||||
| A Track within a Track, formed by a non-empty collection of Legs of | ||||
| the Track. | ||||
| 2.4.5.8. Segment | 2.4.5.8. Segment | |||
| A serial path formed by a strict sequence of nodes, along which a | A serial path formed by a strict sequence of nodes, along which a | |||
| P-Route is installed. With this specification, a Segment is | P-Route is installed. With this specification, a Segment is | |||
| typically installed by the Root of the main DODAG using Storing Mode | typically installed by the Root of the main DODAG using Storing Mode | |||
| P-DAO messages. A Segment used as the topological edge of a Track. | P-DAO messages. A Segment is used as the topological edge of a Track | |||
| joining the loose steps along the Legs that form the structure of a | ||||
| complex Track. The same segment may be leveraged by more than one | ||||
| Leg where the Legs overlap. | ||||
| Since this specification builds only DODAGs, all Segments are | Since this specification builds only DODAGs, all Segments are | |||
| oriented from Ingress (East) to Egress (West), as opposed to the | oriented from Ingress (East) to Egress (West), as opposed to the | |||
| general RAW model, which allows North/South Segments that can be | general Track model in the RAW Architecture [RAW-ARCHI], which allows | |||
| bidirectional. | North/South Segments that can be bidirectional as well. | |||
| 2.4.5.8.1. Section of a Segment | 2.4.5.8.1. Section of a Segment | |||
| A continuous subset of a segment that may be replaced while the | 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 | 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 | 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. | segment may be replaced by B=>C'=>D'=>E to route around the problem. | |||
| The segment becomes A=>B=>C'=>D'=>E=>F. | The segment becomes A=>B=>C'=>D'=>E=>F. | |||
| 2.4.5.8.2. Segment Routing and SRH | 2.4.5.8.2. Segment Routing and SRH | |||
| skipping to change at page 33, line 15 ¶ | skipping to change at page 33, line 15 ¶ | |||
| till node B and congruent with Leg 2 from node H on, abstracting | till node B and congruent with Leg 2 from node H on, abstracting | |||
| Segment 5 as an East-West Segment. | Segment 5 as an East-West Segment. | |||
| 3.7. Scope and Expectations | 3.7. Scope and Expectations | |||
| 3.7.1. External Dependencies | 3.7.1. External Dependencies | |||
| This specification expects that the RPL Main DODAG is operated in RPL | This specification expects that the RPL Main DODAG is operated in RPL | |||
| Non-Storing Mode to sustain the exchanges with the Root. Based on | Non-Storing Mode to sustain the exchanges with the Root. Based on | |||
| its comprehensive knowledge of the parent-child relationship, the | its comprehensive knowledge of the parent-child relationship, the | |||
| Root can form an abstracted view of the whole DODAG topology. This | Root can form an abstracted view of the whole DODAG topology. THIS | |||
| document adds the capability for nodes to advertise additional | RFC adds the capability for nodes to advertise additional sibling | |||
| sibling information to complement the topological awareness of the | information to complement the topological awareness of the Root to be | |||
| Root to be passed on to the PCE, and enable the PCE to build more / | passed on to the PCE, and enable the PCE to build more / better paths | |||
| better paths that traverse those siblings. | that traverse those siblings. | |||
| P-Routes require resources such as routing table space in the routers | 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 | 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 | 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 | amount of rerouted traffic must fit within the capabilities of the | |||
| transmission links. The methods used to learn the node capabilities | transmission links. The methods used to learn the node capabilities | |||
| and the resources that are available in the devices and in the | and the resources that are available in the devices and in the | |||
| network are out of scope for this document. The method to capture | network are out of scope for THIS RFC. The method to capture and | |||
| and report the LLN link capacity and reliability statistics are also | report the LLN link capacity and reliability statistics are also out | |||
| out of scope. They may be fetched from the nodes through network | of scope. They may be fetched from the nodes through network | |||
| management functions or other forms of telemetry such as OAM. | management functions or other forms of telemetry such as OAM. | |||
| 3.7.2. Positioning vs. Related IETF Standards | 3.7.2. Positioning vs. Related IETF Standards | |||
| 3.7.2.1. Extending 6TiSCH | 3.7.2.1. Extending 6TiSCH | |||
| The "6TiSCH Architecture" [RFC9030] leverages a centralized model | The "6TiSCH Architecture" [RFC9030] leverages a centralized model | |||
| that is similar to that of "Deterministic Networking Architecture" | that is similar to that of "Deterministic Networking Architecture" | |||
| [RFC8655], whereby the device resources and capabilities are exposed | [RFC8655], whereby the device resources and capabilities are exposed | |||
| to an external controller which installs routing states into the | to an external controller which installs routing states into the | |||
| skipping to change at page 36, line 30 ¶ | skipping to change at page 36, line 30 ¶ | |||
| 4.1.1. Projected DAO | 4.1.1. Projected DAO | |||
| Section 6 of [RPL] introduces the RPL Control Message Options (CMO), | Section 6 of [RPL] introduces the RPL Control Message Options (CMO), | |||
| including the RPL Target Option (RTO) and Transit Information Option | including the RPL Target Option (RTO) and Transit Information Option | |||
| (TIO), which can be placed in RPL messages such as the destination | (TIO), which can be placed in RPL messages such as the destination | |||
| Advertisement Object (DAO). A DAO message signals routing | Advertisement Object (DAO). A DAO message signals routing | |||
| information to one or more Targets indicated in RTOs, providing one | information to one or more Targets indicated in RTOs, providing one | |||
| hop information at a time in the TIO. | hop information at a time in the TIO. | |||
| This document Amends the specification of the DAO to create the P-DAO | THIS RFC Amends the specification of the DAO to create the P-DAO | |||
| message. This Amended DAO is signaled with a new "Projected DAO" (P) | message. This Amended DAO is signaled with a new "Projected DAO" (P) | |||
| flag, see Figure 8. | flag, see Figure 8. | |||
| A Projected DAO (P-DAO) is a special DAO message generated by the | A Projected DAO (P-DAO) is a special DAO message generated by the | |||
| Root to install a P-Route formed of multiple hops in its DODAG. This | Root to install a P-Route formed of multiple hops in its DODAG. This | |||
| provides a RPL-based method to install the Tracks as expected by the | provides a RPL-based method to install the Tracks as expected by the | |||
| 6TiSCH Architecture [RFC9030] as a collection of multiple P-Routes. | 6TiSCH Architecture [RFC9030] as a collection of multiple P-Routes. | |||
| The Root MUST source the P-DAO message with its address that serves | The Root MUST source the P-DAO message with its address that serves | |||
| as DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO | as DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO | |||
| skipping to change at page 38, line 18 ¶ | skipping to change at page 38, line 18 ¶ | |||
| message signals to the Root that a given parent can be used to reach | 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 | a given child. The P-DAO message generalizes the DAO to signal to | |||
| the Track Ingress that a Track for which it is Root can be used to | the Track Ingress that a Track for which it is Root can be used to | |||
| reach children and siblings of the Track Egress. In both cases, | reach children and siblings of the Track Egress. In both cases, | |||
| options may be factorized and multiple RTOs may be present to signal | options may be factorized and multiple RTOs may be present to signal | |||
| a collection of children that can be reached through the parent or | a collection of children that can be reached through the parent or | |||
| the Track, respectively. | the Track, respectively. | |||
| 4.1.2. Projected DAO-ACK | 4.1.2. Projected DAO-ACK | |||
| This document also Amends the DAO-ACK message. The new P flag | THIS RFC also Amends the DAO-ACK message. The new P flag signals the | |||
| signals the projected form. | projected form. | |||
| The format of the P-DAO-ACK message is thus as illustrated in | The format of the P-DAO-ACK message is thus as illustrated in | |||
| Figure 9: | Figure 9: | |||
| 0 1 2 3 | 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 | 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 | | | TrackID |D|P| Reserved | DAOSequence | Status | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| skipping to change at page 39, line 13 ¶ | skipping to change at page 39, line 13 ¶ | |||
| and it is set to 0 otherwise. | and it is set to 0 otherwise. | |||
| The D flag is set to one to signal that the DODAGID field is present. | The D flag is set to one to signal that the DODAGID field is present. | |||
| It may be set to zero if and only if the source address of the P-DAO- | It may be set to zero if and only if the source address of the P-DAO- | |||
| ACK message is set to the IPv6 address that serves as DODAGID and it | ACK message is set to the IPv6 address that serves as DODAGID and it | |||
| MUST be set to one otherwise, meaning that the DODAGID field MUST | MUST be set to one otherwise, meaning that the DODAGID field MUST | |||
| then be present. | then be present. | |||
| 4.1.3. Via Information Option | 4.1.3. Via Information Option | |||
| This document Extends the CMO to create new objects called the Via | THIS RFC Extends the CMO to create new objects called the Via | |||
| Information Options (VIO). The VIOs are the multihop alternative to | Information Options (VIO). The VIOs are the multihop alternative to | |||
| the TIO, more in Section 5.3. One VIO is the stateful Storing Mode | the TIO, 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 | 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 | Track Segment. The other is the Non-Storing Mode VIO (NSM-VIO); the | |||
| NSM-VIO installs a loose source-routed P-Route called a Track Leg at | NSM-VIO installs a loose source-routed P-Route called a Track Leg at | |||
| the Track Ingress, which uses that state to encapsulate a packet | the Track Ingress, which uses that state to encapsulate a packet | |||
| IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress, more | IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress, more | |||
| in Section 6.7. | in Section 6.7. | |||
| A P-DAO contains one or more RTOs to indicate the Target | A P-DAO contains one or more RTOs to indicate the Target | |||
| skipping to change at page 69, line 37 ¶ | skipping to change at page 69, line 37 ¶ | |||
| P-DAO. | P-DAO. | |||
| Note that the Path Sequence and Lifetime in the TIO are selected by | Note that the Path Sequence and Lifetime in the TIO are selected by | |||
| the Root, and that the Target/Transit information tupples in the | the Root, and that the Target/Transit information tupples in the | |||
| P-DAO are not those received by the Root in the DAO messages about | 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 | the said Targets. The Track may follow sibling routes and does not | |||
| need to be congruent with the Main DODAG. | need to be congruent with the Main DODAG. | |||
| 8. Profiles | 8. Profiles | |||
| This document provides a set of tools that may or may not be needed | THIS RFC provides a set of tools that may or may not be needed by an | |||
| by an implementation depending on the type of application it serves. | implementation depending on the type of application it serves. This | |||
| This sections described profiles that can be implemented separately | sections described profiles that can be implemented separately and | |||
| and can be used to discriminate what an implementation can and cannot | can be used to discriminate what an implementation can and cannot do. | |||
| do. This section describes profiles that enable to implement only a | This section describes profiles that enable to implement only a | |||
| portion of this specification to meet a particular use case. | portion of this specification to meet a particular use case. | |||
| Profiles 0 to 2 operate in the Main RPL Instance and do not require | Profiles 0 to 2 operate in the Main RPL Instance and do not require | |||
| the support of local RPL Instances or the indication of the RPL | the support of local RPL Instances or the indication of the RPL | |||
| Instance in the data plane. Profile 3 and above leverage Local RPL | Instance in the data plane. Profile 3 and above leverage Local RPL | |||
| Instances to build arbitrary Tracks Rooted at the Track Ingress and | Instances to build arbitrary Tracks Rooted at the Track Ingress and | |||
| using its namespace for TrackID. | using its namespace for TrackID. | |||
| Profiles 0 and 1 are REQUIRED by all implementations that may be used | Profiles 0 and 1 are REQUIRED by all implementations that may be used | |||
| in LLNs; Profiles 1 leverages Storing Mode to reduce the size of the | in LLNs; Profiles 1 leverages Storing Mode to reduce the size of the | |||
| skipping to change at page 73, line 18 ¶ | skipping to change at page 73, line 18 ¶ | |||
| | 0 (suggested) | Projected Routes Support (D) | THIS RFC | | | 0 (suggested) | Projected Routes Support (D) | THIS RFC | | |||
| +---------------+------------------------------+-----------+ | +---------------+------------------------------+-----------+ | |||
| Table 21: New DODAG Configuration Option Flag | Table 21: New DODAG Configuration Option Flag | |||
| IANA is requested to add [THIS RFC] as a reference for MOP 7 in the | IANA is requested to add [THIS RFC] as a reference for MOP 7 in the | |||
| RPL Mode of Operation registry. | RPL Mode of Operation registry. | |||
| 11.2. Elective 6LoWPAN Routing Header Type | 11.2. Elective 6LoWPAN Routing Header Type | |||
| This document updates the IANA registry titled "Elective 6LoWPAN | THIS RFC updates the IANA registry titled "Elective 6LoWPAN Routing | |||
| Routing Header Type" that was created for [RFC8138] and assigns the | Header Type" that was created for [RFC8138] and assigns the following | |||
| following value: | value: | |||
| +===============+=============+===============+ | +===============+=============+===========+ | |||
| | Value | Description | Reference | | | Value | Description | Reference | | |||
| +===============+=============+===============+ | +===============+=============+===========+ | |||
| | 8 (Suggested) | P-RPI-6LoRH | This document | | | 8 (Suggested) | P-RPI-6LoRH | THIS RFC | | |||
| +---------------+-------------+---------------+ | +---------------+-------------+-----------+ | |||
| Table 22: New Elective 6LoWPAN Routing | Table 22: New Elective 6LoWPAN Routing | |||
| Header Type | Header Type | |||
| 11.3. Critical 6LoWPAN Routing Header Type | 11.3. Critical 6LoWPAN Routing Header Type | |||
| This document updates the IANA registry titled "Critical 6LoWPAN | THIS RFC updates the IANA registry titled "Critical 6LoWPAN Routing | |||
| Routing Header Type" that was created for [RFC8138] and assigns the | Header Type" that was created for [RFC8138] and assigns the following | |||
| following value: | value: | |||
| +===============+=============+===============+ | +===============+=============+===========+ | |||
| | Value | Description | Reference | | | Value | Description | Reference | | |||
| +===============+=============+===============+ | +===============+=============+===========+ | |||
| | 8 (Suggested) | P-RPI-6LoRH | This document | | | 8 (Suggested) | P-RPI-6LoRH | THIS RFC | | |||
| +---------------+-------------+---------------+ | +---------------+-------------+-----------+ | |||
| Table 23: New Critical 6LoWPAN Routing | Table 23: New Critical 6LoWPAN Routing | |||
| Header Type | Header Type | |||
| 11.4. Subregistry For The RPL Option Flags | 11.4. Subregistry For The RPL Option Flags | |||
| IANA is required to create a subregistry for the 8-bit RPL Option | IANA is required to create a subregistry for the 8-bit RPL Option | |||
| Flags field, as detailed in Figure 11, under the "Routing Protocol | Flags field, as detailed in Figure 11, under the "Routing Protocol | |||
| for Low Power and Lossy Networks (RPL)" registry. The bits are | for Low Power and Lossy Networks (RPL)" registry. The bits are | |||
| indexed from 0 (leftmost) to 7. Each bit is Tracked with the | indexed from 0 (leftmost) to 7. Each bit is Tracked with the | |||
| skipping to change at page 74, line 14 ¶ | skipping to change at page 74, line 14 ¶ | |||
| * Bit number (counting from bit 0 as the most significant bit) | * Bit number (counting from bit 0 as the most significant bit) | |||
| * Indication When Set | * Indication When Set | |||
| * Reference | * Reference | |||
| Registration procedure is "Standards Action" [RFC8126]. The initial | Registration procedure is "Standards Action" [RFC8126]. The initial | |||
| allocation is as indicated in Table 27: | allocation is as indicated in Table 27: | |||
| +===============+======================+===============+ | +===============+======================+===========+ | |||
| | Bit number | Indication When Set | Reference | | | Bit number | Indication When Set | Reference | | |||
| +===============+======================+===============+ | +===============+======================+===========+ | |||
| | 0 | Down 'O' | [RFC6553] | | | 0 | Down 'O' | [RFC6553] | | |||
| +---------------+----------------------+---------------+ | +---------------+----------------------+-----------+ | |||
| | 1 | Rank-Error (R) | [RFC6553] | | | 1 | Rank-Error (R) | [RFC6553] | | |||
| +---------------+----------------------+---------------+ | +---------------+----------------------+-----------+ | |||
| | 2 | Forwarding-Error (F) | [RFC6553] | | | 2 | Forwarding-Error (F) | [RFC6553] | | |||
| +---------------+----------------------+---------------+ | +---------------+----------------------+-----------+ | |||
| | 3 (Suggested) | Projected-Route (P) | This document | | | 3 (Suggested) | Projected-Route (P) | THIS RFC | | |||
| +---------------+----------------------+---------------+ | +---------------+----------------------+-----------+ | |||
| Table 24: Initial PDR Flags | Table 24: Initial PDR Flags | |||
| 11.5. RPL Control Codes | 11.5. RPL Control Codes | |||
| This document extends the IANA Subregistry created by RFC 6550 for | THIS RFC extends the IANA Subregistry created by RFC 6550 for RPL | |||
| RPL Control Codes as indicated in Table 25: | Control Codes as indicated in Table 25: | |||
| +==================+=============================+===============+ | +==================+=============================+===========+ | |||
| | Code | Description | Reference | | | Code | Description | Reference | | |||
| +==================+=============================+===============+ | +==================+=============================+===========+ | |||
| | 0x09 (Suggested) | Projected DAO Request (PDR) | This document | | | 0x09 (Suggested) | Projected DAO Request (PDR) | THIS RFC | | |||
| +------------------+-----------------------------+---------------+ | +------------------+-----------------------------+-----------+ | |||
| | 0x0A (Suggested) | PDR-ACK | This document | | | 0x0A (Suggested) | PDR-ACK | THIS RFC | | |||
| +------------------+-----------------------------+---------------+ | +------------------+-----------------------------+-----------+ | |||
| Table 25: New RPL Control Codes | Table 25: New RPL Control Codes | |||
| 11.6. RPL Control Message Options | 11.6. RPL Control Message Options | |||
| This document extends the IANA Subregistry created by RFC 6550 for | THIS RFC extends the IANA Subregistry created by RFC 6550 for RPL | |||
| RPL Control Message Options as indicated in Table 26: | Control Message Options as indicated in Table 26: | |||
| +==================+=============================+===============+ | +==================+=============================+===========+ | |||
| | Value | Meaning | Reference | | | Value | Meaning | Reference | | |||
| +==================+=============================+===============+ | +==================+=============================+===========+ | |||
| | 0x0E (Suggested) | Stateful VIO (SM-VIO) | This document | | | 0x0E (Suggested) | Stateful VIO (SM-VIO) | THIS RFC | | |||
| +------------------+-----------------------------+---------------+ | +------------------+-----------------------------+-----------+ | |||
| | 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | This document | | | 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | THIS RFC | | |||
| +------------------+-----------------------------+---------------+ | +------------------+-----------------------------+-----------+ | |||
| | 0x10 (Suggested) | Sibling Information option | This document | | | 0x10 (Suggested) | Sibling Information option | THIS RFC | | |||
| +------------------+-----------------------------+---------------+ | +------------------+-----------------------------+-----------+ | |||
| Table 26: RPL Control Message Options | Table 26: RPL Control Message Options | |||
| 11.7. SubRegistry for the Projected DAO Request Flags | 11.7. SubRegistry for the Projected DAO Request Flags | |||
| IANA is required to create a registry for the 8-bit Projected DAO | IANA is required to create a registry for the 8-bit Projected DAO | |||
| Request (PDR) Flags field. Each bit is Tracked with the following | Request (PDR) Flags field. Each bit is Tracked with the following | |||
| qualities: | qualities: | |||
| * Bit number (counting from bit 0 as the most significant bit) | * Bit number (counting from bit 0 as the most significant bit) | |||
| * Capability description | * Capability description | |||
| * Reference | * Reference | |||
| Registration procedure is "Standards Action" [RFC8126]. The initial | Registration procedure is "Standards Action" [RFC8126]. The initial | |||
| allocation is as indicated in Table 27: | allocation is as indicated in Table 27: | |||
| +============+========================+===============+ | +============+========================================+===========+ | |||
| | Bit number | Capability description | Reference | | | Bit number | Capability description | Reference | | |||
| +============+========================+===============+ | +============+========================================+===========+ | |||
| | 0 | PDR-ACK request (K) | This document | | | 0 | PDR-ACK request (K) | THIS RFC | | |||
| +------------+------------------------+---------------+ | +------------+----------------------------------------+-----------+ | |||
| | 1 | Requested path should | This document | | | 1 | Requested path should be redundant (R) | THIS RFC | | |||
| | | be redundant (R) | | | +------------+----------------------------------------+-----------+ | |||
| +------------+------------------------+---------------+ | ||||
| Table 27: Initial PDR Flags | Table 27: Initial PDR Flags | |||
| 11.8. SubRegistry for the PDR-ACK Flags | 11.8. SubRegistry for the PDR-ACK Flags | |||
| IANA is required to create an subregistry for the 8-bit PDR-ACK Flags | IANA is required to create an subregistry for the 8-bit PDR-ACK Flags | |||
| field. Each bit is Tracked with the following qualities: | field. Each bit is Tracked with the following qualities: | |||
| * Bit number (counting from bit 0 as the most significant bit) | * Bit number (counting from bit 0 as the most significant bit) | |||
| skipping to change at page 76, line 18 ¶ | skipping to change at page 76, line 18 ¶ | |||
| IANA is requested to create a Subregistry for the PDR-ACK Acceptance | IANA is requested to create a Subregistry for the PDR-ACK Acceptance | |||
| Status values. | Status values. | |||
| * Possible values are 6-bit unsigned integers (0..63). | * Possible values are 6-bit unsigned integers (0..63). | |||
| * Registration procedure is "Standards Action" [RFC8126]. | * Registration procedure is "Standards Action" [RFC8126]. | |||
| * Initial allocation is as indicated in Table 28: | * Initial allocation is as indicated in Table 28: | |||
| +-------+------------------------+---------------+ | +-------+------------------------+-----------+ | |||
| | Value | Meaning | Reference | | | Value | Meaning | Reference | | |||
| +-------+------------------------+---------------+ | +-------+------------------------+-----------+ | |||
| | 0 | Unqualified Acceptance | This document | | | 0 | Unqualified Acceptance | THIS RFC | | |||
| +-------+------------------------+---------------+ | +-------+------------------------+-----------+ | |||
| Table 28: Acceptance values of the PDR-ACK Status | Table 28: Acceptance values of the PDR-ACK | |||
| Status | ||||
| 11.10. Subregistry for the PDR-ACK Rejection Status Values | 11.10. Subregistry for the PDR-ACK Rejection Status Values | |||
| IANA is requested to create a Subregistry for the PDR-ACK Rejection | IANA is requested to create a Subregistry for the PDR-ACK Rejection | |||
| Status values. | Status values. | |||
| * Possible values are 6-bit unsigned integers (0..63). | * Possible values are 6-bit unsigned integers (0..63). | |||
| * Registration procedure is "Standards Action" [RFC8126]. | * Registration procedure is "Standards Action" [RFC8126]. | |||
| * Initial allocation is as indicated in Table 29: | * Initial allocation is as indicated in Table 29: | |||
| +-------+-----------------------+---------------+ | +-------+-----------------------+-----------+ | |||
| | Value | Meaning | Reference | | | Value | Meaning | Reference | | |||
| +-------+-----------------------+---------------+ | +-------+-----------------------+-----------+ | |||
| | 0 | Unqualified Rejection | This document | | | 0 | Unqualified Rejection | THIS RFC | | |||
| +-------+-----------------------+---------------+ | +-------+-----------------------+-----------+ | |||
| | 1 | Transient Failure | This document | | | 1 | Transient Failure | THIS RFC | | |||
| +-------+-----------------------+---------------+ | +-------+-----------------------+-----------+ | |||
| Table 29: Rejection values of the PDR-ACK Status | Table 29: Rejection values of the PDR-ACK | |||
| Status | ||||
| 11.11. SubRegistry for the Via Information Options Flags | 11.11. SubRegistry for the Via Information Options Flags | |||
| IANA is requested to create a Subregistry for the 5-bit Via | IANA is requested to create a Subregistry for the 5-bit Via | |||
| Information Options (Via Information Option) Flags field. Each bit | Information Options (Via Information Option) Flags field. Each bit | |||
| is Tracked with the following qualities: | is Tracked with the following qualities: | |||
| * Bit number (counting from bit 0 as the most significant bit) | * Bit number (counting from bit 0 as the most significant bit) | |||
| * Capability description | * Capability description | |||
| skipping to change at page 77, line 33 ¶ | skipping to change at page 77, line 39 ¶ | |||
| * Capability description | * Capability description | |||
| * Reference | * Reference | |||
| Registration procedure is "Standards Action" [RFC8126]. The initial | Registration procedure is "Standards Action" [RFC8126]. The initial | |||
| allocation is as indicated in Table 30: | allocation is as indicated in Table 30: | |||
| +===============+========================+===========+ | +===============+========================+===========+ | |||
| | Bit number | Capability description | Reference | | | Bit number | Capability description | Reference | | |||
| +===============+========================+===========+ | +===============+========================+===========+ | |||
| | 0 (Suggested) | "S" flag: Sibling in | This | | | 0 (Suggested) | "S" flag: Sibling in | THIS RFC | | |||
| | | same DODAG as Self | document | | | | same DODAG as Self | | | |||
| +---------------+------------------------+-----------+ | +---------------+------------------------+-----------+ | |||
| Table 30: Initial SIO Flags | Table 30: Initial SIO Flags | |||
| 11.13. Destination Advertisement Object Flag | 11.13. Destination Advertisement Object Flag | |||
| This document modifies the "Destination Advertisement Object (DAO) | THIS RFC modifies the "Destination Advertisement Object (DAO) Flags" | |||
| Flags" registry initially created in Section 20.11 of [RPL] . | registry initially created in Section 20.11 of [RPL] . | |||
| Section 4.1.1 also defines one new entry in the Registry as follows: | Section 4.1.1 also defines one new entry in the Registry as follows: | |||
| +---------------+------------------------+-----------+ | +---------------+------------------------+-----------+ | |||
| | Bit Number | Capability Description | Reference | | | Bit Number | Capability Description | Reference | | |||
| +---------------+------------------------+-----------+ | +---------------+------------------------+-----------+ | |||
| | 2 (Suggested) | Projected DAO (P) | THIS RFC | | | 2 (Suggested) | Projected DAO (P) | THIS RFC | | |||
| +---------------+------------------------+-----------+ | +---------------+------------------------+-----------+ | |||
| Table 31: New Destination Advertisement Object | Table 31: New Destination Advertisement Object | |||
| (DAO) Flag | (DAO) Flag | |||
| 11.14. Destination Advertisement Object Acknowledgment Flag | 11.14. Destination Advertisement Object Acknowledgment Flag | |||
| This document modifies the "Destination Advertisement Object (DAO) | THIS RFC modifies the "Destination Advertisement Object (DAO) | |||
| Acknowledgment Flags" registry initially created in Section 20.12 of | Acknowledgment Flags" registry initially created in Section 20.12 of | |||
| [RPL] . | [RPL] . | |||
| Section 4.1.2 also defines one new entry in the Registry as follows: | Section 4.1.2 also defines one new entry in the Registry as follows: | |||
| +---------------+------------------------+-----------+ | +---------------+------------------------+-----------+ | |||
| | Bit Number | Capability Description | Reference | | | Bit Number | Capability Description | Reference | | |||
| +---------------+------------------------+-----------+ | +---------------+------------------------+-----------+ | |||
| | 1 (Suggested) | Projected DAO-ACK (P) | THIS RFC | | | 1 (Suggested) | Projected DAO-ACK (P) | THIS RFC | | |||
| +---------------+------------------------+-----------+ | +---------------+------------------------+-----------+ | |||
| skipping to change at page 79, line 26 ¶ | skipping to change at page 79, line 26 ¶ | |||
| | 6..63 | Unassigned | | | | 6..63 | Unassigned | | | |||
| +---------------+-------------------------+-----------+ | +---------------+-------------------------+-----------+ | |||
| Table 33: Rejection values of the RPL Status | Table 33: Rejection values of the RPL Status | |||
| 12. Acknowledgments | 12. Acknowledgments | |||
| The authors wish to acknowledge JP Vasseur, Remy Liubing, James | The authors wish to acknowledge JP Vasseur, Remy Liubing, James | |||
| Pylakutty, and Patrick Wetterwald for their contributions to the | Pylakutty, and Patrick Wetterwald for their contributions to the | |||
| ideas developed here. Many thanks to Dominique Barthel and SVR Anand | ideas developed here. Many thanks to Dominique Barthel and SVR Anand | |||
| for their global contribution to 6TiSCH, RAW and this document, as | for their global contribution to 6TiSCH, RAW and this RFC, as well as | |||
| well as text suggestions that were incorporated. Also special thanks | text suggestions that were incorporated. Also special thanks Li Zhao | |||
| Toerless Eckert for his deep review, with many excellent suggestions | and Toerless Eckert for their in-depth reviews, with many excellent | |||
| that improved the readability and well as the content of the | suggestions that improved the readability and well as the content of | |||
| specification. Many thanks to Remous-Aris Koutsiamanis for his | the specification. Many thanks to Remous-Aris Koutsiamanis for his | |||
| review during WGLC. | review during WGLC. | |||
| 13. Normative References | 13. Normative References | |||
| [INT-ARCHI] | [INT-ARCHI] | |||
| Braden, R., Ed., "Requirements for Internet Hosts - | Braden, R., Ed., "Requirements for Internet Hosts - | |||
| Communication Layers", STD 3, RFC 1122, | Communication Layers", STD 3, RFC 1122, | |||
| DOI 10.17487/RFC1122, October 1989, | DOI 10.17487/RFC1122, October 1989, | |||
| <https://www.rfc-editor.org/info/rfc1122>. | <https://www.rfc-editor.org/info/rfc1122>. | |||
| skipping to change at page 83, line 8 ¶ | skipping to change at page 83, line 8 ¶ | |||
| [RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- | [RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- | |||
| Power and Lossy Networks (RPL) Destination-Oriented | Power and Lossy Networks (RPL) Destination-Oriented | |||
| Directed Acyclic Graph (DODAG) Configuration Option for | Directed Acyclic Graph (DODAG) Configuration Option for | |||
| the 6LoWPAN Routing Header", RFC 9035, | the 6LoWPAN Routing Header", RFC 9035, | |||
| DOI 10.17487/RFC9035, April 2021, | DOI 10.17487/RFC9035, April 2021, | |||
| <https://www.rfc-editor.org/info/rfc9035>. | <https://www.rfc-editor.org/info/rfc9035>. | |||
| [RAW-ARCHI] | [RAW-ARCHI] | |||
| Thubert, P. and G. Z. Papadopoulos, "Reliable and | Thubert, P. and G. Z. Papadopoulos, "Reliable and | |||
| Available Wireless Architecture", Work in Progress, | Available Wireless Architecture", Work in Progress, | |||
| Internet-Draft, draft-ietf-raw-architecture-03, 14 January | Internet-Draft, draft-ietf-raw-architecture-04, 4 March | |||
| 2022, <https://datatracker.ietf.org/doc/html/draft-ietf- | 2022, <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
| raw-architecture-03>. | raw-architecture-04>. | |||
| [USE-CASES] | [USE-CASES] | |||
| Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. | Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. | |||
| Theoleyre, "RAW use-cases", Work in Progress, Internet- | Theoleyre, "RAW use-cases", Work in Progress, Internet- | |||
| Draft, draft-ietf-raw-use-cases-05, 23 February 2022, | Draft, draft-ietf-raw-use-cases-05, 23 February 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- | <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- | |||
| cases-05>. | cases-05>. | |||
| [I-D.kuehlewind-update-tag] | [I-D.kuehlewind-update-tag] | |||
| Kuehlewind, M. and S. Krishnan, "Definition of new tags | Kuehlewind, M. and S. Krishnan, "Definition of new tags | |||
| for relations between RFCs", Work in Progress, Internet- | for relations between RFCs", Work in Progress, Internet- | |||
| Draft, draft-kuehlewind-update-tag-04, 12 July 2021, | Draft, draft-kuehlewind-update-tag-04, 12 July 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-kuehlewind- | <https://datatracker.ietf.org/doc/html/draft-kuehlewind- | |||
| update-tag-04>. | update-tag-04>. | |||
| [I-D.irtf-panrg-path-properties] | [I-D.irtf-panrg-path-properties] | |||
| Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path | Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path | |||
| Properties", Work in Progress, Internet-Draft, draft-irtf- | Properties", Work in Progress, Internet-Draft, draft-irtf- | |||
| panrg-path-properties-04, 25 October 2021, | panrg-path-properties-05, 7 March 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-irtf-panrg- | <https://datatracker.ietf.org/doc/html/draft-irtf-panrg- | |||
| path-properties-04>. | path-properties-05>. | |||
| [PCE] IETF, "Path Computation Element", | [PCE] IETF, "Path Computation Element", | |||
| <https://dataTracker.ietf.org/doc/charter-ietf-pce/>. | <https://dataTracker.ietf.org/doc/charter-ietf-pce/>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Pascal Thubert (editor) | Pascal Thubert (editor) | |||
| Cisco Systems, Inc | Cisco Systems, Inc | |||
| Building D | Building D | |||
| 45 Allee des Ormes - BP1200 | 45 Allee des Ormes - BP1200 | |||
| End of changes. 48 change blocks. | ||||
| 136 lines changed or deleted | 146 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||