idnits 2.17.1 draft-pu-6lo-multipath-transmission-03.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 -- The document date (September 21, 2018) is 2042 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) == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-04 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-problem-statement-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 6lo C. Pu 2 Internet Draft Y. Wang 3 Intended status: Standards Track H. Wang 4 Expires: March 25, 2019 Y. Yang 5 P. Wang 6 Chongqing University of 7 Posts and Telecommunications 8 September 21, 2018 10 Multipath Transmission for 6LoWPAN Networks 11 draft-pu-6lo-multipath-transmission-03 13 Abstract 15 This document provides a multipath transmission method for 6LoWPAN 16 Networks, which can effectively provide the transmission redundancy 17 for packets. It is suitable for high-reliability networks, 18 especially for IPv6-based industrial wireless scenarios. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on March 25, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ................................................ 2 61 2. 6LoWPAN Multipath Header Format.............................. 3 62 3. Architecture ................................................ 3 63 4. Number of Paths Destination.................................. 4 64 5. Multipath Distribution....................................... 5 65 6. Packet Replication and Elimination........................... 7 66 7. Security Considerations...................................... 8 67 8. IANA Considerations ......................................... 8 68 9. References .................................................. 8 69 9.1. Normative References.................................... 8 70 9.2. Informative References.................................. 9 71 Authors' Addresses ............................................ 10 73 1. Introduction 75 6LoWPAN can deploy large-scale and high-density wireless personal 76 area network devices with its high popularity, applicability, and 77 more address space. However, due to the low processing power, the 78 limited energy and the poor communication environment of the 6LoWPAN 79 network, packets are easily lost during transmission, which causes 80 transmission failure. The use of multipath packet transmission 81 technology in 6LoWPAN is of great significance for improving 82 communication reliability and transmission performance. It is well 83 known that RPL as a routing protocol standardized by IETF, is an 84 efficient distance vector protocol for wireless sensor networks, 85 which has designed a series of new mechanisms [RFC6550], and is 86 widely used in 6LoWPAN. Aiming at the explicit requirement of multi- 87 path packet transmission for 6LoWPAN, this document proposes an RPL- 88 based multipath transmission method, which improves the success rate 89 of packets transmission in uplink networks and further enhances the 90 transmission reliability. 92 2. 6LoWPAN Multipath Header Format 94 6LoWPAN multipath header designed at the adaptation layer contains 95 the multipath header type field, the sequence number field of the 96 multipath package (SequenceNumber) and the path number field 97 (PathCount) [RFC4944], as depicted in Figure 1. 99 0 1 2 3 100 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 2 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Multipath | Sequence Number | Path Number | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Figure 1: 6LoWPAN Multipath Header Format 106 Field definitions are as follows. 108 Multipath: Different types of headers at the adaptation layer must 109 have a length of 8-bit header type field. The multipath field is 110 the header type field of 6LoWPAN Multipath Header that uses the 111 Dispatch Value Bit Pattern of 11101000. 113 Sequence Number: This field contains the unique sequence number 114 SequenceNumber of packets, and its length is 16 bits. 116 Path Number: This field includes the number of paths PathCount that 117 needs to be filled in the packet, and its length is 8 bit. 119 3. Architecture 121 The following figure 2 shows the architecture of the 6LoWPAN 122 protocol stack. In this architecture, the IP layer uses RPL to 123 realize the multipath transmission. Moreover, at the adaptation 124 layer, the multipath transmission entity is achieved by designing a 125 multipath header. The encapsulation of multipath packets and the 126 transmission of multipath packets can be implemented by using above 127 methods. 129 +---------------------------------------------------+ 130 | COAP Application Layer XMPP | 131 |---------------------------------------------------| 132 | UDP Transport Layer | 133 |---------------------------------------------------| 134 | ---------- --------------| 135 | |RPL|IPv6| IP Layer | Multipath|| 136 | ---------- |Transmission|| 137 | --------------| 138 |---------------------------------------------------| 139 | ------------------| 140 | Fragmentation Adaptation Layer| Multipath|| 141 | Header Compression |Transport Entity|| 142 | ------------------| 143 |---------------------------------------------------| 144 | CSMA/CA Mac Layer | 145 |---------------------------------------------------| 146 | Channel Detection Physical Layer | 147 +---------------------------------------------------+ 148 Figure 2: 6LoWPAN Protocol Stack Architecture 150 Before the source node sends a message, it is necessary to determine 151 the number of paths P according to reliability requirements. Then we 152 need to assign one or more paths for each parent node at the IP 153 layer through the rank value. The rank value is calculated according 154 to the residual energy value and the hop value to the sink node from 155 the source node [RFC6551], [RFC6552]. The number of paths is 156 encapsulated into the multipath header of the message at the 157 adaptation layer before sending the message to the parent node. In 158 addition, each intermediate routing node forwards the message 159 according to the above method until it reaches the sink node. 161 4. Number of Paths Destination 163 Before the source node sends packets, it is needed to first 164 determine the number of transmission paths. By determining the 165 number of suitable paths, the end-to-end transmission success rate 166 can be effectively improved, and the transmission reliability of the 167 network can be further improved. 169 ETX refers to the number of expected transmissions of a link and is 170 an important criterion for evaluating the quality of links in the 171 network. This paper uses ETX to confirm the number of paths and 172 balance the link quality of each path. At the same time, it selects 173 the path with better quality, thereby increases the transmission 174 success rate of the network. 176 Assume that there are n paths in the network, each path has a, b, c, 177 d,...links, then the total ETX value of path a can be calculated by 178 following formula: 180 E1 = L1 + L2 + ... + La. 182 Similarly, the total ETX values of the path b, path c, and path d 183 are 185 E2 = L1+L2+...+Lb, E3 = L1+L2+...+Lc, E4 = L1+L2+...+Ld, and 186 so on. 188 Among them, li represents the ETX of the link i in each path, so the 189 transmission success rate of the path a is 191 p1 = 1 / E1. 193 Similarly, the transmission success rate of the path b, path c, and 194 path d are 196 p2 = 1 / E2, p3 = 1 / E3, p4 = 1 / E4, and so on. 198 Then, the transmission success rate of the entire network is the sum 199 of the transmission success rates of all the paths, that is 201 p = p1 + p2 + p3 + ... + pi + ... + pn. 203 Where p represents the success rate of the entire network, and pi 204 represents the transmission success rate of path i. Sort p1 to pn 205 from largest to smallest, followed by p11, p12, p13,..., p1i,...p1n. 206 In order to ensure the success rate of one transmission, calculating 207 the following formula: 209 p = p11 + p12 + p13 + ... + p1i >= 1. 211 When the above formula is established, then i is the number of 212 required path. 214 5. Multipath Distribution 216 If the required number of paths P is greater than the total number 217 of parent nodes N in the collection of RPL parent nodes, multiple 218 paths are assigned to each parent node according to the size 219 relation among the rank values of all parent nodes. The following 220 formula is used. 222 Pm = round (P/Rm/R) where R = 1/R1 + 1/R2 + ... + 1/Rn 224 Here, round() presents the rounding function, rounding for the 225 calculation result of (P/Rm/R). P is the total number of paths. Pm 226 shows the number of paths allocated for parent node m. Rm represents 227 the Rank value corresponding to the parent node m (m=1,2,...n). The 228 above situation is shown as Figure 3. 230 +---------------------------------------------------+ 231 | rank2=500 P2=1 | 232 | +------------>(R1)----> ..... | 233 | | | 234 | | | 235 | | /---->(R3)---->(R4)----> .....\ | 236 | |rank1=100 P1=5/ \ | 237 |(S) ---------->(R2).....--->(R5)--->(R6)---> ...(D)| 238 | |P=8 \ / | 239 | | \---->(R7)---->(R8)----> ...../ | 240 | | | 241 | |rank3=200 P3=2 /----> ..... | 242 | +---------------->(R9) | 243 | \----> ..... | 244 +---------------------------------------------------+ 245 Figure 3: The Transmission Process of P>N 247 If the number of paths P is less than or equal to the total number 248 of parent nodes, P rank values are selected according to the rise 249 order of rank values, and one path is assigned to the parent node 250 corresponding to each rank value, as shown in Figure 4. 252 +---------------------------------------------------+ 253 | rank2=500 P2=1 | 254 | +---------------->(R1)---->(R2)---->(R3)......... | 255 | | | | 256 | | rank1=100 P1=1 | | 257 | | /-------------->(R4)---->(R5)---->(R6)......\ | | 258 | |/ \| | 259 |(S)P=3 (D)| 260 | .\rank3=200 P3=1 /. | 261 | . \-------------->(R7)---->(R8)---->(R9)....../ . | 262 | . . | 263 | . rank4=600 P4=0 . | 264 | ..................(10)....(R11)....(R12)......... | 265 | | 266 +---------------------------------------------------+ 267 Figure 4: The Transmission Process of P<=N 269 6. Packet Replication and Elimination 271 The process of packet multipath transmission also includes packet 272 replication and elimination. A detailed description is given as 273 following five steps. 275 1) When the multipath transport entity of the adaptation layer 276 receives the packet from the upper layer of the protocol stack, it 277 first confirms the total number of paths P of the transmission 278 packet according to the reliability requirements of the packet. When 279 P is less than or equal to 1, it indicates that the packet does not 280 need to use multipath transmission, then the packet can be forwarded 281 directly. 283 2) When the total number of paths P is larger than 1, the number of 284 the replicated packets PathCount that needs to be forwarded by each 285 parent node in the collection of RPL parent nodes is allocated using 286 the multipath packet allocation method [I-D.ietf-detnet- 287 architecture], [I-D.ietf-detnet-problem-statement]. 289 3) For the parent node that PathCount is greater than or equal to 290 1, the multipath transport entity replicates the packet and adds the 291 multipath header at the adaptation layer, and then sends the packet 292 to the parent node. In this case, the packet sequence number 293 SequenceNumber of the multipath header in all replicated packets 294 must be concurrent and it can be accumulated when the next new 295 packet is sent. The path number field is filled with the 296 corresponding number of copies PathCount. For the parent node whose 297 number of copies PathCount is less than 1, the source node does not 298 send the packet. 300 4) After the intermediate routing node receives the packet 301 including the multipath header, it judges whether the number of 302 paths PathCount is equal to 1 in the multipath header. If PathCount 303 is equal to 1, the intermediate node sends the packet directly with 304 the value of each field in the multipath header constant. If 305 PathCount is greater than 1, the node replicate PathCount copies of 306 the packet and distributes them to multiple paths. Repeating step 2 307 and 3, and in step 2, P is equal to PathCount. In step 3, the new 308 multipath header is not added, the SequenceNumber of the packet is 309 unchanged, and the path number field is filled with the new 310 corresponding number of copies. 312 5) When a destination node receives a packet containing the 313 multipath header, it can distinguish whether the packet has been 314 received according to the source address and the packet sequence 315 number in the multipath header. If the destination node has not 316 received the packet before, the node forwards the packet to its 317 upper layer protocol directly. Otherwise, the node discards the 318 packet [I-D.ietf-detnet-architecture], [I-D.ietf-detnet-problem- 319 statement]. 321 7. Security Considerations 323 This document does not add any new security considerations other 324 than what is already mentioned in the referenced technology. 326 8. IANA Considerations 328 This document creates an IANA registry for 6LoWPAN Multipath Header 329 Type, and assigns the following dispatch type values: 331 11101000: for 6LoWPAN Multipath Header Type. 333 9. References 335 9.1. Normative References 337 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 338 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., 339 and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power 340 and Lossy Networks", RFC 6550, March 2012, 341 . 343 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 344 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 345 RFC 4944, September 2007, 346 . 348 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and 349 D. Barthel, "Routing Metrics Used for Path Calculation in 350 Low-Power and Lossy Networks", RFC 6551, March 2012, 351 . 353 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 354 Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, 355 March 2012, . 357 9.2. Informative References 359 [I-D.ietf-detnet-architecture] 360 Finn, N. and P. Thubert, "Deterministic Networking 361 Architecture", draft-ietf-detnet-architecture-04 (work in 362 progress), August 2017. 364 [I-D.ietf-detnet-problem-statement] 365 Finn, N. and P. Thubert, "Deterministic Networking Problem 366 Statement", draft-ietf-detnet-problem-statement-02 (work in 367 progress), September 2016. 369 Authors' Addresses 371 Chenggen Pu 372 Chongqing University of Posts and Telecommunications 373 2 Chongwen Road 374 Chongqing, 400065 375 China 377 Phone: (86)-23-6246-1061 378 Email: mentospcg@163.com 380 Yadong Wang 381 Chongqing University of Posts and Telecommunications 382 2 Chongwen Road 383 Chongqing, 400065 384 China 386 Phone: (86)-23-6246-1061 387 Email: 13618266302@163.com 389 Heng Wang 390 Chongqing University of Posts and Telecommunications 391 2 Chongwen Road 392 Chongqing, 400065 393 China 395 Phone: (86)-23-6248-7845 396 Email: wangheng@cqupt.edu.cn 398 Yi Yang 399 Chongqing University of Posts and Telecommunications 400 2 Chongwen Road 401 Chongqing, 400065 402 China 404 Phone: (86)-23-6246-1061 405 Email: 15023705316@163.com 407 Ping Wang 408 Chongqing University of Posts and Telecommunications 409 2 Chongwen Road 410 Chongqing, 400065 411 China 413 Phone: (86)-23-6246-1061 414 Email: wangping@cqupt.edu.cn