idnits 2.17.1 draft-pu-6lo-multipath-transmission-01.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 7, 2017) is 2423 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-03 == 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: March 11, 2018 Y. Yang 5 P. Wang 6 Chongqing University of 7 Posts and Telecommunications 8 September 7, 2017 10 Multipath Transmission for 6LoWPAN Networks 11 draft-pu-6lo-multipath-transmission-01 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 March 11, 2018. 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 ................................. 8 70 Authors' Addresses ............................................. 9 72 1. Introduction 74 6LoWPAN has high popularity and applicability, and has more address 75 space that can realize the deployment of large-scale and high- 76 density wireless personal area network devices. However, due to the 77 low processing power, limited energy and poor communication 78 environment in 6LoWPAN, packets are prone to be lost during 79 transmission, which results in transmission failure. In order to 80 increase the communication reliability and improve the transmission 81 performance, it is significant to introduce multipath packet 82 transmission technology in 6LoWPAN. It is well known that RPL as a 83 routing protocol standardized by IETF, is an efficient distance 84 vector protocol for wireless sensor networks, which has designed a 85 series of new mechanisms [RFC6550], and is widely used in 6LoWPAN. 86 Aiming at the explicit demand for 6LoWPAN adopting multipath packet 87 transmission, this document proposes a multipath transmission method 88 based on RPL, which improves the success rate of packets 89 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: 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 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| IP Layer | Multipath|| 136 | ----- |Transmission|| 137 | --------------| 138 |---------------------------------------------------| 139 | ------------------| 140 | Header Adaptation Layer | Multipath|| 141 | 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. 158 Moreover, each intermediate routing node forwards the message 159 according to the above method until it reaches the sink node. 161 4. Multipath Distribution 163 If the required number of paths P is greater than the total number 164 of parent nodes N in the collection of RPL parent nodes, multiple 165 paths are assigned to each parent node according to the size 166 relation among the rank values of all parent nodes. The following 167 formula is used. 169 Pm = round (P/Rm/R) where R = 1/R1 + 1/R2 +...+ 1/Rn 171 Here, round() presents the rounding function, rounding for the 172 calculation result of (P/Rm/R). P is the total number of paths. Pm 173 shows the number of paths allocated for parent node m. Rm represents 174 the Rank value corresponding to the parent node m (m=1,2,...,n). The 175 above situation is shown as Figure 3. 177 +---------------------------------------------------+ 178 | rank2=500 P2=1 | 179 | +------------>(R1)----> ..... | 180 | | | 181 | | | 182 | | /---->(R3)---->(R4)----> .....\ | 183 | |rank1=100 P1=5/ \ | 184 |(S) ---------->(R2).....--->(R5)--->(R6)---> ...(D)| 185 | |P=8 \ / | 186 | | \---->(R7)---->(R8)----> ...../ | 187 | | | 188 | |rank3=200 P3=2 /----> ..... | 189 | +---------------->(R9) | 190 | \----> ..... | 191 +---------------------------------------------------+ 192 Figure 3: The Transmission Process of P>N 194 If the number of paths P is less than or equal to the total number 195 of parent nodes, P rank values are selected according to the rise 196 order of rank values, and one path is assigned to the parent node 197 corresponding to each rank value, as shown in Figure 4. 199 +---------------------------------------------------+ 200 | rank2=500 P2=1 | 201 | +---------------->(R1)---->(R2)---->(R3)......... | 202 | | | | 203 | | rank1=100 P1=1 | | 204 | | /-------------->(R4)---->(R5)---->(R6)......\ | | 205 | |/ \| | 206 |(S)P=3 (D)| 207 | .\rank3=200 P3=1 /. | 208 | . \-------------->(R7)---->(R8)---->(R9)....../ . | 209 | . . | 210 | . rank4=600 P4=0 . | 211 | ..................(10)....(R11)....(R12)......... | 212 | | 213 +---------------------------------------------------+ 214 Figure 4: The Transmission Process of P<=N 216 5. Packet Replication and Elimination 218 The process of packet multipath transmission also includes packet 219 replication and elimination. A detailed description is given as 220 following five steps. 222 1) When the multipath transport entity of the adaptation layer 223 receives the packet from the upper layer of the protocol stack, it 224 first determines the total number of paths P to transmit the packet 225 according to the reliability requirements of the packet. When P is 226 less than or equal to 1, indicating that the packet does not need to 227 use multipath transmission, then the packet can be forwarded 228 directly. 230 2) When the total number of paths P is larger than 1, the multipath 231 packet allocation method is used to allocate the number of the 232 replicated packets PathCount that needs to be forwarded by each 233 parent node in the collection of RPL parent nodes [I-D.ietf-detnet- 234 architecture], [I-D.ietf-detnet-problem-statement]. 236 3) For the parent node that PathCount is greater than or equal to 237 1, the multipath transport entity replicates the packet and adds the 238 multipath header at the adaptation layer, and then sends the packet 239 to the parent node. In this case, the packet sequence number 240 SequenceNumber of the multipath header in all replicated packets 241 must be consistent and it can be accumulated when the next new 242 packet is sent. The path number field is filled with the 243 corresponding number of copies PathCount. For the parent node whose 244 number of copies PathCount is less than 1, the source node does not 245 send the packet. 247 4) After the intermediate routing node receives the packet 248 containing the multipath header, it judges whether the number of 249 paths PathCount in the multipath header is equal to 1. If PathCount 250 is equal to 1, the intermediate node sends the packet directly with 251 the value of each field in the multipath header constant. If 252 PathCount is greater than 1, the node has to replicate PathCount 253 copies of the packet and distributes them to multiple paths. 254 Repeating step 2 and 3, and in step 2, P is equal to PathCount. In 255 step 3, the new multipath header is not added, the SequenceNumber of 256 the packet is unchanged, and the path number field is filled with 257 the new corresponding number of copies. 259 5) When a destination node receives a packet containing the 260 multipath header, it can distinguish whether the packet has been 261 received according to the source address and the packet sequence 262 number in the multipath header. If the destination node has not 263 received the packet before, the node forwards the packet to its 264 upper layer protocol directly. Otherwise, the node discards the 265 packet [I-D.ietf-detnet-architecture], [I-D.ietf-detnet-problem- 266 statement]. 268 6. Security Considerations 270 This document does not add any new security considerations beyond 271 what the referenced technologies already have. 273 7. IANA Considerations 275 This document creates an IANA registry for 6LoWPAN Multipath Header 276 Type, and assigns the following dispatch type values: 278 11101000: for 6LoWPAN Multipath Header Type. 280 8. References 282 8.1. Normative References 284 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 285 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., 286 and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power 287 and Lossy Networks", RFC 6550, March 2012, 288 . 290 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 291 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 292 RFC 4944, September 2007, 293 . 295 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and 296 D. Barthel, "Routing Metrics Used for Path Calculation in 297 Low-Power and Lossy Networks", RFC 6551, March 2012, 298 . 300 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 301 Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, 302 March 2012, . 304 8.2. Informative References 306 [I-D.ietf-detnet-architecture] 307 Finn, N. and P. Thubert, "Deterministic Networking 308 Architecture", draft-ietf-detnet-architecture-03 (work in 309 progress), August 2017. 311 [I-D.ietf-detnet-problem-statement] 312 Finn, N. and P. Thubert, "Deterministic Networking Problem 313 Statement", draft-ietf-detnet-problem-statement-01 (work in 314 progress), September 2016. 316 Authors' Addresses 318 Chenggen Pu 319 Chongqing University of Posts and Telecommunications 320 2 Chongwen Road 321 Chongqing, 400065 322 China 324 Phone: (86)-23-6246-1061 325 Email: mentospcg@163.com 327 Yadong Wang 328 Chongqing University of Posts and Telecommunications 329 2 Chongwen Road 330 Chongqing, 400065 331 China 333 Phone: (86)-23-6246-1061 334 Email: 13618266302@163.com 336 Heng Wang 337 Chongqing University of Posts and Telecommunications 338 2 Chongwen Road 339 Chongqing, 400065 340 China 342 Phone: (86)-23-6248-7845 343 Email: wangheng@cqupt.edu.cn 345 Yi Yang 346 Chongqing University of Posts and Telecommunications 347 2 Chongwen Road 348 Chongqing, 400065 349 China 351 Phone: (86)-23-6246-1061 352 Email: 15023705316@163.com 354 Ping Wang 355 Chongqing University of Posts and Telecommunications 356 2 Chongwen Road 357 Chongqing, 400065 358 China 360 Phone: (86)-23-6246-1061 361 Email: wangping@cqupt.edu.cn