idnits 2.17.1 draft-satish-6tisch-aodv-rpl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 68 has weird spacing: '...ication at 6T...' -- The document date (March 18, 2016) is 2960 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6550' is mentioned on line 714, but not defined == Missing Reference: 'RFC6997' is mentioned on line 726, but not defined == Missing Reference: 'RFC6998' is mentioned on line 732, but not defined == Missing Reference: 'RFC5548' is mentioned on line 694, but not defined == Missing Reference: 'RFC5673' is mentioned on line 699, but not defined == Missing Reference: 'RFC5826' is mentioned on line 704, but not defined == Missing Reference: 'RFC5867' is mentioned on line 709, but not defined == Missing Reference: 'RFC6552' is mentioned on line 721, but not defined == Missing Reference: 'RFC2119' is mentioned on line 684, but not defined == Missing Reference: 'RFC3561' is mentioned on line 689, but not defined == Outdated reference: A later version (-01) exists of draft-dujovne-6tisch-6top-sf0-00 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-15 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch S. Anamalamudi 3 Internet-Draft M. Zhang 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 19, 2016 C. Perkins 6 Futurewei 7 D. Liu 8 China Telcom Co., Ltd 9 S.V.R.Anand 10 Indian Institute of Science 11 March 18, 2016 13 Asymmetrical AODV-P2P-RPL in 6tisch Networks 14 draft-satish-6tisch-aodv-rpl-00 16 Abstract 18 Asymmetrical link based time-sensitive traffic flows with highly 19 reliable shortest end-to-end route discovery is pre-requisite in IPv6 20 over the TSCH mode of IEEE 802.15.4e (6tisch) Networks. To achieve, 21 this document specifies a resource reservation based reactive P2P 22 route discovery mechanism for hop-by-hop routing (storing mode) based 23 on Ad Hoc On-demand Distance Vector Routing (AODV) RPL protocol for 24 6tisch Networks. Two separate instances are used to achieve 25 directional paths based on asymmetric links in between source and 26 destination. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 19, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 5 65 4. AODV Route Discovery Mode . . . . . . . . . . . . . . . . . . 5 66 4.1. Route Discovery mode for DIO-RREQ-Instance-1 . . . . . . 8 67 4.2. Route Discovery mode for DIO-RREQ-Instance-2 . . . . . . 10 68 5. Resource reservation for P2P Communication at 6TOP . . . . . 12 69 5.1. Operation of Trickle TImer . . . . . . . . . . . . . . . 14 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 6.1. Additions to Mode of Operation . . . . . . . . . . . . . 14 72 6.2. Additions to RPL Control Message Options . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8.1. References . . . . . . . . . . . . . . . . . . . . . . . 15 76 8.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 Deterministic Networks enable time sensitive traffic flows that are 82 highly sensitive to jitter, quite sensitive to latency, and with a 83 high degree of operational criticality. This clearly depicts that 84 nodes in the Deterministic networks need to be scheduled to support 85 critical packet flows. To achieve this, 6TiSCH Working Group focus 86 on the Time Slotted Channel Hopping (TSCH) mode of the IEEE802.15.4e 87 standard to schedule traffic flows through Channel Distribution and 88 Usage (CDU) matrix. [I-D.ietf-6tisch-minimal] describes about 89 initial formation of 6tisch network during network bootstrap through 90 Enhanced Beacons (EB). RPL [RFC6550], the IPv6 distance vector 91 routing protocol for Low-power and Lossy Networks (LLNs), is used on 92 the resulting 6tisch network. RPL is designed to support multiple 93 traffic flows through a root-based Destination Oriented Directed 94 Acyclic Graph (DODAG). For Point-to-Point (P2P) traffic flows 95 (meaning that two routers within the RPL network need to 96 communicate), this mean that data packets either have to traverse the 97 root in non-storing mode (source routing), or traverse a common 98 ancestor in storing mode (hop-by-hop routing). Such P2P traffic 99 thereby flows along sub-optimal routes between arbitrary router pairs 100 and may suffer severe traffic congestion near the DAG root [RFC6997], 101 [RFC6998]. This sub-optimal paths in RPL[RFC6550] result in 102 increased resource reservation control overhead (6top control message 103 overhead) and in-efficient bandwidth allocation (cells) for P2P 104 traffic flows in 6tisch networks. To avoid this issue, it is 105 desirable for child node to acquire resources (cells) reactively from 106 its next hop neighbor (temporary parent) towards destination instead 107 of original parent of RPL. In addition, severe traffic congestion 108 near the DAG root MAY leads to increased packet drops that need to be 109 taken care more efficiently for time-sensitive traffic flows in 110 6tisch networks. 112 To overcome sub-optimal paths for P2P traffic flows in RPL, P2P-RPL 113 [RFC6997] is proposed with a temporary DODAG where the source acts as 114 temporary root. The source initiates "P2P Route Discovery mode (P2P- 115 RDO)" with "address vector" for both non-storing mode (H=0) and 116 storing mode (H=1). Subsequently, each intermediate router will add 117 its IP address and multicast the P2P-RDO message again, until it 118 reaches the destination. The destination will send "Discovery reply 119 option", using either "hop-by-hop routing" or "source routing", based 120 on "H" field in P2P-RDO. The proposed solution is efficient for 121 source routing, but much less efficient for hop-by-hop routing. This 122 is due to the extra address vector overhead in hop-by-hop routing. 123 In fact, when the P2P-RDO message is being multicast from the source 124 hop-by-hop, receiving nodes are able to figure out a next hop towards 125 the source in symmetric links. Subsequently, when the destination 126 replies to the source along the established routes, receiving nodes 127 can once again figure out the next hop towards the destination. In 128 other words, it is efficient to use only routing tables for P2P-RDO 129 message instead of "Address vector" for purely hop-by-hop routes 130 (H=1) in symmetrical links. 132 Both RPL and P2P-RPL is proposed for single DODAG where bi- 133 directional symmetrical links are assumed. But, application-specific 134 routing requirements that are defined in IETF ROLL Working Group 135 [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may have routing 136 metrics and routing constraints that refer to links with bi- 137 directional asymmetric properties. To achieve this, 138 [I-D.thubert-roll-asymlink] describes about bi-directional 139 asymmetrical links for RPL [RFC6550] with Paired DODAGs where the DAG 140 root (DODAGID) is common for two Instances. This satisfies the 141 application-specific routing requirements for bi-directional 142 asymmetrical links in root based RPL [RFC6550]. However, P2P-RPL 143 [RFC6997] for Paired DODAGs may need to have two DAG roots: one for 144 the source and the other for the destination due to on-demand 145 temporary DODAG formation. Moreover, applications in deterministic 146 networks [I-D.grossman-detnet-use-cases] MAY also need to allocate 147 asymmetrical links for P2P traffic flows where resource reservation 148 (cell allocation) is different for bi-directional links. To achieve, 149 this document specifies P2P route discovery through AODV-RPL, given 150 the network supports bi-directional asymmetric links (See Section 4) 151 and describes how 6top reserves resources (See Section 5) required by 152 the discovered route [I-D.wang-6tisch-6top-sublayer]. This scenario 153 requires two multicast messages to discover routes for bi-directional 154 asymmetric links. With AODV-RPL, there is no "Address vector" 155 control overhead during route discovery for paired DODAG scenarios. 156 It is noteworthy that proposed AODV-RPL is designed on the top of the 157 RPL routing protocol[RFC6550]. 159 The main objective of AODV-RPL with bi-directional asymmetric links 160 is to discover P2P routes reactively rather than those available 161 along a global DAG [I-D.thubert-roll-asymlink]. The discovered 162 routes of each bi-directional path must meet the application specific 163 metrics and constraints that are separately defined in each Objective 164 Function for each instance [RFC6552]. In this specification, all the 165 nodes within the constrained network are required to support both 166 instances to enable on-demand route establishment. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in 173 [RFC2119]. Additionally, this document uses the following terms: 175 AODV 176 Ad Hoc On-demand Distance Vector Routing[RFC3561]. 178 Source 179 The IPv6 router initiating the AODV-RPL route discovery. 181 Destination 182 The IPv6 router at the other end point of the P2P route(s) within 183 the LLN network. 185 Bi-directional Asymmetric Link 186 A link that can be used in both directions but with different link 187 characteristics. [I-D.thubert-roll-asymlink] 189 Instance-1 190 Instance used for control transmission from Source to Destination 191 and data transmission from Destination to Source. 193 Instance-2 194 Instance used for control transmission from Destination to Source 195 and data transmission from Source to Destination. 197 hop-by-hop routing 198 Routing when each node stores routing information about the next 199 hop towards Source or Destination. 201 Paired DODAGs 202 Two DODAGs for a single application. 204 P2P 205 Point-to-Point. 207 source routing 208 The mechanism by which the source supplies the complete route to 209 the destination along with each data packet [RFC6997]. 211 3. Overview of AODV-RPL 213 With AODV-RPL, routes from Source to Destination within the LLN 214 network are "on-demand"; in other words, the route discovery 215 mechanism in AODV-RPL will be performed reactively when source has 216 data for delivery to the Destination but existing routes do not 217 satisfy the application's requirements. Unlike base RPL [RFC6550] 218 and P2P-RPL [RFC6997], AODV-RPL can determine routes in networks with 219 bi-directional asymmetric links. In other words, AODV-RPL is 220 designed to discover two routes namely one from Source to Destination 221 and other from Destination to Source. In addition, AODV-RPL can also 222 support purely symmetric links for Paired DODAGs through "A" bit that 223 is explained in Section 4. 225 4. AODV Route Discovery Mode 227 In AODV-RPL, route discovery is initiated by forming a temporary DAG 228 rooted at the Source. Paired DODAGs are used to achieve bi- 229 directional asymmetrical link formation in between Source and 230 Destination. AODV-RPL is designed to support two instances. 231 Instance-1 is used for the route control messages from Source to 232 Destination whereas Instance-2 is used for route control messages 233 from Destination to Source (as shown in Figure 2). Intermediate 234 routers join the Paired DODAGs based on the rank determined from the 235 DIO message. Henceforth in this document, the DIO-RREQ-Instance-1 236 message represents the Route Discovery message from Source to 237 Destination whereas DIO-RREQ-Instance-2 represents the Route 238 Discovery message from Destination to Source. Subsequently, 239 Instance-1 is used for data transmission from Destination to Source 240 and Instance-2 is used for Data transmission from Source to 241 Destination. The operation of the discovery mechanism resembles base 242 RPL, extended by a new option called AODV-RREQ in a modified DIO 243 message [I-D.thubert-roll-asymlink]. A new bit called Asymmetric bit 244 ("A") is added to the base DIO message as shown in Figure 1. Source 245 will always set the "D" bit to 1 and "A" bit to 0 while initiating 246 the DIO-RREQ-Instance-1 message. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | RPLInstanceID |Version Number | Rank | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |G|D| MOP | Prf | DTSN | Flags |A| Reserved | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 + + 257 | | 258 + DODAGID + 259 | | 260 + + 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Option(s)... 265 Figure 1: Modified DI0 to support asymmetric links 267 The "D" bit in the DIO message indicates the directional DODAG 268 information whereas "A" bit describes the link nature (Asymmetric or 269 Symmetric). Figure 2 describes about operation of "A" bit for 270 symmetrical and asymmetrical links.If the DIO-RREQ-Instance-1 arrives 271 over an interface (Intermediate router) that is known to be 272 symmetric, and the 'A' bit is set to 0, then it remains set at 0 (see 273 Figure 2(a)). If the DIO-RREQ-Instance-1 arrives over an interface 274 that is not known to be symmetric, or is known to be asymmetric, then 275 the 'A' bit is set to be 1. If the 'A' bit arrives already set to be 276 '1', it is set to be '1' on retransmission (Figure 2(b)). The 'A' 277 bit is set to mean that the route is asymmetric. If any Intermediate 278 router along the way believes that the incoming link is asymmetric, 279 then the "A" bit is set to be 1 and remains set to be 1 all the way 280 to the destination. Otherwise if there are no asymmetric links the 281 "A" bit remains set to zero. Based on the "A" bit received by 282 Destination in DIO-RREQ-Instance-1, link nature (Asymmetric or 283 Symmetric) is decided to transmit DIO-RREQ-Instance-2 message back to 284 Source. 286 --Instance-1 (Control:S->D;Data:D->S) ------> 288 A=0 A=0 A=0 289 <--> <--> <--> 290 R--------R--------R--------R 291 | | | | 292 | A=0 | | A=0 | 293 A=0 |<--> | | <--> | A=0 A=0 294 <--> | | | | <--> <--> 295 S--------R--------R--------R--------R--------R---------D 296 | | | | | | 297 | | | | | | 298 | | | | | | 299 R--------R--------R--------R--------R---------R 301 <--Instance-2(Control:D->S;Data:S->D)-------- 303 (a). AODV-RPL with Symmetrical links 305 --Instance-1 (Control:S->D;Data:D->S) ------> 306 A=0 A=0 A=1 307 --> --> --> 308 R--------R--------R--------R 309 | | | | 310 |A=0 | | A=1 | 311 A=0 |--> | | --> | A=1 A=1 312 --> | | | ------ --> --> 313 S--------R--------R--------R--------R--------R---------D 314 | | | | | | 315 A=1 | | | | | | 316 <-- |A=1 | | | | |A=1 317 |<-- | | | | |<-- 318 | | | | | | 319 R--------R--------R--------R--------R---------R 321 A=1 A=1 A=1 A=1 A=1 322 <-- <-- <-- <-- <-- 324 <--Instance-2(Control:D->S;Data:S->D)-------- 326 (b). AODV-RPL with Asymmetrical links 328 S :Source 329 R :Intermediate nodes 330 D :Destination 332 Figure 2: AODV-RPL with Paired Instances 334 The value of 'A' bit (Symmetric or Asymmetric) can be decided by the 335 available radio resources (cells) (See Section.5) during DIO-RREQ- 336 Instance-1 message. Based on the received number of cell requests 337 (NumCell) from ADDRequest in DIO-RREQ-Instance-1, Intermediate node 338 will decide to set 'A' bit to '1' or remain to set 'A' bit to '0'. 339 For example, if intermediate node has resource (cells) to transmit 340 data for only one direction then it set A bit to '1'. If it has 341 resources (cells) to support data in both directions then it can 342 remain the 'A' bit to '0'. Even if there is atleast one link along 343 the path of DIO-RREQ-Instance-1 that does not have cells for both 344 directions then 'A' bit is set to '1' and Destination will start to 345 multicast DIO-RREQ-Instance-2(see Figure 2(b)). If all the 346 Intermediate nodes have cells for both directions then 'A' bit will 347 be remain to '0' and DIO-RREQ-Instance-2 is unicast back in same path 348 of DIO-RREQ-Instance-1 (see Figure 2(a)). 350 4.1. Route Discovery mode for DIO-RREQ-Instance-1 352 The AODV-RPL Source specifies the following information in the DIO- 353 RREQ-Instance-1 message: 355 - D-bit 357 Directional bit in the DIO base object (D=1 for DIO-RREQ- 358 Instance-1 message)[I-D.thubert-roll-asymlink]. 360 - A-bit 362 Asymmetric bit in the DIO base object (A=0 for DIO-RREQ-Instance-1 363 message). 365 - MOP bit 367 MOP operation in the DIO object MUST be set to "5(tbd)" by Source 368 for "AODV-RPL". 370 - RPLInstanceID 372 RPLInstanceID in the DIO object MUST be the InstanceID of 373 Instance-1. 375 - DODAGID 377 DODAGID in the DIO object MUST be the IPv6 address of the Source 378 that initiates the DIO-RREQ message of Instance-1. 380 - Rank 381 Rank in the DIO object MUST be the the rank of Instance-1. 383 - Metric Container Options 385 DIO-RREQ-Instance-1 message from Source MAY carry one or more 386 Metric Container options to specify the relevant routing metrics. 388 - Destination address 390 IPv6 address of the Destination that receives DIO-RREQ-Instance-1 391 message. This address MUST be in the modified RREQ option (see 392 Figure 3) of AODV [RFC3561]. 394 - G bit 396 G(Gratuitous RREP flag) bit is set to "1" when Source has 397 Destination Sequence number. When an intermediate node has a 398 route towards destination with higher Destination Sequence number 399 then Gratuitous DIO-RREP messages are unicast from the 400 intermediate node to Destination. Note that Intermediate nodes 401 never reply unicast Gratuitous DIO-RREP messages back to Source in 402 Instance-1. 404 - J bit 406 Derived from [RFC3561].Out of scope for this specification. 408 - R bit 410 Derived from [RFC3561].Out of scope for this specification. 412 - D bit 414 Derived from [RFC3561].Out of scope for this specification. 416 - U bit 418 Derived from [RFC3561].Out of scope for this specification. 420 The Source in Figure 2 will multicast the DIO-RREQ-Instance-1 message 421 (see Figure 3) to its one-hop neighbours. Intermediate nodes will 422 compute the rank for Instance-1 and create a routing table entry for 423 path towards the source if the routing metrics/constraints are 424 satisfied. Subsequently, it checks for already existing path towards 425 destination by comparing the Destination Sequence Numbers. Whenever 426 the path exists from intermediate node to Destination, it unicast the 427 Gratuitous DIO-RREP towards destination and creates the path towards 428 Source for Instance-1. This helps to minimize the route control 429 message multicast overhead during Route Discovery process. The 430 message format of Gratuitous DIO-RREP is same as [RFC3561] with the 431 exception of the Source IP address which can be obtained through 432 DODAGID of DIO base (see Figure 1). If the path towards Destination 433 does not exist, the intermediate node has to re-multicast the DIO- 434 RREQ-Instance-1 message with updated rank to the next-hop neighbours 435 until the message reaches to Destination(Figure 2). Based on the "A" 436 bit in received DIO-RREQ_instance-1, Destination will decide to 437 unicast or multicast the DIO-RREQ-Instance-2 message back to Source. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type |J|R|G|D|U| Reserved | Hop Count | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Destination IP Address | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Destination Sequence Number | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Originator Sequence Number | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 3: Modified DIO-RREQ message format 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Type |R|A| Reserved |Prefix Sz| Hop Count | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Destination IP Address | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Destination Sequence Number | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Lifetime | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 4: DIO-Gratuitous-RREP message format 467 4.2. Route Discovery mode for DIO-RREQ-Instance-2 469 The AODV-RPL Destination specifies the following information in the 470 DIO-RREQ-Instance-2 message: 472 - D-bit 474 Directional bit in the DIO base object (D=1 for DIO-RREQ- 475 Instance-2 message)[I-D.thubert-roll-asymlink]. 477 - A-bit 479 Asymmetric bit in the DIO base object (value of "A" bit for DIO- 480 RREQ-Instance-2 is directly copied from "A" bit of DIO-RREQ- 481 Instance-1 message). 483 - MOP bit 485 MOP operation in the DIO object MUST be set to "5(tbd)" by 486 Destination for "AODV-RPL". 488 - RPLInstanceID 490 RPLInstanceID in the DIO object MUST be the InstanceID of 491 Instance-2. 493 - DODAGID 495 DODAGID in the DIO object MUST be the IPv6 address of the 496 Destination that initiates the DIO-RREQ message of Instance-2. 498 - Rank 500 Rank in the DIO object MUST be the the rank of Instance-2. 502 - Metric Container Options 504 DIO-RREQ-Instance-2 message from Destination MAY carry one or more 505 Metric Container options to specify the relevant routing metrics. 507 - Destination address 509 IPv6 address of the Source that receives DIO-RREQ-Instance-2 510 message. This address MUST be in the modified RREQ option (see 511 Figure 3) of AODV [RFC3561]. 513 - G bit 515 G(Gratuitous RREP flag) bit is set to "1" when Destination has 516 Source Sequence number. When an Intermediate node has a route 517 towards Source with higher Source Sequence number then Gratuitous 518 DIO-RREP messages are unicast from Intermediate node to Source. 519 Note that Intermediate nodes never reply unicast DIO-RREP messages 520 back to Destination in Instance-2. 522 - J bit 524 Derived from [RFC3561].Out of scope for this specification. 526 - R bit 528 Derived from [RFC3561].Out of scope for this specification. 530 - D bit 532 Derived from [RFC3561].Out of scope for this specification. 534 - U bit 536 Derived from [RFC3561].Out of scope for this specification. 538 The Destination in Figure 2 start to multicast the DIO-RREQ- 539 Instance-2 message when the received "A" bit in DIO-RREQ-Instance-1 540 is set to 1. Intermediate nodes will create the routing tables for 541 the path towards the Destination during DIO-RREQ-Instance-2 messages 542 to Source. If the intermediate nodes have path towards the Source, 543 then it unicast the Gratuitous DIO-RREP towards the Source and 544 creates the path towards Destination for Instance-2. Once the route 545 control message is reached to Source, it will start transmitting the 546 application data packets to the Destination in the path that is 547 discovered through DIO-RREQ-Instance-2 messages. Similarly, 548 application data from Destination to Source is transmitted through 549 the path that is discovered from DIO-RREQ-Instance-1 message. 551 The Destination in Figure 2 start to unicast the DIO-RREQ-Instance-2 552 message when the received "A" bit in DIO-RREQ-Instance-1 is set to 0. 553 In this case, route control messages and application data in between 554 Source and Destination for both Instance-1 and Instance-2 are 555 transmitted in symmetrical links. 557 5. Resource reservation for P2P Communication at 6TOP 559 Whenever, Source has data to destination it runs the Bandwidth 560 Estimation Algorithm (BEA)[I-D.dujovne-6tisch-6top-sf0] to estimate 561 the application bandwidth requirement and map it to required number 562 of cells. Subsequently, 6P ADD Request 563 [I-D.wang-6tisch-6top-sublayer] is appended to the DIO-RREQ- 564 Instance-1 with NumCells equal to application bandwidth requirement 565 that is known through BEA. It is noteworthy that CellList 566 (slotoffset, channeloffset) and Container information in 6P ADD 567 Request is set to zero during DIO-RREQ-Instance-1 multicast from 568 Source. Once the DIO-RREQ-Instance-1 with 6P ADD Request is reached 569 to intermediate node, it checks the NumCells field. When an 570 Intermediate node is able to allocate its transmit and receive cells 571 that are equal to NumCells of 6P ADD Request, then it is eligible to 572 re-multicast the DIO-RREQ-Instance-1 with 6P ADD Request. At this 573 point, link nature (Symmetrical or Asymmetrical) is decided by 574 Intermediate node based on the available resources (cells). If an 575 Intermediate node has transmit and receive cells for both directions 576 that are greater than or equal to NumCells of 6P ADD Request then 'A' 577 bit is remain to set to '0'. If an intermediate node has cells 578 available only for one direction (Destination to Source) then 'A' bit 579 is set to '1' and it re-multicast the DIO-RREQ-Instance-1. Whenever, 580 the intermediate node has Destination Sequence number that is greater 581 than Sequence number specified in modified-RREQ then Gratuitous-RREP 582 is unicast with 6P ADD Request. It is assumed that Intermediate 583 nodes who know the path towards the Destination must be able to 584 allocate both transmit and receive cells that are specified in 585 NumCells to either single direction (Asymmetric) or both directions 586 (Symmetric). Once the DIO-RREQ-Instance-1 with 6P ADD Request 587 reaches to the Destination, it checks the 'A' bit to reply the DIO- 588 RREQ_Instance-2 messages. 590 For Asymmetrical links(A=1) to Instance-1, it is notable that Source 591 will allocate only receive cells, Destination will allocate only 592 transmit cells and Intermediate nodes that multicast route control 593 messages will allocate both transmit and receive cells to perform 594 data transmission from Destination to Source in Instance-1. 596 For asymmetrical links (A=1) to Instance-2, Destination will estimate 597 the application bandwidth requirement through BEA and map it to 598 Numcell for DIO-RREQ-Instance-2. It is noteworthy that 599 CellList(slotoffset, channeloffset) and Container information in 6P 600 ADD Request is set to zero during DIO-RREQ-Instance-2 multicast from 601 Destination. Intermediate nodes that are able to allocate it's both 602 transmit and receive cells of Numcell in 6P ADD Request will re- 603 multicast the DIO-RREQ-Instance-2 with 6P ADD Request until it 604 reaches to Source. In this case, 'A' bit is always set to '1'. From 605 this operation, it is notable that Source will allocate only transmit 606 cells, Destination will allocate only receive cells and Intermediate 607 nodes that multicast route control messages will allocate both 608 transmit and receive cells to perform data transmission from Source 609 to Destination in Instance-2. 611 Once the Source know the path towards the Destination in Instance-2, 612 it performs the actual 6P negotiation (6P ADD Request, 6P ADD 613 Response) [I-D.wang-6tisch-6top-sublayer] to request and allocates 614 the CellList (slotoffset, channeloffset) hop-by-hop for actual data 615 transmission. Similarly, Destination will perform 6P negotiation (6P 616 ADD Request, 6P ADD Response) [I-D.wang-6tisch-6top-sublayer] to 617 request and allocate the CellList(slotoffset, channeloffset) hop-by- 618 hop towards Source in Instance-1 for data transmission. The 619 cells(bundle) allocated for end-to-end path in Instance-1 is 620 associated with one TrackID and the cells allocated for end-to-end 621 path in Instance-2 is associated with another TrackID. 623 For asymmetrical links (A=1), allocation of transmit-receive cells 624 for Instance-1 and allocation of transmit-receive cells for 625 Instance-2 will be in different paths. 627 For symmetrical links (A=0), Source and Destination will use same 628 path for both Instance-1 and Instance-2 to transmit data. Hence, 629 allocation of transmit-receive cells for Instance-1 and allocation of 630 transmit-receive cells for Instance-2 need to be in same path. 632 With AODV-RPL, the address vector is not required and resource 633 reservation (cell allocation) is on-demand during reactive route- 634 discovery. This efficiently utilizes the control packet size and 635 radio resources that is most significant in 6tisch networks. 637 5.1. Operation of Trickle TImer 639 The operation of Trickle timer to control DIO-RREQ-Instance 1/ 640 Instance-2 message is similar to P2P-RPL Trickle operation [RFC6997]. 642 6. IANA Considerations 644 6.1. Additions to Mode of Operation 646 IANA is required to assign a new Mode of Operation, named "AODV-RPL" 647 for Point-to-Point(P2P) hop-by-hop routing under the RPL registry. 648 The value of tbd1 is assigned from the "Mode of Operation" space 649 [RFC6550]. 651 +-------------+---------------+---------------+ 652 | Value | Description | Reference | 653 +-------------+---------------+---------------+ 654 | tbd1(5) | AODV-RPL | This document | 655 +-------------+---------------+---------------+ 657 Figure 5: Mode of Operation 659 6.2. Additions to RPL Control Message Options 661 IANA is require to assign two entries for a new RPL options: "DIO- 662 RREQ-Instance-1" and "DIO-RREQ-Instance-1" values of tbd2 (0x0a) and 663 tbd3(0x0b) from the "RPL Control Message Options" space [RFC6550]. 665 +-------------+----------------------+---------------+ 666 | Value | Meaning | Reference | 667 +-------------+----------------------+---------------+ 668 | tbd2(0x0a) | DIO-RREQ-Instance-1 | This document | 669 +-------------+----------------------+---------------+ 670 | tbd3(0x0b) | DIO-RREQ-Instance-2 | This document | 671 +-------------+----------------------+---------------+ 673 Figure 6: RPL Control Message Options 675 7. Security Considerations 677 This document does not introduce additional security issues to 678 [RFC6550]. For general RPL security considerations, see [RFC6550]. 680 8. References 682 8.1. References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, 686 DOI 10.17487/RFC2119, March 1997, 687 . 689 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 690 Demand Distance Vector (AODV) Routing", RFC 3561, 691 DOI 10.17487/RFC3561, July 2003, 692 . 694 [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and 695 D. Barthel, Ed., "Routing Requirements for Urban Low-Power 696 and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 697 2009, . 699 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 700 Phinney, "Industrial Routing Requirements in Low-Power and 701 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 702 2009, . 704 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 705 Routing Requirements in Low-Power and Lossy Networks", 706 RFC 5826, DOI 10.17487/RFC5826, April 2010, 707 . 709 [RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, 710 "Building Automation Routing Requirements in Low-Power and 711 Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June 712 2010, . 714 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 715 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 716 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 717 Low-Power and Lossy Networks", RFC 6550, 718 DOI 10.17487/RFC6550, March 2012, 719 . 721 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 722 Protocol for Low-Power and Lossy Networks (RPL)", 723 RFC 6552, DOI 10.17487/RFC6552, March 2012, 724 . 726 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 727 J. Martocci, "Reactive Discovery of Point-to-Point Routes 728 in Low-Power and Lossy Networks", RFC 6997, 729 DOI 10.17487/RFC6997, August 2013, 730 . 732 [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, 733 "A Mechanism to Measure the Routing Metrics along a Point- 734 to-Point Route in a Low-Power and Lossy Network", 735 RFC 6998, DOI 10.17487/RFC6998, August 2013, 736 . 738 8.2. Informative References 740 [I-D.dujovne-6tisch-6top-sf0] 741 Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, 742 "6TiSCH 6top Scheduling Function Zero (SF0)", draft- 743 dujovne-6tisch-6top-sf0-00 (work in progress), October 744 2015. 746 [I-D.grossman-detnet-use-cases] 747 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 748 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y. 749 Zha, "Deterministic Networking Use Cases", draft-grossman- 750 detnet-use-cases-01 (work in progress), November 2015. 752 [I-D.ietf-6tisch-minimal] 753 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 754 Configuration", draft-ietf-6tisch-minimal-15 (work in 755 progress), February 2016. 757 [I-D.thubert-roll-asymlink] 758 Thubert, P., "RPL adaptation for asymmetrical links", 759 draft-thubert-roll-asymlink-02 (work in progress), 760 December 2011. 762 [I-D.wang-6tisch-6top-sublayer] 763 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 764 (6top)", draft-wang-6tisch-6top-sublayer-04 (work in 765 progress), November 2015. 767 Authors' Addresses 769 Satish Anamalamudi 770 Huawei Technologies 771 No. 156 Beiqing Rd. Haidian District 772 Beijing 100095 773 China 775 Email: satish.anamalamudi@huawei.com 777 Mingui Zhang 778 Huawei Technologies 779 No. 156 Beiqing Rd. Haidian District 780 Beijing 100095 781 China 783 Email: zhangmingui@huawei.com 785 Charles E. Perkins 786 Futurewei 787 2330 Central Expressway 788 Santa Clara 95050 789 Unites States 791 Email: charliep@computer.org 793 Dongxin Liu 794 China Telcom Co., Ltd 795 109 West Zhongshan Ave, Tianhe District 796 Guangzhou 510630 797 China 799 Email: liudx@gsta.com 800 S.V.R Anand 801 Indian Institute of Science 802 Bangalore 803 560012 804 India 806 Email: anand@ece.iisc.ernet.in