idnits 2.17.1 draft-pu-6lo-multipath-transmission-02.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 (March 18, 2018) is 2230 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: September 19, 2018 Y. Yang 5 P. Wang 6 Chongqing University of 7 Posts and Telecommunications 8 March 18, 2018 10 Multipath Transmission for 6LoWPAN Networks 11 draft-pu-6lo-multipath-transmission-02 13 Abstract 15 This document provides a multipath transmission method for 6LoWPAN 16 Networks, which can effectively offer the transmission redundancy of 17 packets. It is applicable for high-reliability networks, especially 18 for IPv6-based wireless industrial 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 September 19, 2018. 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 has high popularity and applicability, and has more address 76 space that can realize the deployment of large-scale and high- 77 density wireless personal area network devices. However, packets are 78 prone to be lost during transmission due to the low processing power, 79 limited energy and poor communication environment in 6LoWPAN, which 80 results in transmission failure. In order to increase the 81 communication reliability and improve the transmission performance, 82 it is of great significance to introduce multipath packet 83 transmission technology in 6LoWPAN. It is well known that RPL as a 84 routing protocol standardized by IETF, is an efficient distance 85 vector protocol for wireless sensor networks, which has designed a 86 series of new mechanisms [RFC6550], and is widely used in 6LoWPAN. 87 Aiming at the explicit requirement of multi-path packet transmission 88 for 6LoWPAN, this document proposes an RPL-based multipath 89 transmission method, which improves the success rate of packets 90 transmission in uplink networks and further enhances the 91 transmission reliability. 93 2. 6LoWPAN Multipath Header Format 95 6LoWPAN multipath header designed at the adaptation layer contains 96 the multipath header type field, the sequence number field of the 97 multipath package (SequenceNumber) and the path number field 98 (PathCount) [RFC4944], as depicted in Figure 1. 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Multipath | Sequence Number | Path Number | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 Figure 1: 6LoWPAN Multipath Header Format 107 Field definitions are as follows. 109 Multipath: Different types of headers at the adaptation layer must 110 have a length of 8-bit header type field. The multipath field is 111 the header type field of 6LoWPAN Multipath Header that uses the 112 Dispatch Value Bit Pattern of 11101000. 114 Sequence Number: This field contains the unique sequence number 115 SequenceNumber of packets, and its length is 16 bits. 117 Path Number: This field includes the number of paths PathCount that 118 needs to be filled in the packet, and its length is 8 bit. 120 3. Architecture 122 The following figure 2 shows the architecture of the 6LoWPAN 123 protocol stack. In this architecture, the IP layer uses RPL to 124 realize the multipath transmission. Moreover, at the adaptation 125 layer, the multipath transmission entity is achieved by designing a 126 multipath header. The encapsulation of multipath packets and the 127 transmission of multipath packets can be implemented by using above 128 methods. 130 +---------------------------------------------------+ 131 | COAP Application Layer XMPP | 132 |---------------------------------------------------| 133 | UDP Transport Layer | 134 |---------------------------------------------------| 135 | ---------- --------------| 136 | |RPL|IPv6| IP Layer | Multipath|| 137 | ---------- |Transmission|| 138 | --------------| 139 |---------------------------------------------------| 140 | ------------------| 141 | Fragmentation Adaptation Layer| Multipath|| 142 | Header Compression |Transport Entity|| 143 | ------------------| 144 |---------------------------------------------------| 145 | CSMA/CA Mac Layer | 146 |---------------------------------------------------| 147 | Channel Detection Physical Layer | 148 +---------------------------------------------------+ 149 Figure 2: 6LoWPAN Protocol Stack Architecture 151 Before the source node sends a message, it is necessary to determine 152 the number of paths P according to reliability requirements. Then we 153 need to assign one or more paths for each parent node at the IP 154 layer through the rank value. The rank value is calculated according 155 to the residual energy value and the hop value to the sink node from 156 the source node [RFC6551], [RFC6552]. The number of paths is 157 encapsulated into the multipath header of the message at the 158 adaptation layer before sending the message to the parent node. In 159 addition, each intermediate routing node forwards the message 160 according to the above method until it reaches the sink node. 162 4. Number of Paths Destination 164 Before the source node sends packets, it is needed to first 165 determine the number of transmission paths. It can effectively 166 improve the end-to-end transmission success rate and further improve 167 the transmission reliability of the network by determining the 168 number of suitable paths. 170 ETX refers to the number of expected transmissions of a link and is 171 an important criterion for evaluating the quality of links in the 172 network. This paper uses ETX to confirm the number of paths and 173 balance the link quality of each path. At the same time, it selects 174 the path with better quality and thereby improves the transmission 175 success rate of the network. 177 Assume that there are n paths in the network, each path has a, b, c, 178 d,...links, then the total ETX value of path a can be calculated by 179 following formula: 181 E1 = L1 + L2 + ... + La. 183 Similarly, the total ETX values of the path b, path c, and path d 184 are 186 E2 = L1+L2+ ... +Lb, E3 = L1+L2+ ... +Lc, E4 = L1+L2+ ... +Ld, and 187 so on. 189 Among them, li represents the ETX of the link i in each path, so the 190 transmission success rate of the path a is 192 p1 = 1 / E1. 194 Similarly, the transmission success rate of the path b, path c, and 195 path d are 197 p2 = 1 / E2, p3 = 1 / E3, p4 = 1 / E4, and so on. 199 Then, the transmission success rate of the entire network is the sum 200 of the transmission success rates of all the paths, that is 202 p = p1 + p2 + p3 + ... + pi + ... + pn. 204 Where p represents the success rate of the entire network, and pi 205 represents the transmission success rate of path i. Sort p1 to pn 206 from largest to smallest, followed by p11, p12, p13,..., p1i,...p1n. 207 In order to ensure the success rate of one transmission, calculating 208 the following formula: 210 p = p11 + p12 + p13 + ... + p1i >= 1. 212 When the above formula is established, then i is the number of 213 required path. 215 5. Multipath Distribution 217 If the required number of paths P is greater than the total number 218 of parent nodes N in the collection of RPL parent nodes, multiple 219 paths are assigned to each parent node according to the size 220 relation among the rank values of all parent nodes. The following 221 formula is used. 223 Pm = round (P/Rm/R) where R = 1/R1 + 1/R2 + ... + 1/Rn 225 Here, round() presents the rounding function, rounding for the 226 calculation result of (P/Rm/R). P is the total number of paths. Pm 227 shows the number of paths allocated for parent node m. Rm represents 228 the Rank value corresponding to the parent node m (m=1,2,...,n). The 229 above situation is shown as Figure 3. 231 +---------------------------------------------------+ 232 | rank2=500 P2=1 | 233 | +------------>(R1)----> ..... | 234 | | | 235 | | | 236 | | /---->(R3)---->(R4)----> .....\ | 237 | |rank1=100 P1=5/ \ | 238 |(S) ---------->(R2).....--->(R5)--->(R6)---> ...(D)| 239 | |P=8 \ / | 240 | | \---->(R7)---->(R8)----> ...../ | 241 | | | 242 | |rank3=200 P3=2 /----> ..... | 243 | +---------------->(R9) | 244 | \----> ..... | 245 +---------------------------------------------------+ 246 Figure 3: The Transmission Process of P>N 248 If the number of paths P is less than or equal to the total number 249 of parent nodes, P rank values are selected according to the rise 250 order of rank values, and one path is assigned to the parent node 251 corresponding to each rank value, as shown in Figure 4. 253 +---------------------------------------------------+ 254 | rank2=500 P2=1 | 255 | +---------------->(R1)---->(R2)---->(R3)......... | 256 | | | | 257 | | rank1=100 P1=1 | | 258 | | /-------------->(R4)---->(R5)---->(R6)......\ | | 259 | |/ \| | 260 |(S)P=3 (D)| 261 | .\rank3=200 P3=1 /. | 262 | . \-------------->(R7)---->(R8)---->(R9)....../ . | 263 | . . | 264 | . rank4=600 P4=0 . | 265 | ..................(10)....(R11)....(R12)......... | 266 | | 267 +---------------------------------------------------+ 268 Figure 4: The Transmission Process of P<=N 270 6. Packet Replication and Elimination 272 The process of packet multipath transmission also includes packet 273 replication and elimination. A detailed description is given as 274 following five steps. 276 1) When the multipath transport entity of the adaptation layer 277 receives the packet from the upper layer of the protocol stack, it 278 first confirms the total number of paths P of the transmission 279 packet according to the reliability requirements of the packet. When 280 P is less than or equal to 1, it indicates that the packet does not 281 need to use multipath transmission, then the packet can be forwarded 282 directly. 284 2) When the total number of paths P is larger than 1, the number of 285 the replicated packets PathCount that needs to be forwarded by each 286 parent node in the collection of RPL parent nodes is allocated using 287 the multipath packet allocation method [I-D.ietf-detnet- 288 architecture], [I-D.ietf-detnet-problem-statement]. 290 3) For the parent node that PathCount is greater than or equal to 291 1, the multipath transport entity replicates the packet and adds the 292 multipath header at the adaptation layer, and then sends the packet 293 to the parent node. In this case, the packet sequence number 294 SequenceNumber of the multipath header in all replicated packets 295 must be concurrent and it can be accumulated when the next new 296 packet is sent. The path number field is filled with the 297 corresponding number of copies PathCount. For the parent node whose 298 number of copies PathCount is less than 1, the source node does not 299 send the packet. 301 4) After the intermediate routing node receives the packet 302 including the multipath header, it judges whether the number of 303 paths PathCount in the multipath header is equal to 1. If PathCount 304 is equal to 1, the intermediate node sends the packet directly with 305 the value of each field in the multipath header constant. If 306 PathCount is greater than 1, the node has to replicate PathCount 307 copies of the packet and distributes them to multiple paths. 308 Repeating step 2 and 3, and in step 2, P is equal to PathCount. In 309 step 3, the new multipath header is not added, the SequenceNumber of 310 the packet is unchanged, and the path number field is filled with 311 the new corresponding number of copies. 313 5) When a destination node receives a packet containing the 314 multipath header, it can distinguish whether the packet has been 315 received according to the source address and the packet sequence 316 number in the multipath header. If the destination node has not 317 received the packet before, the node forwards the packet to its 318 upper layer protocol directly. Otherwise, the node discards the 319 packet [I-D.ietf-detnet-architecture], [I-D.ietf-detnet-problem- 320 statement]. 322 7. Security Considerations 324 This document does not add any new security considerations beyond 325 what the referenced technologies already have. 327 8. IANA Considerations 329 This document creates an IANA registry for 6LoWPAN Multipath Header 330 Type, and assigns the following dispatch type values: 332 11101000: for 6LoWPAN Multipath Header Type. 334 9. References 336 9.1. Normative References 338 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 339 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., 340 and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power 341 and Lossy Networks", RFC 6550, March 2012, 342 . 344 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 345 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 346 RFC 4944, September 2007, 347 . 349 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and 350 D. Barthel, "Routing Metrics Used for Path Calculation in 351 Low-Power and Lossy Networks", RFC 6551, March 2012, 352 . 354 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 355 Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, 356 March 2012, . 358 9.2. Informative References 360 [I-D.ietf-detnet-architecture] 361 Finn, N. and P. Thubert, "Deterministic Networking 362 Architecture", draft-ietf-detnet-architecture-04 (work in 363 progress), August 2017. 365 [I-D.ietf-detnet-problem-statement] 366 Finn, N. and P. Thubert, "Deterministic Networking Problem 367 Statement", draft-ietf-detnet-problem-statement-02 (work in 368 progress), September 2016. 370 Authors' Addresses 372 Chenggen Pu 373 Chongqing University of Posts and Telecommunications 374 2 Chongwen Road 375 Chongqing, 400065 376 China 378 Phone: (86)-23-6246-1061 379 Email: mentospcg@163.com 381 Yadong Wang 382 Chongqing University of Posts and Telecommunications 383 2 Chongwen Road 384 Chongqing, 400065 385 China 387 Phone: (86)-23-6246-1061 388 Email: 13618266302@163.com 390 Heng Wang 391 Chongqing University of Posts and Telecommunications 392 2 Chongwen Road 393 Chongqing, 400065 394 China 396 Phone: (86)-23-6248-7845 397 Email: wangheng@cqupt.edu.cn 399 Yi Yang 400 Chongqing University of Posts and Telecommunications 401 2 Chongwen Road 402 Chongqing, 400065 403 China 405 Phone: (86)-23-6246-1061 406 Email: 15023705316@163.com 408 Ping Wang 409 Chongqing University of Posts and Telecommunications 410 2 Chongwen Road 411 Chongqing, 400065 412 China 414 Phone: (86)-23-6246-1061 415 Email: wangping@cqupt.edu.cn