idnits 2.17.1 draft-do-roll-p2p-backup-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 18, 2013) is 3962 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ROLL D.S. Do 2 Internet Draft N.T. Dinh 3 Intended status: Standards Track Y. Kim 4 Expires: December 18 2013 Soongsil University 5 June 18, 2013 7 Backup Path for Point-to-Point Routes in Low Power and Lossy 8 Networks 9 draft-do-roll-p2p-backup-01 11 Abstract 13 In this draft, a backup path setup mechanism is proposed for the 14 P2P-RPL protocol in Low Power and Lossy Networks (LLNs). This 15 mechanism allows sensor nodes to send packets over the backup path 16 without rediscovering the p2p path in case of path failure, thus 17 improving the reliability of p2p transmission. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on December 18, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction ................................................ 2 60 2. Target Use Cases ............................................ 3 61 3. Terminology ................................................. 3 62 4. P2P backup path setup with Local RPLInstanceID in LLNs....... 4 63 5. P2P backup path setup with Global RPLInstanceID in LLNs...... 4 64 6. Message Format .............................................. 7 65 6.1. Backup Path Establishing Option.......................... 7 66 6.2. Backup Path Confirming Option............................ 8 67 7. Security Considerations...................................... 9 68 8. IANA Considerations ......................................... 9 69 9. Acknowledgments ............................................. 9 70 10. References ................................................. 9 71 10.1. Normative References...................................... 9 72 10.2. Informative References................................... 10 74 1. Introduction 76 Reliable routing is the general name for those mechanisms in which 77 data is transmitted from a node to another node with a highly 78 successful delivering ratio. Normally, reliable routing establishes 79 a reliable path from the source to the destination. Then, the data 80 packet is forwarded to the destination based on those paths. 81 However, links in WSNs maybe frequently broken due to scheduling or 82 sensor node failure. Therefore, data may not reach the destination. 83 Then, the source needs to reestablish the path to the destination to 84 send these packets. This increases costs and delays the transmission 85 process. However, nodes in WSNs have resource constraints in terms 86 of energy and memory. Thus, energy efficiency, reliability, and 87 delay are crucial problems. 89 Currently, the P2P-RPL routing protocol [1] in the ROLL working 90 group provides a standard protocol for communication between two 91 nodes in Low power and Lossy Networks. This protocol relies on the 92 RPL routing protocol [RFC6550]. First, the source acts as a sink and 93 builds its own directed acyclic graph (DAG) to discover the 94 destination. Then, the destination sends a unicast message back to 95 the source node to confirm the path from the source to the 96 destination. The current P2P-RPL routing protocol focuses on 97 building only one point-to-point path. However, in an LLN 98 environment, this path can be frequently broken at any time during 99 the transmission phase. In this case, the overhead to rebuild the 100 path from the beginning is very high. 102 This document describes an extension to the P2P-RPL routing protocol 103 on recovery after path failure. Nodes utilize the interactive path 104 as alternative to quickly recover from failure to send packets to 105 the destination instead of recreating the path. In particular, the 106 purpose of the P2P-RPL-BACKUP is to immediately repair the path 107 locally at the failed point to minimize cost and latency. The 108 interactive path was created for this purpose without high extra 109 overhead, which is composed of links including primary links and 110 backup links for an optimal recovery path. In addition, this 111 mechanism helps improve the performance of p2P-RPL routing in case 112 of failure. Primary links and interactive links are defined in the 113 terminology section. 115 2. Targeted Use Cases 117 This document aims at point-to-point communication in LLN scenarios 118 where reliability and delay constraints are not satisfied by P2P 119 routes, especially in high broken link scenarios, including in 120 industrial zone, home automation, and building automation. 122 One typical example is due to the changes in the climate, a sensor 123 to inform the cluster head of sensors in an area to change its 124 parameters related to living conditions. In these applications, 125 reliable transmission and delay are important. The message should be 126 sent as quickly as possible. Then, retransmission of messages should 127 be minimized. 129 3. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] 135 Besides the terminology from [1], this draft also uses the following 136 terms: 138 Source: The node that initiates route discovery. 140 Destination: The node at the end point of the discovery process. 142 Intermediate: The nodes between the Source and the Destination. 144 Primary path: The path is established between the source and the 145 destination based on P2P-RPL routing protocol. 147 Primary node: The nodes on the Primary path. 149 Primary link: The links on the Primary path. 151 Backup node: The nodes selected for backup forwarding in case of 152 failure on the Primary path. 154 Backup link: The links created between a primary node and a backup 155 node or between two backup nodes. 157 Backup path: The path created by backup nodes. 159 Interactive path: The path created between the primary link and 160 backup link for an optimal recovery path from the failure. 162 Forward direction: The direction from a primary node to a backup 163 node. 165 Backward direction: The direction from a backup node to a primary 166 node. 168 Hop-by-hop route: The route by which each node uses the routing 169 table to determine the next-hop. 171 4. P2P backup path setup with Local RPLInstanceID in LLNs 173 This section briefly describes the P2P-RPL-BACKUP process. 175 Our proposal is an extension of the P2P-RPL routing algorithm [1]. 176 As with the P2P-RPL routing protocol, the Source starts building its 177 own new DAG by using IPv6 link-local multicast DIO messages to 178 discover the destination. However, unlike P2P-RPL routing, which 179 only focuses on creating one path, the P2P-RPL-BACKUP tries to build 180 a recovery path in addition to the Primary path. The recovery path 181 is used in case of failure in the Primary path. The backup path can 182 be used as a recovery path to avoid rediscovering processes that may 183 result in high overhead and latency. 185 However, the failure may occur at any node or link on the Primary 186 path. Therefore, retransmission on the backup path is not an optimal 187 solution. P2P-RPL-BACKUP aims at repairing the path locally at the 188 failed point immediately to minimize cost and latency. The 189 interactive path is created for this purpose without high extra 190 overhead and is composed of links, such as the primary link and 191 backup link, for an optimal recovery path. 193 The interactive path has special characteristics. The Primary path 194 is responsible for transmitting packets from the Source to the 195 Destination. The other paths are used as backup paths in the event a 196 link is lost in the primary path. In this context, each node in the 197 primary path has only one backup node in the secondary path. In 198 addition, a node in the secondary path has connections with two 199 nodes in the primary path. Once a packet arrives at a node, it has 200 two options: It can be forwarded along the primary path or along the 201 secondary path. Naturally, by utilizing the backup link at each 202 node, the probability of a packet's successful transmission to the 203 Destination is increased. Moreover, this algorithm helps reduce data 204 packet transmission when the primary path is disrupted. Furthermore, 205 the number of nodes in the secondary path are estimated and limited 206 by the number of nodes in the primary path because each node in the 207 primary path has a backup node. 209 The Interactive-path-establishing process relies on the above 210 characteristics. After the destination discovery phase, each node 211 has its own position in the DAG of the Source by setting up its own 212 rank [RFC6206]. Next, the Destination sends a discovery reply 213 message back to its parent in the DAG of the Source to establish the 214 Primary node. Then, this process is repeated until the Primary path 215 is completely setup. The process of setting up the Interactive path 216 occurs simultaneously. This is also based on the Discovery Reply 217 message, which contains the Backup Path Establishing option and is 218 defined in the next section, and includes two processes-establishing 219 the connection between the Primary node and the Backup nodes and 220 establishing the connection between the backup nodes. For the first 221 process, the Destination sends its neighbors a Discovery Reply 222 message that contains the above options and the rank of the 223 Destination. If the rank of a neighbor is smaller than the rank 224 contained in the option, the neighbor continues forwarding the reply 225 message to its neighbor. Otherwise, this message is discarded. After 226 the second-packet-broadcasting process occurs in the Destination's 227 neighbor, if a node in the Primary path receives this message, based 228 on the rank contained in each message, the node will choose the node 229 with a greater than its rank, making it the smallest rank among the 230 satisfying ranks. If multiple nodes satisfy the above condition, one 231 of them is randomly chosen. For the second process, a DIO message 232 that contains the Backup Path Confirming option (which is defined in 233 the next section) is sent back to the chosen backup node. Then, this 234 process is repeats to choose the next backup node. The entire 235 process stops when it reaches the Source. 237 In the above process, the Source has to clarify the following 238 information: 240 o The IPv6 address of the Destination: This address could be a 241 unicast or multicast address. 243 o The forwarding mechanism: hop-by-hop. 245 In addition, one of the most important factors is the distance 246 between the Source and the Destination, which determines whether the 247 Destination should establish a path to the Source. If this distance 248 is too great, energy is wasted forming a path from the Source to the 249 Sink and from the Sink to the Destination. 251 After setting up the paths, except the interactive links, other 252 links are unnecessary, and nodes do not keep those connections. Then, 253 the DAG is released. 255 Finally, the data packets are forwarded along the Interactive path 256 and adhere to the following rule: The Source sends data along the 257 Primary path. If there is a broken link in this path, the 258 intermediate node will redirect the data to the node in the 259 Interactive path. At this node, the data are forwarded to the next 260 hop in the Primary path if the link is available. Otherwise, the 261 data are forwarded to the next-hop in the Interactive path. 263 5. P2P backup path setup with Global RPLInstanceID in LLNs 265 This part provides a method of guaranteeing the path for 266 transmitting data packets over multiple domains. This path includes 267 three sub-paths. The first one is from the Source to the Sink which 268 has the same RPLInstanceID with the Source. The second is between 269 the above Sink and the Sink which has the same RPLInstanceID with 270 the Destination. And the third is from the latter Sink to the 271 Destination. Specifically, there are two sub-paths, the first and 272 the third, are protected with high reliability. The second must 273 establish the tunnel between them. However, it is out of the scope 274 of this draft. 276 The process of establishing above path is similar to the process 277 which is presented in the section 4. However, the RPLInstanceID of 278 the Destination and the Source MUST be supplemented. 280 Therefore, in order to meet the above functional requirements, some 281 parameters should be added in the header of the packet. 283 o Flag G: Must be set to one if RPLInstaceID of the Destination and 284 the Source are different 286 o Additional header length 288 o RPLInstanceID Source: the RPLInstanceID of the Source 290 o RPLInstanceID Destination: the RPLInstanceID of the Destination 292 6. Message Format 294 6.1. Backup Path Establishing Option 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type =10 |D|H| R | Reserved | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 | Target Address | 303 | | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 1: Format of the Backup Path Establishing Option 309 The Backup path Establishing Option is an alternative to the 310 Discovery Reply Object in establishing the path between the backup 311 and primary nodes. 313 o Option Type = 0x10 (to be confirmed by IANA). 315 o Target Address: The IPv6 address of the target node. 317 o D: A 1-bit field that indicates the direction of the desired 318 routes. 320 D = 0x0: Forward from the primary node to the backup node. 322 D = 0x1: Backward from the backup node to the primary node. 324 o H: Limit the scale of sending message within one hop 326 o R: Rank of the sending node 328 6.2. Backup Path Confirming Option 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type=11 |D|H| Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 | Destination Address | 337 | | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 2. Format of the Backup Path Confirming Option 342 o Option Type = 0x11 (to be confirmed by IANA). 344 o Target Address: The IPv6 address of the selected node. 346 o D: A 1-bit field that indicates the direction of the desired 347 routes: 349 D = 0x0: Forward from the primary node to the backup node. 351 D = 0x1: Backward from the backup node to the primary node. 353 o H: Limit the scale of sending message within one hop 355 7. Security Considerations 357 8. IANA Considerations 359 9. Acknowledgments 361 10. References 363 10.1. Normative References 365 [RFC6550] Winter, T., Thubert., P, and R. Team, "RPL: IPv6 routing 366 protocol for low power and lossy networks, "RFC 6550, March 367 2012. 369 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 370 "The Trickle Algorithm", RFC 6206, March 2011. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 10.2. Informative References 377 [1] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 378 Martocci, "Reactive Discovery of Point-to-Point Routes in Low 379 Power and Lossy Networks, "draft-ietf-roll-p2p-rpl-15 (work in 380 progress), October 2012. 382 Authors' Addresses 384 Dinh-Sy Do 385 Soongsil University 386 Huyngnam Enginerring Building 424, Soongsil Univ, Sangdo-do, 387 Dongjak-Gu, Seoul, Korea 156-743 389 Phone: 00828200841 390 Email: sydodinh@dcn.ssu.ac.kr 392 Ngoc-Thanh Dinh 393 Soongsil University 394 Huyngnam Enginerring Building 424, Soongsil Univ, Sangdo-do, 395 Dongjak-Gu, Seoul, Korea 156-743 397 Phone: 00828200841 398 Email: ngocthanhdinh@dcn.ssu.ac.kr 400 Younghan Kim 401 Soongsil University 402 Huyngnam Enginerring Building 424, Soongsil Univ, Sangdo-do, 403 Dongjak-Gu, Seoul, Korea 156-743 405 Phone: 00828200841 406 Email: younghak@ssu.ac.kr