idnits 2.17.1 draft-wang-6lowpan-scheduling-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 145 characters in excess of 72. ** The abstract seems to contain references ([RFC4944]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 100 has weird spacing: '...ocation mecha...' == 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 (April 20, 2012) is 4379 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) == Missing Reference: 'RFC 4944' is mentioned on line 542, but not defined == Missing Reference: 'RFC 6282' is mentioned on line 220, but not defined == Missing Reference: 'E' is mentioned on line 388, but not defined == Missing Reference: 'F' is mentioned on line 388, but not defined == Missing Reference: 'G' is mentioned on line 388, but not defined == Missing Reference: 'H' is mentioned on line 391, but not defined == Missing Reference: 'HART' is mentioned on line 601, but not defined == Missing Reference: 'S' is mentioned on line 611, but not defined == Missing Reference: 'IEEE802.15.4' is mentioned on line 604, but not defined == Missing Reference: 'WIA-PA' is mentioned on line 611, but not defined == Unused Reference: 'RFC2234' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-indus-routing-reqs' is defined on line 594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 4919 Summary: 4 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 6LoWPAN Working Group H. Wang 2 Internet Draft P. Wang 3 Interned status: Standards Track Chongqing University of 4 Expires: October 21, 2012 Posts and Telecommunications 5 C. Zhou 6 Cisco Systems 7 April 20, 2012 9 Transmission Scheduling of IPv6 Packets over IEEE 802.15.4 Networks-- - 10 Extension for Industrial Application Space 11 draft-wang-6lowpan-scheduling-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on mouth date year. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 These years, wireless technologies, including the application of 54 6LoWPAN protocol, are more and more been applied in industrial 55 environment to improve productivity and safety of the plants. In 56 spite of the fact that [RFC4944] has introduced the methods of 57 transmitting IPv6 packets over IEEE 802.15.4 networks, industrial 58 automation field, either process automation or factory automation, 59 has its special characteristics and requirements. If 6LoWPAN is been 60 used in industrial environment, some change SHOULD be made in the 61 adaption layer. This document defines a Scheduling Header, to make 62 the adaption layer meet the requirements of industrial scheduling for 63 transmission of IPv6 packets over IEEE 802.15.4 networks. 64 Additionally, this document also provides an application example of 65 Scheduling Header. 67 Table of Contents 69 1. Introduction ................................................ 2 70 1.1. Requirements Notation .................................. 4 71 1.2. Terms Uesd ............................................. 4 72 2. Scheduling Header ........................................... 5 73 2.1. Scheduling dispatch and IPv6 header stack .............. 5 74 2.2. Scheduling Header ...................................... 6 75 3. An example using Scheduling Header .......................... 7 76 3.1. Route Discovery......................................... 7 77 3.2. Route Maintenance ..................................... 12 78 4. IANA Considerations ........................................ 12 79 5. Security Considerations .................................... 12 80 6. Conclusions ................................................ 13 81 7. References ................................................. 13 82 7.1. Normative References .................................. 13 83 7.2. Informative References ................................ 13 84 7.3. External Informative References ....................... 13 85 8. Acknowledgments ............................................ 14 87 1. Introduction 89 Wireless technology has been demonstrated as an effective option for 90 industrial applications. For convenient and fast deployment in a 91 global world, it has attracted huge attention to introduce IPv6 92 technology to wireless industrial networks. But in the industrial 93 environment, especially the environments (eg. a coal mine) with high 94 risk and low bandwidth, the resources are too limited. Which MUST be 95 scheduled properly to ensure every significant thing be done in its 96 specific time and channel and to ensure the safety and reliability. 97 It is worth mentioning that the MAC layers of some industrial 98 standards, [ISA100.11a]/[Wireless Hart]/[WIA-PA] standards, schedule 99 the slot time and channel resources of network with TDMA and ACA 100 Adaptive Channel Allocation mechanism. Through the investigation 101 of the data features and the application class of wireless 102 industrial applications, a conclusion can be draw that the important 103 requirements for wireless industrial networks are: 105 * Determinism 107 * Reliability 109 * Real time 111 * Security 113 * Synchronization 115 However, the adaption layer of 6LoWPAN defined in RFC 4944 is mainly 116 based on contention access and best effort delivery. It does not 117 make special optimization for industrial applications. To meet above 118 requirements, it is recommended to improve the design of the 119 adaption layer for transmission of IPv6 packets. 121 ISA100.11a adopts 6LoWPAN as its network layer, but the function of 122 6LoWPAN in is limited. For example, the operations of scheduling and 123 routing in the wireless subnet are performed by upper data link 124 layer of ISA100.11a rather than network layer. Moreover, ISA100.11a 125 is an integrated solution for industrial control net, including 126 system manager, gateway, provisioning and a series of new protocols 127 for every layer except physical layer. 6LoWPAN is just a part of 128 ISA100.11a system. For simple or lightweight industrial applications 129 which want to use IPv6 technology, the ISA100.11a has too much 130 overhead to deploy. Thus, it is attractive to add direct support 131 mechanism for industrial applications in 6LoWPAN. Industrial users 132 will benefit from more choices for different kinds of applications. 134 Consequently, it's hoped that 6LoWPAN supports the schedule 135 mechanism, and to be more suitable for industrial application. In 136 this case, the MAC layer is based on slot time, while the upper 137 layer, called the adaption layer, is based on non-slot. Therefore, 138 it is necessary to improve the frame format of the adaptation layer, 139 to make it support scheduling operations. 141 As a result, this document improves the frame format of the 142 adaptation and defines a scheduling header. In addition, this 143 document also introduces an application example of the Scheduling 144 Header. 146 1.1. Requirements Notation 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119] 152 1.2. Terms Uesd 154 MAC: Medium Access Control 156 Industrial Wireless Standard: At present, there are three main 157 industrial wireless standards, ISA100.11a, WirelessHART, and WIA-PA. 159 ISA: ''International Society of Automation''. ISA is an ANSI 160 accredited standards-making society. ISA100 is an ISA committee 161 whose charter includes defining a family of standards for industrial 162 automation. [ISA100.11a] is a working group within ISA100 that is 163 working on a standard for monitoring and non-critical process 164 control applications. 166 HART: ''Highway Addressable Remote Transducer'', a group of 167 specifications for industrial process and control devices 168 administered by the HART Foundation. The specifications include the 169 additions for Wireless HART. 171 WIA-PA: ''Wireless Networks for Industrial Automation-Process 172 Automation'', a Chinese industrial wireless specification, is passed 173 by 96% of IEC(International Electrotechnical Commission) members, 174 and formally released as IEC/PAS 62601 standard document. 176 CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance 178 TDMA: Time Division Multiple Address 180 GTS: Guaranteed Time Slot 182 Safety: It means the system's safety of industrial environment, 183 including the safety of devices and human safety. 185 Security: It means the specific security mechanism or security 186 algorithm. 188 Scheduling time: It means the time a node must to wait between the 189 time it wanted to send data or received data and the moment it send 190 data to a special node. When the MAC layer schedules the slot time 191 and channel resources of network with TDMA mechanism, every node get 192 send slots and receive slots. In this case if node A wants to send 193 data to node B, it have to send data at its send slot, which is also 194 the receive slot of node B. The time from the time A wanted to send 195 data to the slot above mentioned is the scheduling time from node A 196 to node B. It is noteworthy that the scheduling time from A to B is 197 usually different from the scheduling time from B to A. 199 Determinism: It is usually meant that access to the control 200 network by a node may be delayed by at most some time t, where t is 201 known. In industrial wireless network, it also means that data is 202 sent and received within the stipulated time. 204 Neighbor domain: It means the neighbors a node could reach to. 205 Node could use neighbor discovery to find its neighbors and store 206 the neighbors' addresses in its neighbor table. 208 2. Scheduling Header 210 In this section, we define the scheduling dispatch value and the 211 field of Scheduling Header, used for supporting scheduling 212 operations. 214 2.1. Scheduling dispatch and IPv6 header stack 216 The definition of LoWPAN headers, other than mesh addressing and 217 fragmentation, consists of the dispatch value, and the definition of 218 the header fields that follow. Note that [RFC 4944] has defined some 219 values for some headers. In order to avoid any conflicts with the 220 existing standard documents, including [RFC 4944] and [RFC 6282], we 221 make full use of the reserved symbols of dispatch. Here, we set the 222 value of Scheduling dispatch is 01 000011. The Scheduling dispatch 223 and the Scheduling Header are shown here: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |0 1|0 0 0 0 1 1| Scheduling Header 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 1 Scheduling dispatch and Scheduling Header 233 The dispatch value may be treated as unstructured namespace. Only a 234 few symbols have been used to represent current LoWPAN functionality 235 according to [RFC 4944]. We can use the non-defined values to encode 236 additional functionality. 238 According to RFC 4944, all LoWPAN encapsulated datagrams transported 239 over IEEE 802.15.4 are prefixed by an encapsulated header stack. 240 Whereas in an IPv6 header stack, the Scheduling dispatch and the 241 Scheduling Header follow the Mesh Header and the next are other 242 headers, or options, finally payload. An Ipv6 header stack 243 containing Scheduling Header is shown as figure 2. 245 +---------+------------+--------------------+------------------+-------------+--------+ 246 |Mesh Type| Mesh Header| scheduling dispatch| Scheduling Header| other header| payload| 247 +---------+------------+--------------------+------------------+-------------+--------+ 249 Figure 2 An Ipv6 header stack containing Scheduling Header 251 Here, the other headers contain IPv6 header or other compressed IPv6 252 headers, and other types of header. 254 2.2. Scheduling Header 256 The Scheduling Header is shown here: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Sequence ID | Scheduling ID | Scheduling Time Limit | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 3 Scheduling Header 266 Field definitions are as follows: 268 Sequence ID: This 8-bit field is a local counter maintained 269 separately by each node and SHALL be incremented by the originator 270 whenever it sends a datagram with a Scheduling Header. This field is 271 used for follow-up maintenance, for example it could be used to tell 272 new datagrams from old datagrams. 274 Scheduling ID: This 8-bit field is used for identifying paths or 275 other scheduling parameter, which SHALL meet the industrial 276 requirements mentioned in the above section of Introduction, 277 especially the requirements of determinism. During the transmission 278 of the datagram, the Scheduling ID could show the information of 279 propagation path. 281 Scheduling Time Limit: This 16-bit field is used mainly to identify 282 the maximum scheduling time a packet allowed to be sent. It is the 283 key field to ensure the requirement of determinism, and in units of 284 milliseconds. This field can contain values up to 65535. 285 Additionally, it is an accumulated metric, an aggregation of 286 scheduling time value of every node along the path. Especially, when 287 a datagram with the requirement of determinism is sent for the first 288 time, this field is necessary for it to choose a satisfying path. 290 It is worth noting that the above definition of the Scheduling 291 Header is originally envisaged. With the subsequent increase in 292 scheduling applications, it MAY be further modified. Meanwhile, the 293 definition of the fields SHOULD be applied flexibly, according to 294 actual needs. 296 3. An example using Scheduling Header 298 Scheduling Header defined aims to support scheduling operation, and 299 to meet the industrial application requirements of determinism. 300 According to the initial consideration, the Scheduling Time Limit is 301 the key field to ensure determinism, which is used mainly to 302 identify the maximum scheduling time a packet allowed along the 303 transmission path. It is also to say that a datagram must be 304 transmitted from source node to destination node with the given 305 Scheduling Time Limit. So, we can see it as an accumulated routing 306 metric. Along this train of thought, route discovery MAY be an 307 obvious application of Scheduling Header defined above. 309 The aim of this section is simply to provide an example of 310 Scheduling Header application, using it in route discovery. Needless 311 to say that the MAC layer SHOULD based on TDMA and ACA mechanism, 312 which schedules the slot time and channel resources of network. 314 3.1. Route Discovery 316 The way of route discovery in this section is an on-demand algorithm, 317 that is, it determines a route to some destination only when 318 somebody wants to send packet to this destination within a 319 Scheduling Time Limit. The Scheduling Time Limit is set by users. 320 The route discovery process is similar to AODV (Ad hoc On-demand 321 Distance Vector) routing algorithm. However, the broadcast slots in 322 the deterministic scheduling mechanism are usually for organizing 323 network and time synchronization, using broadcast slots in route 324 discovery MAY effect the functional aspects of whole network. 325 Meanwhile, the route discovery for datagram is on-demand and 326 optional. So, it usually uses the non-broadcast slot for route 327 discovery. One of the solutions is that node use a group of unicast 328 messages to realize the broadcast effectiveness. 330 In order to describe route discovery process in detail, we make 331 following assumptions: 333 o The MAC layer is based on TDMA, if node A could send packet to 334 node B in a slot, then node B could send packet to node A in a 335 slot too. 337 o Before the route discovery process, the scheduling process is 338 over, and every node knows its send slot and scheduling time to a 339 special node. 341 o The mesh network can be described by a graph of the nodes 342 (routers + end devices). Two nodes are connected (i.e., have an 343 arc between them in the graph) if they are in each other's 344 neighbor domain. 346 To describe the algorithm, consider the mesh network of figure 4, in 347 which a process on node A wants to send a packet to node H. This 348 algorithm maintains some tables at each node, including: 350 o Scheduling Path History Table, which is maintained by source node, 351 stores information about that destination, including the Path ID, 352 the destination address, as well as the Scheduling Time Limit. 354 o Neighbor Table, which is got from the neighbor discovery process 355 before scheduling process, stores the address information of the 356 node's neighbors. 358 o Route Table, which is maintained by routers, stores information 359 about that destination, including the Path ID, the destination 360 address, as well as the next hop address. 362 o Local History Table, which is maintained by routers, stores the 363 tuple (Source address, Request ID, Destination address) for 364 determining duplicate packet. 366 o Reverse Route Table, which is maintained by every node, stores 367 the reverse route information. This information used to construct 368 the reverse route so the reply packet can get back to the source 369 later. Meanwhile, a timer is also started for the newly-made 370 reverse route entry. If it expires, the entry is deleted. 372 According to the user's requirements, A wants to send data with 373 Scheduling Header to H. Suppose that A looks in its Scheduling Path 374 History table and does not find an entry for H to ensure the 375 requirements of Scheduling Time Limit. It now has to discover a path 376 to H, which could meet the constraints. This property of discovering 377 paths only when they are needed is what makes this algorithm ''on 378 demand.'' 380 +-------------------------------------------------------------+ 381 | +---------------+ +---------------+ +---------------+ | 382 | | (A) | | (A) | | (A) | | 383 | | / \ | | / \ | | / \ | | 384 | | / \ | | / \ | | / \ | | 385 | | [B]---[C] | | (B)---(C) | | (B)---(C) | | 386 | | / / \ | | / / \ | | / / \ | | 387 | | / / \ | | / / \ | | / / \ | | 388 | | (E) (F)--(G)| | [E] [F]--[G]| | (E) (F)--(G)| | 389 | | \ / | | \ / | | \ / | | 390 | | \ / | | \ / | | \ / | | 391 | | (H) | | (H) | | [H] | | 392 | +---------------+ +---------------+ +---------------+ | 393 | (a) (b) (c) | 394 +-------------------------------------------------------------+ 396 Figure 4 The process of path discovery 398 In figure 4, every node has a neighbor domain. Node B and node C are 399 in A's neighbor domain, then B and C could receive A's message. In 400 the graph of (a), B and C have received A's messages. In the graph 401 of (b), E, F and G have received A's messages forwarded by B and C. 402 And in the graph of (c), node H has received A's messages forward by 403 E and F. The nodes in [square brackets] are new recipients. 405 To locate H, node A May construct a Scheduling Route Request (SRR) 406 message and send it to all of his neighbors to find a satisfying 407 path to H. This packet reaches B and C, as illustrated in (a) of 408 figure 4. In fact, the reason B and C are connected to A in the 409 graph is that they can receive communication from A. G, for example, 410 is not shown with an arc to A because it cannot receive A's radio 411 signal. Thus, G is not a neighbor to A and also not connected to A. 413 The main format of SRR message is shown in figure 5. It contains the 414 source and destination address, which identify who is looking for 415 whom. It also contains a Request ID, which is a local counter 416 maintained separately by each node and incremented each time a group 417 of SRR packets is sent to its neighbors. Together, the originator 418 address and the Request ID uniquely identify the special group of 419 SRR messages to allow nodes to discard any duplicates they may 420 receive. 422 +--------------+----------+-------------------+---------------+---------+---------------------+ 423 |Source address|Request ID|Destination address|Source sequence|Hop limit|Scheduling time limit| 424 +--------------+----------+-------------------+---------------+---------+---------------------+ 426 Figure 5 Main format of a Scheduling Route Request packet 428 In addition to the Request ID counter, there is also a second 429 sequence counter, Source sequence, which is incremented whenever a 430 SRR message is sent (or forward someone else's SRR message). It 431 functions a little bit like a clock. The fourth field of figure 5 is 432 A's sequence counter. 434 The Hop limit of SRR is used for terminating the diffusion of SRR 435 messages in the network. It SHALL be decremented by each forwarding 436 node before sending this packet towards its next hop. The packet is 437 not forwarded any further if Hops Left is decremented to zero. 439 The Scheduling time limit of SRR message is an accumulated limit of 440 path. Every time node sends a packet to its neighbor, the Scheduling 441 time limit will minus the scheduling time value of the send node to 442 its special neighbor, whatever the originator or the forwarding 443 nodes. When it is decremented to zero, the node will discard the 444 packet, and stop to send it to his neighbor. The original value of 445 Scheduling time limit in SRR is the same to the Scheduling Time 446 Limit in Scheduling Header. The use of these fields will become 447 clear shortly. 449 Before sending it to his neighbors, Node A will firstly compute the 450 scheduling time to every neighbor node according to scheduling 451 mechanism, and then compute the Scheduling Time Limit to every 452 neighbor (the old Scheduling time limit minus scheduling time to the 453 neighbor). If the new Scheduling time limit to a neighbor becomes to 454 0 or negative, A will not send the SRR to the neighbor. 456 When a SRR arrives at a node (B and C in this case), it is processed 457 in the following steps. 459 o Step 1: The tuple of (Source address, Request ID, Destination 460 address) is looked up in a local history table to see if this 461 request has already been seen and processed. If is a duplicate, 462 it is discarded and processing stops. If it is not a duplicate, 463 the tuple is entered into the history table so future duplicates 464 can be rejected, and processing continues. 466 o Step2: The receiver looks up its Neighbor Table, compute the 467 scheduling time to every neighbor node according to scheduling 468 mechanism, and then compute the Scheduling Time Limit to every 469 neighbor. If the new Scheduling time limit to a neighbor becomes 470 to 0 or negative, A will not send the SRR to the neighbor. 471 Instead, it will decrease the Hop left, increase the Source 472 sequence and renew the Scheduling time limit, and then resend the 473 SRR message to its neighbor. It is worth noting that if the Hop 474 left field becomes to 0, the sending process is terminated too. 476 o Step3: The receiver also extracts the data from the packet and 477 stories it as a new entry in its Reverse Route Table. This 478 information will be used to construct the reverse route so that 479 the acknowledgement packet can get back to the source later. And 480 a timer is also started for the newly-made reverse route entry. 481 If it expires, the entry is deleted. 483 Neither B nor C knows where H is, so each of them creates a reverse 484 route entry pointing back to A, and resend the SRR with a new Hop 485 Left, a new Source sequence, and a new Scheduling Time Limit. The 486 SRR from B reaches E and C. E makes an entry for it in its reverse 487 route table and resend it. In contrast, C rejects it as a duplicate. 488 Similarly, C's SRR is rejected by B. The process goes on, until H 489 receives the broadcast, and the special datagram reaches a 490 destination that knows where H is, namely H, as illustrated in (c) 491 graph of Figure 4. Note that although we have shown the sending 492 process in three discrete steps here, the SRR forwarded from 493 different nodes are not coordinated in any way. 495 In response to the incoming SRR message, H SHOULD builds an 496 acknowledgement packet, here called Scheduling Route Acknowledgement 497 (SRA) message. The main format of SRA message is shown in figure 6. 499 +--------------+----------+-------------------+-------+---------+ 500 |Source address|Request ID|Destination address|Path ID|Hop count| 501 +--------------+----------+-------------------+-------+---------+ 503 Figure 6 Main format of a Scheduling Route Acknowledgement packet 505 The Source address, Destination address, and Request ID are copied 506 from the incoming request message, but the Hop count field is 507 initialized to 0. The Path ID is a counter maintained by the 508 destination node. Each time, the destination node receives a SRR 509 message sent or forwarded by different node, it will increase the 510 Path ID, which means there is a new path. This message is unicast to 511 the node that the SRR message came from, in this case, E and F. It 512 then follows the reverse path to B or C, and finally to A. At each 513 node, Hop count is incremented so the node can see how far from the 514 destination (H) it is. 516 At each intermediate node on the way back, the message is inspected. 517 It is entered into the Route Table as a path to H. 519 In this way, all the nodes on the reverse route learn the path with 520 Path ID to H. And the original node (A) set the Path ID of SRA into 521 the Scheduling ID of the Scheduling header. When data with 522 Scheduling Header is sending, the intermediate nodes will know which 523 path to forward the data. 525 This document only shows the main fields of the SRR and SRA messages, 526 in fact, the SRR and SRA could be extended from the RPL messages or 527 other exiting protocols. The specific extension methods are out of 528 this document. 530 3.2. Route Maintenance 532 Because nodes can move or be switched off, the topology can change 533 spontaneously. When the topology has changed, the algorithm needs to 534 be able to deal with the failure. 536 4. IANA Considerations 538 This document defines a new Scheduling Header for 6LoWPAN to support 539 scheduling mechanism and to meet the industrial requirement of 540 determinism. 542 [RFC 4944] has allocated some values of dispatch for some headers. 543 This assignment preempts the assignment of 01 111111 for ESC [RFC 544 4944]; this preemption is possible because extension bytes that 545 would enable the use of ESC have not been allocated yet. But [RFC 546 6282] takes 01 000000 as a replacement value for ESC, and allocates 547 the value between 01 100000 to 01 111111 for LoWPAN_IPHC. Meanwhile, 548 it also creates a new IANA registry for LoWPAN_NHC, and has used the 549 value from 1110000 to 1110111. 551 As a result, the document allocates 01 000011 of the dispatch for 552 Scheduling dispatch. 554 5. Security Considerations 556 In industrial environment, the wireless networks share the same 557 place and time. In this case, if the security mechanism is not very 558 brilliant, it will seriously affect the system's information 559 security. The security mechanism is beyond the scope of this draft. 561 6. Conclusions 563 This document describes the method of transmission scheduling 564 information over 6LoWPAN Adaption layer for industrial application. 565 6LoWPAN nodes use the Scheduling Header to determine the packets 566 scheduling information, including the transmission path and 567 constraints, to meet the requirement of determinism. 569 7. References 571 7.1. Normative References 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, March 1997. 576 [RFC2234] Crocker, D. and Overell, P. (Editors), "Augmented BNF for 577 Syntax Specifications: ABNF", RFC 2234, Internet Mail 578 Consortium and Demon Internet Ltd., November 1997. 580 [RFC4919] N. Kushalnagar, and G. Montenegro, ''IPv6 over Low-Power 581 Wireless Personal Area Networks (6LoWPANs): Overview, 582 Assumptions, Problem Statement, and Goals'', RFC4919, 583 August 2007. 585 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and Culler, D., 586 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 587 RFC 4944, September 2007. 589 [RFC6282] J. Hui, Ed, "Compression Format for IPv6 Datagrams over 590 IEEE 802.15.4-Based Networks", RFC 6282, September 2011. 592 7.2. Informative References 594 [I-D.ietf-roll-indus-routing-reqs] Dust Networks, ''Industrial 595 Routing Requirements in Low Power and Lossy Networks", 596 draft-ietf-roll-indus-routing-reqs-06 (work in progress), 597 June 2009. 599 7.3. External Informative References 601 [HART] HART Communication Foundation, HART 7.0 Specification[S], 602 2008 604 [IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006", 605 June 2006 607 [ISA100.11a] ISA100.11a Working Group,''Wireless systems for 608 industrial automation: Process control and related 609 applications,'' ISA100.11a Draft standard, September 2008. 611 [WIA-PA] IEC/PAS 62601 Ed.1.0[S], WIA-PA communication network and 612 communication profile, 2009 614 Perkins, C.E., and Royer, E., ''The Ad Hoc On-demand Distance Vector 615 Routing,'' IEEE Workshop on Mobile Computing Systems and 616 Applications, IEEE, pp. 90-100, 1999 618 8. Acknowledgments 620 Thanks to the authors of RFC 4944 and RFC 6282.And, thanks to XXX for 621 edit of this document. Also thanks to XXX et al. 623 This document was prepared using 2-Word-v2.0.template.dot. 625 Authors' Addresses 627 Heng Wang 628 Chongqing University of Posts and Telecommunications 629 Administrative Building, Chongqing University of Posts and 630 Telecommunications 631 Chongqing, 400065 632 China 634 Phone: (86) -23- 6248- 7845 635 Email: wangheng@cqupt.edu.cn 637 Ping Wang 638 Chongqing University of Posts and Telecommunications 639 Administrative Building, Chongqing University of Posts and 640 Telecommunications 641 Chongqing, 400065 642 China 644 Phone: (86) -23- 6246- 1061 645 Email: wangping@cqupt.edu.cn 647 Chao Zhou 648 Cisco Systems (China) 649 Research and Development Co., Ltd. 650 8Floor, Xinsi Mansion 651 926 Yishan Lu, Caohejing Hi-Tech Park, 652 Shanghai, 200233 653 China 655 Phone: (86) -21- 2407- 3419 656 Email: czhou@cisco.com