https://tools.ietf.org/wg/roll
Internet Drafts: rollNew Internet Drafts from the ROLL (Routing Over Low power and Lossy networks) Working GroupenSat, 06 Jun 2020 17:24:34 GMT1hourly1970-01-01T00:30+00:0060henrik@levkowetz.comhttp://www.interglacial.com/rss/about.html"Mode of Operation extension" - Rahul Jadhav, Pascal Thubert, Michael Richardsonhttps://tools.ietf.org/html/draft-ietf-roll-mopex-01
2020-06-05, rev -01: RPL allows different mode of operations which allows nodes to have a consensus on the basic primitives that must be supported to join the network. The MOP field in [RFC6550] is of 3 bits and is fast depleting. This document extends the MOP for future use."RPL Capabilities" - Rahul Jadhav, Pascal Thubert, Michael Richardson, Rabi Sahoohttps://tools.ietf.org/html/draft-ietf-roll-capabilities-06
2020-06-03, rev -06: This draft enables the discovery, advertisement and query of capabilities for RPL nodes."RPL Observations" - Rahul Jadhav, Rabi Sahoo, Yuefeng Wuhttps://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04
2020-05-21, rev -04: This document describes RPL protocol design issues, various observations and possible consequences of the design and implementation choices."Root initiated routing state in RPL" - Pascal Thubert, Rahul Jadhav, Matthew Gillmorehttps://tools.ietf.org/html/draft-ietf-roll-dao-projection-10
2020-05-11, rev -10: This document enables a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a source-route header or in terms of path length, which impacts both the latency and the packet delivery ratio. Projected Routes may be installed in either Storing and Non-Storing Modes Instances of the classical RPL operation, resulting in potentially hybrid situations where the mode of some Projected Routes is different from that of the other routes in the RPL Instance."AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low-Power and Lossy Networks" - Satish Anamalamudi, Mingui Zhang, Charles Perkins, S.V.R Anand, Bing Liuhttps://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-08
2020-05-07, rev -08: Route discovery for symmetric and asymmetric Point-to-Point (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric."Enabling secure network enrollment in RPL networks" - Michael Richardsonhttps://tools.ietf.org/html/draft-ietf-roll-enrollment-priority-02
2020-04-25, rev -02: [I-D.ietf-6tisch-enrollment-enhanced-beacon] defines a method by which a potential [I-D.ietf-6tisch-minimal-security] join proxy can announce itself as a available for new Pledges to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a RPL DODAG root can disable enrollment announcements, or adjust the base priority for enrollment operation."A RPL Configuration Option for the 6LoWPAN Routing Header" - Pascal Thubert, Li Zhaohttps://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-07
2020-04-17, rev -07: This document updates RFC 8138 and RFC 6550 by defining a bit in the RPL configuration option to indicate whether RFC 8138 compression is used within the RPL Instance, and specify the behavior of RFC 8138-capable nodes when the bit is set and reset."Efficient Route Invalidation" - Rahul Jadhav, Pascal Thubert, Rabi Sahoo, Zhen Caohttps://tools.ietf.org/html/draft-ietf-roll-efficient-npdao-18
2020-04-15, rev -18: This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging."Routing for RPL Leaves" - Pascal Thubert, Michael Richardsonhttps://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15
2020-04-15, rev -15: This specification extends RFC6550 and RFC8505 to provide routing services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND but do not participate to RPL. This specification also enables the RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG."Common Ancestor Objective Function and Parent Set DAG Metric Container Extension" - Remous-Aris Koutsiamanis, Georgios Papadopoulos, Nicolas Montavont, Pascal Thuberthttps://tools.ietf.org/html/draft-ietf-roll-nsa-extension-08
2020-03-27, rev -08: Packet Replication and Elimination is a method in which several copies of a data packet are sent in the network in order to achieve high reliability and low jitter. This document details how to apply Packet Replication and Elimination in RPL, especially how to exchange information within RPL control packets to let a node better select the different parents that will be used to forward the multiple copies of a packet. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing."Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane" - Ines Robles, Michael Richardson, Pascal Thuberthttps://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-38
2020-03-23, rev -38: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC6553 (RPI Option Type), RFC6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC6553 adding a change to the RPI Option Type. Additionally, this document updates RFC6550 defining a flag in the DIO Configuration option to indicate about this change and updates [RFC8138] as well to consider the new Option Type when the RPL Option is decompressed.