Root initiated routing state in RPL
draft-ietf-roll-dao-projection-16
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
---|---|---|---|
Authors | Pascal Thubert , Rahul Jadhav , Matthew Gillmore | ||
Last updated | 2021-01-15 | ||
Replaces | draft-thubert-roll-dao-projection | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Associated WG milestone |
|
||
Document shepherd | (None) | ||
IESG | IESG state | I-D Exists | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-roll-dao-projection-16
Internet-Draft DAO Projection January 2021 11.3. New Subregistry For The RPL Option Flags IANA is required to create a subregistry for the 8-bit RPL Option Flags field, as detailed in Figure 2, under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities: * Bit number (counting from bit 0 as the most significant bit) * Indication When Set * Reference Registration procedure is "Standards Action" [RFC8126]. The initial allocation is as indicated in Table 26: +============+======================+===============+ | Bit number | Indication When Set | Reference | +============+======================+===============+ | 0 | Down 'O' | [RFC6553] | +------------+----------------------+---------------+ | 1 | Rank-Error (R) | [RFC6553] | +------------+----------------------+---------------+ | 2 | Forwarding-Error (F) | [RFC6553] | +------------+----------------------+---------------+ | 3 | Projected-Route (P) | This document | +------------+----------------------+---------------+ Table 23: Initial PDR Flags 11.4. New RPL Control Codes This document extends the IANA Subregistry created by RFC 6550 for RPL Control Codes as indicated in Table 24: +======+=============================+===============+ | Code | Description | Reference | +======+=============================+===============+ | 0x09 | Projected DAO Request (PDR) | This document | +------+-----------------------------+---------------+ | 0x0A | PDR-ACK | This document | +------+-----------------------------+---------------+ Table 24: New RPL Control Codes Thubert, et al. Expires 19 July 2021 [Page 40] Internet-Draft DAO Projection January 2021 11.5. New RPL Control Message Options This document extends the IANA Subregistry created by RFC 6550 for RPL Control Message Options as indicated in Table 25: +=======+============================+===============+ | Value | Meaning | Reference | +=======+============================+===============+ | 0x0B | Stateful VIO(SF-VIO) | This document | +-------+----------------------------+---------------+ | 0x0C | Source-Routed VIO(SR-VIO) | This document | +-------+----------------------------+---------------+ | 0x0D | Sibling Information option | This document | +-------+----------------------------+---------------+ Table 25: RPL Control Message Options 11.6. SubRegistry for the Projected DAO Request Flags IANA is required to create a registry for the 8-bit Projected DAO Request (PDR) Flags field. Each bit is tracked with the following qualities: * Bit number (counting from bit 0 as the most significant bit) * Capability description * Reference Registration procedure is "Standards Action" [RFC8126]. The initial allocation is as indicated in Table 26: +============+========================+===============+ | Bit number | Capability description | Reference | +============+========================+===============+ | 0 | PDR-ACK request (K) | This document | +------------+------------------------+---------------+ | 1 | Requested path should | This document | | | be redundant (R) | | +------------+------------------------+---------------+ Table 26: Initial PDR Flags 11.7. SubRegistry for the 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: Thubert, et al. Expires 19 July 2021 [Page 41] Internet-Draft DAO Projection January 2021 * Bit number (counting from bit 0 as the most significant bit) * Capability description * Reference Registration procedure is "Standards Action" [RFC8126]. No bit is currently defined for the PDR-ACK Flags. 11.8. Subregistry for the PDR-ACK Acceptance Status Values IANA is requested to create a Subregistry for the PDR-ACK Acceptance Status values. * Possible values are 6-bit unsigned integers (0..63). * Registration procedure is "Standards Action" [RFC8126]. * Initial allocation is as indicated in Table 27: +-------+------------------------+---------------+ | Value | Meaning | Reference | +-------+------------------------+---------------+ | 0 | Unqualified acceptance | This document | +-------+------------------------+---------------+ Table 27: Acceptance values of the PDR-ACK Status 11.9. Subregistry for the PDR-ACK Rejection Status Values IANA is requested to create a Subregistry for the PDR-ACK Rejection Status values. * Possible values are 6-bit unsigned integers (0..63). * Registration procedure is "Standards Action" [RFC8126]. * Initial allocation is as indicated in Table 28: +-------+-----------------------+---------------+ | Value | Meaning | Reference | +-------+-----------------------+---------------+ | 0 | Unqualified rejection | This document | +-------+-----------------------+---------------+ Table 28: Rejection values of the PDR-ACK Status Thubert, et al. Expires 19 July 2021 [Page 42] Internet-Draft DAO Projection January 2021 11.10. SubRegistry for the Via Information Options Flags IANA is requested to create a Subregistry for the 5-bit Via Information Options (Via Information Option) Flags field. Each bit is tracked with the following qualities: * Bit number (counting from bit 0 as the most significant bit) * Capability description * Reference Registration procedure is "Standards Action" [RFC8126]. No bit is currently defined for the Via Information Options (Via Information Option) Flags. 11.11. SubRegistry for the Sibling Information Option Flags IANA is required to create a registry for the 5-bit Sibling Information Option (SIO) Flags field. Each bit is tracked with the following qualities: * Bit number (counting from bit 0 as the most significant bit) * Capability description * Reference Registration procedure is "Standards Action" [RFC8126]. The initial allocation is as indicated in Table 29: +============+===================================+===============+ | Bit number | Capability description | Reference | +============+===================================+===============+ | 0 | Connectivity is bidirectional (B) | This document | +------------+-----------------------------------+---------------+ Table 29: Initial SIO Flags 11.12. New Destination Advertisement Object Flag This document modifies the "Destination Advertisement Object (DAO) Flags" registry initially created in Section 20.11 of [RPL] . Section 3.1 also defines one new entry in the Registry as follows: Thubert, et al. Expires 19 July 2021 [Page 43] Internet-Draft DAO Projection January 2021 +---------------+------------------------+-----------+ | Bit Number | Capability Description | Reference | +---------------+------------------------+-----------+ | 2 (suggested) | Projected DAO (P) | THIS RFC | +---------------+------------------------+-----------+ Table 30: New Destination Advertisement Object (DAO) Flag 11.13. Error in Projected Route ICMPv6 Code In some cases RPL will return an ICMPv6 error message when a message cannot be forwarded along a Projected Route. This ICMPv6 error message is "Error in Projected Route". IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message Types. ICMPv6 Message Type 1 describes "Destination Unreachable" codes. This specification requires that a new code is allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error in Projected Route", with a suggested code value of 8, to be confirmed by IANA. 12. Acknowledgments The authors wish to acknowledge JP Vasseur, Remy Liubing, James Pylakutty and Patrick Wetterwald for their contributions to the ideas developed here. 13. Normative References [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>. Thubert, et al. Expires 19 July 2021 [Page 44] Internet-Draft DAO Projection January 2021 [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>. [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>. [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>. 14. Informative References [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>. [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>. [6TiSCH-ARCHI] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, Internet-Draft, draft-ietf-6tisch-architecture-30, 26 November 2020, <https://tools.ietf.org/html/draft-ietf-6tisch- architecture-30>. Thubert, et al. Expires 19 July 2021 [Page 45] Internet-Draft DAO Projection January 2021 [RAW-ARCHI] Thubert, P., Papadopoulos, G., and R. Buddenberg, "Reliable and Available Wireless Architecture/Framework", Work in Progress, Internet-Draft, draft-pthubert-raw- architecture-05, 15 November 2020, <https://tools.ietf.org/html/draft-pthubert-raw- architecture-05>. [TURN-ON_RFC8138] Thubert, P. and L. Zhao, "A RPL DODAG Configuration Option for the 6LoWPAN Routing Header", Work in Progress, Internet-Draft, draft-ietf-roll-turnon-rfc8138-18, 18 December 2020, <https://tools.ietf.org/html/draft-ietf- roll-turnon-rfc8138-18>. [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>. [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>. [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>. [USEofRPLinfo] Robles, 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", Work in Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-43, 10 January 2021, <https://tools.ietf.org/html/draft-ietf- roll-useofrplinfo-43>. [PCE] IETF, "Path Computation Element", <https://datatracker.ietf.org/doc/charter-ietf-pce/>. Appendix A. Applications Thubert, et al. Expires 19 July 2021 [Page 46] Internet-Draft DAO Projection January 2021 A.1. Loose Source Routing A RPL implementation operating in a very constrained LLN typically uses the Non-Storing Mode of Operation as represented in Figure 12. 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. ------+--------- | Internet | +-----+ | | 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 12: RPL Non-Storing Mode of operation 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 a 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. It results that the Root, or then some associated centralized computation engine such as a PCE, can determine the amount of packets that reach a destination in the RPL domain, and thus the amount of energy and bandwidth that is wasted for transmission, between itself and the destination, as well as the risk of fragmentation, any potential delays because of a paths longer than necessary (shorter paths exist that would not traverse the Root). Thubert, et al. Expires 19 July 2021 [Page 47] Internet-Draft DAO Projection January 2021 As a network gets deep, the size of the source routing header that the Root must add to all the downward packets becomes an issue for nodes that are many hops away. In some use cases, a RPL network forms long lines and a limited amount of well-Targeted routing state would allow to make the source routing operation loose as opposed to strict, and save packet size. Limiting the packet size is directly beneficial to the energy budget, but, mostly, it reduces the chances of frame loss and/or packet fragmentation, which is highly detrimental to the LLN operation. Because the capability to store a routing state in every node is limited, the decision of which route is installed where can only be optimized with a global knowledge of the system, a knowledge that the Root or an associated PCE may possess by means that are outside of the scope of this specification. This specification enables to store a Storing Mode state in intermediate routers, which enables to limit the excursion of the source route headers in deep networks. Once a P-DAO exchange has taken place for a given Target, if the Root operates in non Storing Mode, then it may elide the sequence of routers that is installed in the network from its source route headers to destination that are reachable via that Target, and the source route headers effectively become loose. A.2. Transversal Routes RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- Point (MP2P), whereby routes are always installed along the RPL DODAG respectively from and towards the DODAG Root. Transversal Peer to Peer (P2P) routes in a RPL network will generally suffer from some elongated (stretched) path versus the best possible path, since routing between 2 nodes always happens via a common parent, as illustrated in Figure 13: * 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 worse, 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. * 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. Thubert, et al. Expires 19 July 2021 [Page 48] Internet-Draft DAO Projection January 2021 ------+--------- | 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 13: Routing Stretch between S and D via common parent X It results that it is often beneficial to enable transversal P2P routes, either if the RPL route presents a stretch from shortest path, or if the new route is engineered with a different objective, and that it 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 at the IETF 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 draft proposes an alternate based on a centralized route computation. ------+--------- | Internet | +-----+ | | 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 14: Projected Transversal Route Thubert, et al. Expires 19 July 2021 [Page 49] Internet-Draft DAO Projection January 2021 This specification enables to store source-routed or Storing Mode state in intermediate routers, which enables to limit the stretch of a P2P route and maintain the characteristics within a given SLA. An example of service using this mechanism oculd be a control loop that would be installed in a network that uses classical RPL for asynchronous data collection. In that case, the P2P path may be installed in a different RPL Instance, with a different objective function. Authors' Addresses Pascal Thubert (editor) Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 06254 Mougins - Sophia Antipolis France Phone: +33 497 23 26 34 Email: pthubert@cisco.com Rahul Arvind Jadhav Huawei Tech Kundalahalli Village, Whitefield, Bangalore 560037 Karnataka India Phone: +91-080-49160700 Email: rahul.ietf@gmail.com Matthew Gillmore Itron, Inc Building D 2111 N Molter Road Liberty Lake, 99019 United States Phone: +1.800.635.5461 Email: matthew.gillmore@itron.com Thubert, et al. Expires 19 July 2021 [Page 50]