idnits 2.17.1 draft-pu-6lo-multipath-transmission-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 -- The document date (March 8, 2017) is 2606 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-00 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-problem-statement-01 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 9, 2017 Y. Yang 5 P. Wang 6 Chongqing University of 7 Posts and Telecommunications 8 March 8, 2017 10 Multipath Transmission for 6LoWPAN Networks 11 draft-pu-6lo-multipath-transmission-00 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 9, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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. Multipath Distribution ....................................... 4 64 5. Packet Replication and Elimination ........................... 6 65 6. Security Considerations ...................................... 7 66 7. IANA Considerations .......................................... 7 67 8. References ................................................... 7 68 8.1. Normative References .................................... 7 69 8.2. Informative References .................................. 7 70 Authors' Addresses .............................................. 9 72 1. Introduction 74 6LoWPAN has high popularity and applicability, and has more address 75 space that can meet needs of the deployment of large-scale and high- 76 density low-speed wireless personal area network devices. However, 77 due to the low processing power, limited energy and poor 78 communication environment in 6LoWPAN, packets are prone to be lost 79 during transmission, resulting in transmission failure. In order to 80 increase the communication reliability and improve the transmission 81 performance of packets, it is very important to introduce multipath 82 packet transmission technology in 6LoWPAN. 83 RPL, as a routing protocol standardized by IETF, is an efficient 84 distance vector protocol for wireless sensor networks, which has 85 designed a series of new mechanisms [RFC6550], and is widely used in 86 6LoWPAN. Aiming at the explicit demand of 6LoWPAN using multipath 87 packet transmission, this document proposes a multipath transmission 88 method based on RPL, which improves the success rate of packets 89 transmission in uplink networks and further improves the network 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: Headers of different types 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 the 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 achieve the multipath transmission. At the adaptation layer, the 124 multipath transmission entity is achieved by designing a multipath 125 header. The encapsulation of multipath packets and the multipath 126 packets transmission can be implemented by using above methods. 128 +---------------------------------------------------+ 129 | COAP Application Layer XMPP | 130 |---------------------------------------------------| 131 | UDP Transport Layer | 132 |---------------------------------------------------| 133 | ----- --------------| 134 | |RPL| IP Layer | Multipath|| 135 | ----- |Transmission|| 136 | --------------| 137 |---------------------------------------------------| 138 | Header Adaptation Layer | Multipath|| 139 | Compression |Transport Entity|| 140 | ------------------| 141 |---------------------------------------------------| 142 | CSMA/CA Mac Layer | 143 |---------------------------------------------------| 144 | Channel Detection Physical Layer | 145 +---------------------------------------------------+ 146 Figure 2: 6LoWPAN Protocol Stack Architecture 148 Before the source node sending a message, it is necessary to 149 determine the number of paths P according to the reliability 150 requirements. Then we need to assign one or more paths for each 151 parent node at the IP layer through the rank value. The rank value 152 is calculated according to the residual energy value and the hop 153 value to the sink node of the source node [RFC6551] [RFC6552]. The 154 number of paths is encapsulated into the multipath header of the 155 message at the adaptation layer before sending the message to the 156 parent node corresponding to the rank value. Each intermediate 157 routing node forwards the message according to the above method 158 until it arrives at the sink node. 160 4. Multipath Distribution 162 If the required number of paths P is greater than the total number 163 of parent nodes N in the collection of RPL parent nodes, multiple 164 paths are assigned to each parent node according to the size 165 relation among the rank values of all parent nodes. The following 166 formula is used. 168 Pm = round (P/Rm/R) where R=1/R + 1/R +...+ 1/Rn 170 Here, round() presents the rounding function, rounding for the 171 calculation result of (P/Rm/R). P is the total number of paths. Pm 172 is the number of paths allocated for parent node m. Rm is the Rank 173 value corresponding to the parent node m (m=1,2,...,n). The above 174 situation is shown as Figure 3. 176 +---------------------------------------------------+ 177 | rank2=500 P2=1 | 178 | +------------>(R1)----> ..... | 179 | | | 180 | | | 181 | | /---->(R3)---->(R4)----> .....\ | 182 | |rank1=100 P1=5/ \ | 183 |(S) ---------->(R2).....--->(R5)--->(R6)---> ...(D)| 184 | |P=8 \ / | 185 | | \---->(R7)---->(R8)----> ...../ | 186 | | | 187 | |rank3=200 P3=2 /----> ..... | 188 | +---------------->(R9) | 189 | \----> ..... | 190 +---------------------------------------------------+ 191 Figure 3: The Transmission Process of (P>N) 193 If the number of paths P is less than or equal to the total number 194 of parent nodes, P rank values are selected according to the rise 195 order of rank values, and one path is assigned to the parent node 196 corresponding to each rank value, as shown in Figure 4. 198 +---------------------------------------------------+ 199 | rank2=500 P2=1 | 200 | +---------------->(R1)---->(R2)---->(R3)......... | 201 | | | | 202 | | rank1=100 P1=1 | | 203 | | /-------------->(R4)---->(R5)---->(R6)......\ | | 204 | |/ \| | 205 |(S)P=3 (D)| 206 | .\rank3=200 P3=1 /. | 207 | . \-------------->(R7)---->(R8)---->(R9)....../ . | 208 | . . | 209 | . rank4=600 P4=0 . | 210 | ..................(10)....(R11)....(R12)......... | 211 | | 212 +---------------------------------------------------+ 213 Figure 4: The Transmission Process of (P<=N) 215 5. Packet Replication and Elimination 217 The process of packet multipath transmission includes the process of 218 packet replication and elimination. A detailed description is given 219 as the following five steps. 221 1) When the multipath transport entity of adaptation layer 222 receives the packet from the upper layer of the protocol stack, it 223 determines the total number of paths P to transmit the packet 224 according to the reliability requirements of the packet. When P is 225 less than or equal to 1, indicating that the packet does not need to 226 use multipath transmission, the packet can be forwarded directly. 228 2) When the total number of paths P is larger than 1, the 229 multipath packet allocation method is used to allocate the number of 230 the replicated packets PathCount that need to be forwarded by each 231 parent node in the collection of RPL parent nodes [I-D.ietf-detnet- 232 architecture] [I-D.ietf-detnet-problem-statement]. 234 3) For the parent node that PathCount is greater than or equal to 235 1, the multipath transport entity replicates the packet and adds the 236 multipath header at the adaptation layer, and then sends the packet 237 to the parent node. In this case, the multipath packet sequence 238 number SequenceNumber of the multipath header in all replicated 239 packets must be consistent and SequenceNumber can be accumulated 240 when the next new packet is sent. The path number field is filled 241 with the corresponding number of copies PathCount. For the parent 242 node whose number of copies PathCount is less than 1, the source 243 node does not send the packet. 245 4) After the intermediate routing node receives the packet 246 containing the multipath header, it judges whether the number of 247 paths PathCount in the multipath header is equal to 1. If PathCount 248 is equal to 1, the intermediate node sends the packet directly with 249 the value of each field in the multipath header unchanged. If 250 PathCount is greater than 1, the node has to replicate PathCount 251 copies of the packet and distributes them to multiple paths. 252 Repeating step 2 and 3, and in step 2, P is equal to PathCount. In 253 step 3, the new multipath header is not added, the sequence number 254 of the packet is unchanged, and the path number field is filled with 255 the new corresponding number of copies PathCount. 257 5) When a destination node receives a packet containing the 258 multipath header, it can distinguish whether the packet has been 259 received according to the multipath packet sequence number in the 260 multipath header and the source address. If the destination node 261 receives the packet before, the node can discard the packet 263 [I-D.ietf-detnet-architecture] [I-D.ietf-detnet-problem-statement]. 264 Otherwise, the node transmits the packet to its upper layer protocol. 266 6. Security Considerations 268 This document does not add any new security considerations beyond 269 what the referenced technologies already have. 271 7. IANA Considerations 273 This document creates an IANA registry for 6LoWPAN Multipath Header 274 Type, and assigns the following dispatch type values: 276 11101000: for 6LoWPAN Multipath Header Type. 278 8. References 280 8.1. Normative References 282 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 283 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., 284 and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power 285 and Lossy Networks", RFC 6550, March 2012, 286 . 288 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 289 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 290 RFC 4944, September 2007, 291 . 293 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and 294 D. Barthel, "Routing Metrics Used for Path Calculation in 295 Low-Power and Lossy Networks", RFC 6551, March 2012, 296 . 298 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 299 Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, 300 March 2012, . 302 8.2. Informative References 304 [I-D.ietf-detnet-architecture] 305 Finn, N. and P. Thubert, "Deterministic Networking 306 Architecture", draft-ietf-detnet-architecture-00 (work in 307 progress), September 2016. 309 [I-D.ietf-detnet-problem-statement] 310 Finn, N. and P. Thubert, "Deterministic Networking Problem 311 Statement", draft-ietf-detnet-problem-statement-01 (work in 312 progress), September 2016. 314 Authors' Addresses 316 Chenggen Pu 317 Chongqing University of Posts and Telecommunications 318 2 Chongwen Road 319 Chongqing, 400065 320 China 322 Phone: (86)-23-6246-1061 323 Email: mentospcg@163.com 325 Yadong Wang 326 Chongqing University of Posts and Telecommunications 327 2 Chongwen Road 328 Chongqing, 400065 329 China 331 Phone: (86)-23-6246-1061 332 Email: 13618266302@163.com 334 Heng Wang 335 Chongqing University of Posts and Telecommunications 336 2 Chongwen Road 337 Chongqing, 400065 338 China 340 Phone: (86)-23-6248-7845 341 Email: wangheng@cqupt.edu.cn 343 Yi Yang 344 Chongqing University of Posts and Telecommunications 345 2 Chongwen Road 346 Chongqing, 400065 347 China 349 Phone: (86)-23-6246-1061 350 Email: 15023705316@163.com 352 Ping Wang 353 Chongqing University of Posts and Telecommunications 354 2 Chongwen Road 355 Chongqing, 400065 356 China 358 Phone: (86)-23-6246-1061 359 Email: wangping@cqupt.edu.cn