--- 1/draft-ietf-roll-aodv-rpl-09.txt 2021-04-04 09:13:11.375138289 -0700 +++ 2/draft-ietf-roll-aodv-rpl-10.txt 2021-04-04 09:13:11.411138762 -0700 @@ -1,26 +1,25 @@ ROLL S. Anamalamudi Internet-Draft SRM University-AP Intended status: Standards Track M. Zhang -Expires: August 6, 2021 Huawei Technologies +Expires: October 6, 2021 Huawei Technologies C. Perkins Lupin Lodge S.V.R.Anand Indian Institute of Science B. Liu Huawei Technologies - February 2, 2021 + April 4, 2021 - AODV based RPL Extensions for Supporting Asymmetric P2P Links in - Low-Power and Lossy Networks - draft-ietf-roll-aodv-rpl-09 + Supporting Asymmetric Links in Low Power Networks: AODV-RPL + draft-ietf-roll-aodv-rpl-10 Abstract 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 @@ -34,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 6, 2021. + This Internet-Draft will expire on October 6, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -74,71 +73,73 @@ 6.2.1. General Processing . . . . . . . . . . . . . . . . . 14 6.2.2. Additional Processing for Multiple Targets . . . . . 15 6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 16 6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 16 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 16 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 17 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 17 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 19 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 19 + 9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 20 9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Example: Using ETX/RSSI Values to determine value of S bit . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24 - B.1. Changes from version 08 to version 09 . . . . . . . . . . 24 - B.2. Changes from version 07 to version 08 . . . . . . . . . . 25 - B.3. Changes from version 06 to version 07 . . . . . . . . . . 26 - B.4. Changes from version 05 to version 06 . . . . . . . . . . 26 - B.5. Changes from version 04 to version 05 . . . . . . . . . . 26 - B.6. Changes from version 03 to version 04 . . . . . . . . . . 26 - B.7. Changes from version 02 to version 03 . . . . . . . . . . 27 + B.1. Changes from version 09 to version 10 . . . . . . . . . . 24 + B.2. Changes from version 08 to version 09 . . . . . . . . . . 25 + B.3. Changes from version 07 to version 08 . . . . . . . . . . 25 + B.4. Changes from version 06 to version 07 . . . . . . . . . . 26 + B.5. Changes from version 05 to version 06 . . . . . . . . . . 26 + B.6. Changes from version 04 to version 05 . . . . . . . . . . 26 + B.7. Changes from version 03 to version 04 . . . . . . . . . . 27 + B.8. Changes from version 02 to version 03 . . . . . . . . . . 27 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction - RPL [RFC6550] (Routing Protocol for Low-Power and Lossy Networks) is + RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is an IPv6 distance vector routing protocol designed to support multiple traffic flows through a root-based Destination-Oriented Directed Acyclic Graph (DODAG). Typically, a router does not have routing information for most other routers. Consequently, for traffic between routers within the DODAG (i.e., Point-to-Point (P2P) traffic) data packets either have to traverse the root in non-storing mode, or traverse a common ancestor in storing mode. Such P2P traffic is thereby likely to traverse longer routes and may suffer severe - congestion near the DAG root (for more information see [RFC6997], + congestion near the root (for more information see [RFC6997], [RFC6998]). The route discovery process in AODV-RPL is modeled on the analogous procedure specified in AODV [RFC3561]. The on-demand nature of AODV route discovery is natural for the needs of peer-to-peer routing in RPL-based LLNs. AODV terminology has been adapted for use with AODV- RPL messages, namely RREQ for Route Request, and RREP for Route Reply. AODV-RPL currently omits some features compared to AODV -- in particular, flagging Route Errors, blacklisting unidirectional links, multihoming, and handling unnumbered interfaces. AODV-RPL reuses and provides a natural extension to the core RPL functionality to support routes with birectional asymmetric links. It retains RPL's DODAG formation, RPL Instance and the associated Objective Function (defined in [RFC6551]), trickle timers, and support for storing and non-storing modes. AODV adds basic messages RREQ and RREP as part of RPL DIO (DODAG Information Object) control - messages, and does not utilize the DAO message of RPL. AODV-RPL - specifies a new MOP running in a separate instance dedicated to - discover P2P routes, which may differ from the P2MP routes + messages, and does not utilize the Destination Advertisement Object + (DAO) message of RPL. AODV-RPL specifies a new MOP (Mode of + Operation) running in a separate instance dedicated to discover P2P + routes, which may differ from the point-to-multipoint routes discoverable by native RPL. AODV-RPL can be operated whether or not native RPL is running otherwise. 2. Terminology 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. @@ -265,21 +266,21 @@ is used for transmitting data from TargNode to OrigNode, and the route discovered in RREP-Instance is used for transmitting data from OrigNode to TargNode. 4. AODV-RPL DIO Options 4.1. AODV-RPL RREQ Option OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO message. A RREQ-DIO message MUST carry exactly one RREQ option, - otherwise it SHOULD be dropped. + otherwise it MUST be dropped. 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|H|X| Compr | L | MaxRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Orig SeqNo | | +-+-+-+-+-+-+-+-+ | | | | | @@ -350,21 +351,21 @@ TargNode can join the RREQ instance at a Rank whose integer portion is equal to the MaxRank. Other nodes MUST NOT join a RREQ instance if its own Rank would be equal to or higher than MaxRank. A router MUST discard a received RREQ if the integer part of the advertised Rank equals or exceeds the MaxRank limit. 4.2. AODV-RPL RREP Option TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO message. A RREP-DIO message MUST carry exactly one RREP option, - otherwise the message SHOULD be dropped. TargNode supplies the + otherwise the message MUST be dropped. TargNode supplies the following information in the RREP option: 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 |G|H|X| Compr | L | MaxRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shift |Rsv| | +-+-+-+-+-+-+-+-+ | | | @@ -434,37 +435,37 @@ MUST be dropped. OrigNode can include multiple TargNode addresses via multiple AODV- RPL Target Options in the RREQ-DIO, for routes that share the same requirement on metrics. This reduces the cost to building only one DODAG. 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 | Dest SeqNo |r|Prefix Length| + | Option Type | Option Length | Dest SeqNo |X|Prefix Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + | | Target Prefix / Address (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ART Option format for AODV-RPL MOP Option Type TBD4 Option Length Length of the option in octets excluding the Type and Length - fields + fields. Dest SeqNo In RREQ-DIO, if nonzero, it is the last known Sequence Number for TargNode for which a route is desired. In RREP-DIO, it is the destination sequence number associated to the route. r A one-bit reserved field. This field MUST be initialized to zero by the sender and MUST be ignored by the receiver. @@ -871,20 +872,26 @@ 8. Operation of Trickle Timer The trickle timer operation to control RREQ-Instance/RREP-Instance multicast uses [RFC6206] to control RREQ-DIO and RREP-DIO transmissions. The Trickle control of these DIO transmissions follow the procedures described in the Section 8.3 of [RFC6550] entitled "DIO Transmission". 9. IANA Considerations + Note to RFC editor: + + The sentences "The parenthesized number 5 is only a suggestion." and + "The parenthesized numbers are only suggestions." are to be removed + prior publication. + 9.1. New Mode of Operation: AODV-RPL IANA is asked to assign a new Mode of Operation, named "AODV-RPL" for Point-to-Point(P2P) hop-by-hop routing from the "Mode of Operation" Registry. The parenthesized number 5 is only a suggestion. +-------------+---------------+---------------+ | Value | Description | Reference | +-------------+---------------+---------------+ | TBD1 (5) | AODV-RPL | This document | @@ -930,24 +937,21 @@ If a rogue router knows the key for the Security Configuration in use, it can join the secure AODV-RPL route discovery and cause various types of damage. Such a rogue router could advertise false information in its DIOs in order to include itself in the discovered route(s). It could generate bogus RREQ-DIO, and RREP-DIO messages carrying bad routes or maliciously modify genuine RREP-DIO messages it receives. A rogue router acting as the OrigNode could launch denial-of-service attacks against the LLN deployment by initiating fake AODV-RPL route discoveries. In this type of scenario, RPL's preinstalled mode of operation, where the key to use for a P2P-RPL - route discovery is preinstalled, SHOULD be used. If a future IETF - document specifies the authenticated mode of operation as described - in [RFC6550], then future AODV-RPL implementations SHOULD use the - authenticated mode of operation. + route discovery is preinstalled, SHOULD be used. When a RREQ-DIO message uses the source routing option by setting the H bit to 0, a rogue router may populate the Address Vector field with a set of addresses that may result in the RREP-DIO traveling in a routing loop. The TargNode MUST NOT generate a RREP if one of its addresses is present in the Address Vector. An Intermediate Router MUST NOT forward a RREP if one of its addresses is present in the Address Vector. 11. References @@ -969,32 +973,20 @@ Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, . - [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, - "A Mechanism to Measure the Routing Metrics along a Point- - to-Point Route in a Low-Power and Lossy Network", - RFC 6998, DOI 10.17487/RFC6998, August 2013, - . - - [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, - . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [co-ioam] Ballamajalu, Rashmi., S.V.R., Anand., and Malati Hegde, "Co-iOAM: In-situ Telemetry Metadata Transport for Resource Constrained Networks within IETF Standards Framework", 2018 10th International Conference on @@ -1019,26 +1011,38 @@ Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, . [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, . + [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, + "A Mechanism to Measure the Routing Metrics along a Point- + to-Point Route in a Low-Power and Lossy Network", + RFC 6998, DOI 10.17487/RFC6998, August 2013, + . + [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, . + [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, + . + [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. Sehgal, "Management of Networks with Constrained Devices: Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, . Appendix A. Example: Using ETX/RSSI Values to determine value of S bit The combination of Received Signal Strength Indication(downstream) (RSSI) and Expected Number of Transmissions(upstream)" (ETX) has been tested to determine whether a link is symmetric or asymmetric at @@ -1103,21 +1107,35 @@ received RSSI from NodeB. Whenever nodeA determines that the link towards the nodeB is bi-directional asymmetric then the S bit is set to 0. Afterwards, the link from NodeA to Destination remains designated as asymmetric and the S bit remains set to 0. Appendix B. Changelog Note to the RFC Editor: please remove this section before publication. -B.1. Changes from version 08 to version 09 +B.1. Changes from version 09 to version 10 + + o Changed the title for brevity and to remove acronyms. + + o Added "Note to the RFC Editor" in Section 9. + + o Expanded DAO and P2MP in Section 1. + + o Reclassified [RFC6998] and [RFC7416] as Informational. + + o SHOULD changed to MUST in Section 4.1 and Section 4.2. + + o Several editorial improvements and clarifications. + +B.2. Changes from version 08 to version 09 o Removed section "Link State Determination" and put some of the relevant material into Section 5. o Cited security section of [RFC6550] as part of the RREP-DIO message description in Section 2. o SHOULD has been changed to MUST in Section 4.2. o Expanded the terms ETX and RSSI in Section 5. @@ -1130,21 +1148,21 @@ operation. o Appendix A has been mostly re-written to describe methods to determine whether or not the 'S' bit should be set to 1. o For consistency, adjusted several mandates from SHOULD to MUST and from SHOULD NOT to MUST NOT. o Numerous editorial improvements and clarifications. -B.2. Changes from version 07 to version 08 +B.3. Changes from version 07 to version 08 o Instead of describing the need for routes to "fulfill the requirements", specify that routes need to "satisfy the Objective Function". o Removed all normative dependencies on [RFC6997] o Rewrote Section 10 to avoid duplication of language in cited specifications. @@ -1164,64 +1182,64 @@ o Specified behavior upon reception of a RREQ-DIO or RREP-DIO message for an already existing DODAGID (e.g, Section 6.4). o Fixed numerous language issues in IANA Considerations Section 9. o For consistency, adjusted several mandates from SHOULD to MUST and from SHOULD NOT to MUST NOT. o Numerous editorial improvements and clarifications. -B.3. Changes from version 06 to version 07 +B.4. Changes from version 06 to version 07 o Added definitions for all fields of the ART option (see Section 4.3). Modified definition of Prefix Length to prohibit Prefix Length values greater than 127. o Modified the language from [RFC6550] Target Option definition so that the trailing zero bits of the Prefix Length are no longer described as "reserved". o Reclassified [RFC3561] and [RFC6998] as Informative. o Added citation for [RFC8174] to Terminology section. -B.4. Changes from version 05 to version 06 +B.5. Changes from version 05 to version 06 o Added Security Considerations based on the security mechanisms defined in [RFC6550]. o Clarified the nature of improvements due to P2P route discovery versus bidirectional asymmetric route discovery. o Editorial improvements and corrections. -B.5. Changes from version 04 to version 05 +B.6. Changes from version 04 to version 05 o Add description for sequence number operations. o Extend the residence duration L in section 4.1. o Change AODV-RPL Target option to ART option. -B.6. Changes from version 03 to version 04 +B.7. Changes from version 03 to version 04 o Updated RREP option format. Remove the T bit in RREP option. o Using the same RPLInstanceID for RREQ and RREP, no need to update [RFC6550]. o Explanation of Shift field in RREP. o Multiple target options handling during transmission. -B.7. Changes from version 02 to version 03 +B.8. Changes from version 02 to version 03 o Include the support for source routing. o Import some features from [RFC6997], e.g., choice between hop-by- hop and source routing, the L bit which determines the duration of residence in the DAG, MaxRank, etc. o Define new target option for AODV-RPL, including the Destination Sequence Number in it. Move the TargNode address in RREQ option and the OrigNode address in RREP option into ADOV-RPL Target @@ -1242,31 +1260,31 @@ Authors' Addresses Satish Anamalamudi SRM University-AP Amaravati Campus Amaravati, Andhra Pradesh 522 502 India Email: satishnaidu80@gmail.com - Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China Email: zhangmingui@huawei.com + Charles E. Perkins Lupin Lodge - Saratoga 95070 + Los Gatos 95033 United States Email: charliep@computer.org S.V.R Anand Indian Institute of Science Bangalore 560012 India Email: anandsvr@iisc.ac.in