6tisch S. Anamalamudi Internet-Draft M. Zhang Intended status: Standards Track Huawei Technologies Expires: September 19, 2016 C. Perkins Futurewei D. Liu China Telcom Co., Ltd S.V.R.Anand Indian Institute of Science March 18, 2016 Asymmetrical AODV-P2P-RPL in 6tisch Networks draft-satish-6tisch-aodv-rpl-00 Abstract Asymmetrical link based time-sensitive traffic flows with highly reliable shortest end-to-end route discovery is pre-requisite in IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) Networks. To achieve, this document specifies a resource reservation based reactive P2P route discovery mechanism for hop-by-hop routing (storing mode) based on Ad Hoc On-demand Distance Vector Routing (AODV) RPL protocol for 6tisch Networks. Two separate instances are used to achieve directional paths based on asymmetric links in between source and destination. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://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 September 19, 2016. Anamalamudi, et al. Expires September 19, 2016 [Page 1] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 Copyright Notice Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 5 4. AODV Route Discovery Mode . . . . . . . . . . . . . . . . . . 5 4.1. Route Discovery mode for DIO-RREQ-Instance-1 . . . . . . 8 4.2. Route Discovery mode for DIO-RREQ-Instance-2 . . . . . . 10 5. Resource reservation for P2P Communication at 6TOP . . . . . 12 5.1. Operation of Trickle TImer . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. Additions to Mode of Operation . . . . . . . . . . . . . 14 6.2. Additions to RPL Control Message Options . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. References . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Deterministic Networks enable time sensitive traffic flows that are highly sensitive to jitter, quite sensitive to latency, and with a high degree of operational criticality. This clearly depicts that nodes in the Deterministic networks need to be scheduled to support critical packet flows. To achieve this, 6TiSCH Working Group focus on the Time Slotted Channel Hopping (TSCH) mode of the IEEE802.15.4e standard to schedule traffic flows through Channel Distribution and Usage (CDU) matrix. [I-D.ietf-6tisch-minimal] describes about initial formation of 6tisch network during network bootstrap through Enhanced Beacons (EB). RPL [RFC6550], the IPv6 distance vector routing protocol for Low-power and Lossy Networks (LLNs), is used on the resulting 6tisch network. RPL is designed to support multiple Anamalamudi, et al. Expires September 19, 2016 [Page 2] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 traffic flows through a root-based Destination Oriented Directed Acyclic Graph (DODAG). For Point-to-Point (P2P) traffic flows (meaning that two routers within the RPL network need to communicate), this mean that data packets either have to traverse the root in non-storing mode (source routing), or traverse a common ancestor in storing mode (hop-by-hop routing). Such P2P traffic thereby flows along sub-optimal routes between arbitrary router pairs and may suffer severe traffic congestion near the DAG root [RFC6997], [RFC6998]. This sub-optimal paths in RPL[RFC6550] result in increased resource reservation control overhead (6top control message overhead) and in-efficient bandwidth allocation (cells) for P2P traffic flows in 6tisch networks. To avoid this issue, it is desirable for child node to acquire resources (cells) reactively from its next hop neighbor (temporary parent) towards destination instead of original parent of RPL. In addition, severe traffic congestion near the DAG root MAY leads to increased packet drops that need to be taken care more efficiently for time-sensitive traffic flows in 6tisch networks. To overcome sub-optimal paths for P2P traffic flows in RPL, P2P-RPL [RFC6997] is proposed with a temporary DODAG where the source acts as temporary root. The source initiates "P2P Route Discovery mode (P2P- RDO)" with "address vector" for both non-storing mode (H=0) and storing mode (H=1). Subsequently, each intermediate router will add its IP address and multicast the P2P-RDO message again, until it reaches the destination. The destination will send "Discovery reply option", using either "hop-by-hop routing" or "source routing", based on "H" field in P2P-RDO. The proposed solution is efficient for source routing, but much less efficient for hop-by-hop routing. This is due to the extra address vector overhead in hop-by-hop routing. In fact, when the P2P-RDO message is being multicast from the source hop-by-hop, receiving nodes are able to figure out a next hop towards the source in symmetric links. Subsequently, when the destination replies to the source along the established routes, receiving nodes can once again figure out the next hop towards the destination. In other words, it is efficient to use only routing tables for P2P-RDO message instead of "Address vector" for purely hop-by-hop routes (H=1) in symmetrical links. Both RPL and P2P-RPL is proposed for single DODAG where bi- directional symmetrical links are assumed. But, application-specific routing requirements that are defined in IETF ROLL Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may have routing metrics and routing constraints that refer to links with bi- directional asymmetric properties. To achieve this, [I-D.thubert-roll-asymlink] describes about bi-directional asymmetrical links for RPL [RFC6550] with Paired DODAGs where the DAG root (DODAGID) is common for two Instances. This satisfies the Anamalamudi, et al. Expires September 19, 2016 [Page 3] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 application-specific routing requirements for bi-directional asymmetrical links in root based RPL [RFC6550]. However, P2P-RPL [RFC6997] for Paired DODAGs may need to have two DAG roots: one for the source and the other for the destination due to on-demand temporary DODAG formation. Moreover, applications in deterministic networks [I-D.grossman-detnet-use-cases] MAY also need to allocate asymmetrical links for P2P traffic flows where resource reservation (cell allocation) is different for bi-directional links. To achieve, this document specifies P2P route discovery through AODV-RPL, given the network supports bi-directional asymmetric links (See Section 4) and describes how 6top reserves resources (See Section 5) required by the discovered route [I-D.wang-6tisch-6top-sublayer]. This scenario requires two multicast messages to discover routes for bi-directional asymmetric links. With AODV-RPL, there is no "Address vector" control overhead during route discovery for paired DODAG scenarios. It is noteworthy that proposed AODV-RPL is designed on the top of the RPL routing protocol[RFC6550]. The main objective of AODV-RPL with bi-directional asymmetric links is to discover P2P routes reactively rather than those available along a global DAG [I-D.thubert-roll-asymlink]. The discovered routes of each bi-directional path must meet the application specific metrics and constraints that are separately defined in each Objective Function for each instance [RFC6552]. In this specification, all the nodes within the constrained network are required to support both instances to enable on-demand route establishment. 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 [RFC2119]. Additionally, this document uses the following terms: AODV Ad Hoc On-demand Distance Vector Routing[RFC3561]. Source The IPv6 router initiating the AODV-RPL route discovery. Destination The IPv6 router at the other end point of the P2P route(s) within the LLN network. Bi-directional Asymmetric Link A link that can be used in both directions but with different link characteristics. [I-D.thubert-roll-asymlink] Anamalamudi, et al. Expires September 19, 2016 [Page 4] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 Instance-1 Instance used for control transmission from Source to Destination and data transmission from Destination to Source. Instance-2 Instance used for control transmission from Destination to Source and data transmission from Source to Destination. hop-by-hop routing Routing when each node stores routing information about the next hop towards Source or Destination. Paired DODAGs Two DODAGs for a single application. P2P Point-to-Point. source routing The mechanism by which the source supplies the complete route to the destination along with each data packet [RFC6997]. 3. Overview of AODV-RPL With AODV-RPL, routes from Source to Destination within the LLN network are "on-demand"; in other words, the route discovery mechanism in AODV-RPL will be performed reactively when source has data for delivery to the Destination but existing routes do not satisfy the application's requirements. Unlike base RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can determine routes in networks with bi-directional asymmetric links. In other words, AODV-RPL is designed to discover two routes namely one from Source to Destination and other from Destination to Source. In addition, AODV-RPL can also support purely symmetric links for Paired DODAGs through "A" bit that is explained in Section 4. 4. AODV Route Discovery Mode In AODV-RPL, route discovery is initiated by forming a temporary DAG rooted at the Source. Paired DODAGs are used to achieve bi- directional asymmetrical link formation in between Source and Destination. AODV-RPL is designed to support two instances. Instance-1 is used for the route control messages from Source to Destination whereas Instance-2 is used for route control messages from Destination to Source (as shown in Figure 2). Intermediate routers join the Paired DODAGs based on the rank determined from the DIO message. Henceforth in this document, the DIO-RREQ-Instance-1 message represents the Route Discovery message from Source to Anamalamudi, et al. Expires September 19, 2016 [Page 5] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 Destination whereas DIO-RREQ-Instance-2 represents the Route Discovery message from Destination to Source. Subsequently, Instance-1 is used for data transmission from Destination to Source and Instance-2 is used for Data transmission from Source to Destination. The operation of the discovery mechanism resembles base RPL, extended by a new option called AODV-RREQ in a modified DIO message [I-D.thubert-roll-asymlink]. A new bit called Asymmetric bit ("A") is added to the base DIO message as shown in Figure 1. Source will always set the "D" bit to 1 and "A" bit to 0 while initiating the DIO-RREQ-Instance-1 message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |Version Number | Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|D| MOP | Prf | DTSN | Flags |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... Figure 1: Modified DI0 to support asymmetric links The "D" bit in the DIO message indicates the directional DODAG information whereas "A" bit describes the link nature (Asymmetric or Symmetric). Figure 2 describes about operation of "A" bit for symmetrical and asymmetrical links.If the DIO-RREQ-Instance-1 arrives over an interface (Intermediate router) that is known to be symmetric, and the 'A' bit is set to 0, then it remains set at 0 (see Figure 2(a)). If the DIO-RREQ-Instance-1 arrives over an interface that is not known to be symmetric, or is known to be asymmetric, then the 'A' bit is set to be 1. If the 'A' bit arrives already set to be '1', it is set to be '1' on retransmission (Figure 2(b)). The 'A' bit is set to mean that the route is asymmetric. If any Intermediate router along the way believes that the incoming link is asymmetric, then the "A" bit is set to be 1 and remains set to be 1 all the way to the destination. Otherwise if there are no asymmetric links the "A" bit remains set to zero. Based on the "A" bit received by Destination in DIO-RREQ-Instance-1, link nature (Asymmetric or Symmetric) is decided to transmit DIO-RREQ-Instance-2 message back to Source. Anamalamudi, et al. Expires September 19, 2016 [Page 6] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 --Instance-1 (Control:S->D;Data:D->S) ------> A=0 A=0 A=0 <--> <--> <--> R--------R--------R--------R | | | | | A=0 | | A=0 | A=0 |<--> | | <--> | A=0 A=0 <--> | | | | <--> <--> S--------R--------R--------R--------R--------R---------D | | | | | | | | | | | | | | | | | | R--------R--------R--------R--------R---------R <--Instance-2(Control:D->S;Data:S->D)-------- (a). AODV-RPL with Symmetrical links --Instance-1 (Control:S->D;Data:D->S) ------> A=0 A=0 A=1 --> --> --> R--------R--------R--------R | | | | |A=0 | | A=1 | A=0 |--> | | --> | A=1 A=1 --> | | | ------ --> --> S--------R--------R--------R--------R--------R---------D | | | | | | A=1 | | | | | | <-- |A=1 | | | | |A=1 |<-- | | | | |<-- | | | | | | R--------R--------R--------R--------R---------R A=1 A=1 A=1 A=1 A=1 <-- <-- <-- <-- <-- <--Instance-2(Control:D->S;Data:S->D)-------- (b). AODV-RPL with Asymmetrical links S :Source R :Intermediate nodes D :Destination Figure 2: AODV-RPL with Paired Instances Anamalamudi, et al. Expires September 19, 2016 [Page 7] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 The value of 'A' bit (Symmetric or Asymmetric) can be decided by the available radio resources (cells) (See Section.5) during DIO-RREQ- Instance-1 message. Based on the received number of cell requests (NumCell) from ADDRequest in DIO-RREQ-Instance-1, Intermediate node will decide to set 'A' bit to '1' or remain to set 'A' bit to '0'. For example, if intermediate node has resource (cells) to transmit data for only one direction then it set A bit to '1'. If it has resources (cells) to support data in both directions then it can remain the 'A' bit to '0'. Even if there is atleast one link along the path of DIO-RREQ-Instance-1 that does not have cells for both directions then 'A' bit is set to '1' and Destination will start to multicast DIO-RREQ-Instance-2(see Figure 2(b)). If all the Intermediate nodes have cells for both directions then 'A' bit will be remain to '0' and DIO-RREQ-Instance-2 is unicast back in same path of DIO-RREQ-Instance-1 (see Figure 2(a)). 4.1. Route Discovery mode for DIO-RREQ-Instance-1 The AODV-RPL Source specifies the following information in the DIO- RREQ-Instance-1 message: - D-bit Directional bit in the DIO base object (D=1 for DIO-RREQ- Instance-1 message)[I-D.thubert-roll-asymlink]. - A-bit Asymmetric bit in the DIO base object (A=0 for DIO-RREQ-Instance-1 message). - MOP bit MOP operation in the DIO object MUST be set to "5(tbd)" by Source for "AODV-RPL". - RPLInstanceID RPLInstanceID in the DIO object MUST be the InstanceID of Instance-1. - DODAGID DODAGID in the DIO object MUST be the IPv6 address of the Source that initiates the DIO-RREQ message of Instance-1. - Rank Anamalamudi, et al. Expires September 19, 2016 [Page 8] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 Rank in the DIO object MUST be the the rank of Instance-1. - Metric Container Options DIO-RREQ-Instance-1 message from Source MAY carry one or more Metric Container options to specify the relevant routing metrics. - Destination address IPv6 address of the Destination that receives DIO-RREQ-Instance-1 message. This address MUST be in the modified RREQ option (see Figure 3) of AODV [RFC3561]. - G bit G(Gratuitous RREP flag) bit is set to "1" when Source has Destination Sequence number. When an intermediate node has a route towards destination with higher Destination Sequence number then Gratuitous DIO-RREP messages are unicast from the intermediate node to Destination. Note that Intermediate nodes never reply unicast Gratuitous DIO-RREP messages back to Source in Instance-1. - J bit Derived from [RFC3561].Out of scope for this specification. - R bit Derived from [RFC3561].Out of scope for this specification. - D bit Derived from [RFC3561].Out of scope for this specification. - U bit Derived from [RFC3561].Out of scope for this specification. The Source in Figure 2 will multicast the DIO-RREQ-Instance-1 message (see Figure 3) to its one-hop neighbours. Intermediate nodes will compute the rank for Instance-1 and create a routing table entry for path towards the source if the routing metrics/constraints are satisfied. Subsequently, it checks for already existing path towards destination by comparing the Destination Sequence Numbers. Whenever the path exists from intermediate node to Destination, it unicast the Gratuitous DIO-RREP towards destination and creates the path towards Source for Instance-1. This helps to minimize the route control Anamalamudi, et al. Expires September 19, 2016 [Page 9] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 message multicast overhead during Route Discovery process. The message format of Gratuitous DIO-RREP is same as [RFC3561] with the exception of the Source IP address which can be obtained through DODAGID of DIO base (see Figure 1). If the path towards Destination does not exist, the intermediate node has to re-multicast the DIO- RREQ-Instance-1 message with updated rank to the next-hop neighbours until the message reaches to Destination(Figure 2). Based on the "A" bit in received DIO-RREQ_instance-1, Destination will decide to unicast or multicast the DIO-RREQ-Instance-2 message back to Source. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|D|U| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Modified DIO-RREQ message format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|A| Reserved |Prefix Sz| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: DIO-Gratuitous-RREP message format 4.2. Route Discovery mode for DIO-RREQ-Instance-2 The AODV-RPL Destination specifies the following information in the DIO-RREQ-Instance-2 message: - D-bit Directional bit in the DIO base object (D=1 for DIO-RREQ- Instance-2 message)[I-D.thubert-roll-asymlink]. Anamalamudi, et al. Expires September 19, 2016 [Page 10] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 - A-bit Asymmetric bit in the DIO base object (value of "A" bit for DIO- RREQ-Instance-2 is directly copied from "A" bit of DIO-RREQ- Instance-1 message). - MOP bit MOP operation in the DIO object MUST be set to "5(tbd)" by Destination for "AODV-RPL". - RPLInstanceID RPLInstanceID in the DIO object MUST be the InstanceID of Instance-2. - DODAGID DODAGID in the DIO object MUST be the IPv6 address of the Destination that initiates the DIO-RREQ message of Instance-2. - Rank Rank in the DIO object MUST be the the rank of Instance-2. - Metric Container Options DIO-RREQ-Instance-2 message from Destination MAY carry one or more Metric Container options to specify the relevant routing metrics. - Destination address IPv6 address of the Source that receives DIO-RREQ-Instance-2 message. This address MUST be in the modified RREQ option (see Figure 3) of AODV [RFC3561]. - G bit G(Gratuitous RREP flag) bit is set to "1" when Destination has Source Sequence number. When an Intermediate node has a route towards Source with higher Source Sequence number then Gratuitous DIO-RREP messages are unicast from Intermediate node to Source. Note that Intermediate nodes never reply unicast DIO-RREP messages back to Destination in Instance-2. - J bit Derived from [RFC3561].Out of scope for this specification. Anamalamudi, et al. Expires September 19, 2016 [Page 11] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 - R bit Derived from [RFC3561].Out of scope for this specification. - D bit Derived from [RFC3561].Out of scope for this specification. - U bit Derived from [RFC3561].Out of scope for this specification. The Destination in Figure 2 start to multicast the DIO-RREQ- Instance-2 message when the received "A" bit in DIO-RREQ-Instance-1 is set to 1. Intermediate nodes will create the routing tables for the path towards the Destination during DIO-RREQ-Instance-2 messages to Source. If the intermediate nodes have path towards the Source, then it unicast the Gratuitous DIO-RREP towards the Source and creates the path towards Destination for Instance-2. Once the route control message is reached to Source, it will start transmitting the application data packets to the Destination in the path that is discovered through DIO-RREQ-Instance-2 messages. Similarly, application data from Destination to Source is transmitted through the path that is discovered from DIO-RREQ-Instance-1 message. The Destination in Figure 2 start to unicast the DIO-RREQ-Instance-2 message when the received "A" bit in DIO-RREQ-Instance-1 is set to 0. In this case, route control messages and application data in between Source and Destination for both Instance-1 and Instance-2 are transmitted in symmetrical links. 5. Resource reservation for P2P Communication at 6TOP Whenever, Source has data to destination it runs the Bandwidth Estimation Algorithm (BEA)[I-D.dujovne-6tisch-6top-sf0] to estimate the application bandwidth requirement and map it to required number of cells. Subsequently, 6P ADD Request [I-D.wang-6tisch-6top-sublayer] is appended to the DIO-RREQ- Instance-1 with NumCells equal to application bandwidth requirement that is known through BEA. It is noteworthy that CellList (slotoffset, channeloffset) and Container information in 6P ADD Request is set to zero during DIO-RREQ-Instance-1 multicast from Source. Once the DIO-RREQ-Instance-1 with 6P ADD Request is reached to intermediate node, it checks the NumCells field. When an Intermediate node is able to allocate its transmit and receive cells that are equal to NumCells of 6P ADD Request, then it is eligible to re-multicast the DIO-RREQ-Instance-1 with 6P ADD Request. At this point, link nature (Symmetrical or Asymmetrical) is decided by Anamalamudi, et al. Expires September 19, 2016 [Page 12] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 Intermediate node based on the available resources (cells). If an Intermediate node has transmit and receive cells for both directions that are greater than or equal to NumCells of 6P ADD Request then 'A' bit is remain to set to '0'. If an intermediate node has cells available only for one direction (Destination to Source) then 'A' bit is set to '1' and it re-multicast the DIO-RREQ-Instance-1. Whenever, the intermediate node has Destination Sequence number that is greater than Sequence number specified in modified-RREQ then Gratuitous-RREP is unicast with 6P ADD Request. It is assumed that Intermediate nodes who know the path towards the Destination must be able to allocate both transmit and receive cells that are specified in NumCells to either single direction (Asymmetric) or both directions (Symmetric). Once the DIO-RREQ-Instance-1 with 6P ADD Request reaches to the Destination, it checks the 'A' bit to reply the DIO- RREQ_Instance-2 messages. For Asymmetrical links(A=1) to Instance-1, it is notable that Source will allocate only receive cells, Destination will allocate only transmit cells and Intermediate nodes that multicast route control messages will allocate both transmit and receive cells to perform data transmission from Destination to Source in Instance-1. For asymmetrical links (A=1) to Instance-2, Destination will estimate the application bandwidth requirement through BEA and map it to Numcell for DIO-RREQ-Instance-2. It is noteworthy that CellList(slotoffset, channeloffset) and Container information in 6P ADD Request is set to zero during DIO-RREQ-Instance-2 multicast from Destination. Intermediate nodes that are able to allocate it's both transmit and receive cells of Numcell in 6P ADD Request will re- multicast the DIO-RREQ-Instance-2 with 6P ADD Request until it reaches to Source. In this case, 'A' bit is always set to '1'. From this operation, it is notable that Source will allocate only transmit cells, Destination will allocate only receive cells and Intermediate nodes that multicast route control messages will allocate both transmit and receive cells to perform data transmission from Source to Destination in Instance-2. Once the Source know the path towards the Destination in Instance-2, it performs the actual 6P negotiation (6P ADD Request, 6P ADD Response) [I-D.wang-6tisch-6top-sublayer] to request and allocates the CellList (slotoffset, channeloffset) hop-by-hop for actual data transmission. Similarly, Destination will perform 6P negotiation (6P ADD Request, 6P ADD Response) [I-D.wang-6tisch-6top-sublayer] to request and allocate the CellList(slotoffset, channeloffset) hop-by- hop towards Source in Instance-1 for data transmission. The cells(bundle) allocated for end-to-end path in Instance-1 is associated with one TrackID and the cells allocated for end-to-end path in Instance-2 is associated with another TrackID. Anamalamudi, et al. Expires September 19, 2016 [Page 13] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 For asymmetrical links (A=1), allocation of transmit-receive cells for Instance-1 and allocation of transmit-receive cells for Instance-2 will be in different paths. For symmetrical links (A=0), Source and Destination will use same path for both Instance-1 and Instance-2 to transmit data. Hence, allocation of transmit-receive cells for Instance-1 and allocation of transmit-receive cells for Instance-2 need to be in same path. With AODV-RPL, the address vector is not required and resource reservation (cell allocation) is on-demand during reactive route- discovery. This efficiently utilizes the control packet size and radio resources that is most significant in 6tisch networks. 5.1. Operation of Trickle TImer The operation of Trickle timer to control DIO-RREQ-Instance 1/ Instance-2 message is similar to P2P-RPL Trickle operation [RFC6997]. 6. IANA Considerations 6.1. Additions to Mode of Operation IANA is required to assign a new Mode of Operation, named "AODV-RPL" for Point-to-Point(P2P) hop-by-hop routing under the RPL registry. The value of tbd1 is assigned from the "Mode of Operation" space [RFC6550]. +-------------+---------------+---------------+ | Value | Description | Reference | +-------------+---------------+---------------+ | tbd1(5) | AODV-RPL | This document | +-------------+---------------+---------------+ Figure 5: Mode of Operation 6.2. Additions to RPL Control Message Options IANA is require to assign two entries for a new RPL options: "DIO- RREQ-Instance-1" and "DIO-RREQ-Instance-1" values of tbd2 (0x0a) and tbd3(0x0b) from the "RPL Control Message Options" space [RFC6550]. Anamalamudi, et al. Expires September 19, 2016 [Page 14] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 +-------------+----------------------+---------------+ | Value | Meaning | Reference | +-------------+----------------------+---------------+ | tbd2(0x0a) | DIO-RREQ-Instance-1 | This document | +-------------+----------------------+---------------+ | tbd3(0x0b) | DIO-RREQ-Instance-2 | This document | +-------------+----------------------+---------------+ Figure 6: RPL Control Message Options 7. Security Considerations This document does not introduce additional security issues to [RFC6550]. For general RPL security considerations, see [RFC6550]. 8. References 8.1. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, . [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 2009, . [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 2009, . [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, DOI 10.17487/RFC5826, April 2010, . [RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June 2010, . Anamalamudi, et al. Expires September 19, 2016 [Page 15] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 [RFC6550] 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, . [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012, . [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, . 8.2. Informative References [I-D.dujovne-6tisch-6top-sf0] Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, "6TiSCH 6top Scheduling Function Zero (SF0)", draft- dujovne-6tisch-6top-sf0-00 (work in progress), October 2015. [I-D.grossman-detnet-use-cases] Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y. Zha, "Deterministic Networking Use Cases", draft-grossman- detnet-use-cases-01 (work in progress), November 2015. [I-D.ietf-6tisch-minimal] Vilajosana, X. and K. Pister, "Minimal 6TiSCH Configuration", draft-ietf-6tisch-minimal-15 (work in progress), February 2016. [I-D.thubert-roll-asymlink] Thubert, P., "RPL adaptation for asymmetrical links", draft-thubert-roll-asymlink-02 (work in progress), December 2011. Anamalamudi, et al. Expires September 19, 2016 [Page 16] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 [I-D.wang-6tisch-6top-sublayer] Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer (6top)", draft-wang-6tisch-6top-sublayer-04 (work in progress), November 2015. Authors' Addresses Satish Anamalamudi Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China Email: satish.anamalamudi@huawei.com Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China Email: zhangmingui@huawei.com Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara 95050 Unites States Email: charliep@computer.org Dongxin Liu China Telcom Co., Ltd 109 West Zhongshan Ave, Tianhe District Guangzhou 510630 China Email: liudx@gsta.com Anamalamudi, et al. Expires September 19, 2016 [Page 17] Internet-Draft draft-satish-tisch-AODV-RPL March 2016 S.V.R Anand Indian Institute of Science Bangalore 560012 India Email: anand@ece.iisc.ernet.in Anamalamudi, et al. Expires September 19, 2016 [Page 18]