6LoWPAN Working Group H. Wang Internet Draft P. Wang Interned status: Standards Track Chongqing University of Expires: October 21, 2012 Posts and Telecommunications C. Zhou Cisco Systems April 20, 2012 Transmission Scheduling of IPv6 Packets over IEEE 802.15.4 Networks-- - Extension for Industrial Application Space draft-wang-6lowpan-scheduling-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on mouth date year. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Wang, et al. Expires October 21, 2012 [Page 1] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract These years, wireless technologies, including the application of 6LoWPAN protocol, are more and more been applied in industrial environment to improve productivity and safety of the plants. In spite of the fact that [RFC4944] has introduced the methods of transmitting IPv6 packets over IEEE 802.15.4 networks, industrial automation field, either process automation or factory automation, has its special characteristics and requirements. If 6LoWPAN is been used in industrial environment, some change SHOULD be made in the adaption layer. This document defines a Scheduling Header, to make the adaption layer meet the requirements of industrial scheduling for transmission of IPv6 packets over IEEE 802.15.4 networks. Additionally, this document also provides an application example of Scheduling Header. Table of Contents 1. Introduction ................................................ 2 1.1. Requirements Notation .................................. 4 1.2. Terms Uesd ............................................. 4 2. Scheduling Header ........................................... 5 2.1. Scheduling dispatch and IPv6 header stack .............. 5 2.2. Scheduling Header ...................................... 6 3. An example using Scheduling Header .......................... 7 3.1. Route Discovery......................................... 7 3.2. Route Maintenance ..................................... 12 4. IANA Considerations ........................................ 12 5. Security Considerations .................................... 12 6. Conclusions ................................................ 13 7. References ................................................. 13 7.1. Normative References .................................. 13 7.2. Informative References ................................ 13 7.3. External Informative References ....................... 13 8. Acknowledgments ............................................ 14 1. Introduction Wireless technology has been demonstrated as an effective option for industrial applications. For convenient and fast deployment in a global world, it has attracted huge attention to introduce IPv6 technology to wireless industrial networks. But in the industrial environment, especially the environments (eg. a coal mine) with high Wang, et al. Expires October 21, 2012 [Page 2] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 risk and low bandwidth, the resources are too limited. Which MUST be scheduled properly to ensure every significant thing be done in its specific time and channel and to ensure the safety and reliability. It is worth mentioning that the MAC layers of some industrial standards, [ISA100.11a]/[Wireless Hart]/[WIA-PA] standards, schedule the slot time and channel resources of network with TDMA and ACA Adaptive Channel Allocation mechanism. Through the investigation of the data features and the application class of wireless industrial applications, a conclusion can be draw that the important requirements for wireless industrial networks are: * Determinism * Reliability * Real time * Security * Synchronization However, the adaption layer of 6LoWPAN defined in RFC 4944 is mainly based on contention access and best effort delivery. It does not make special optimization for industrial applications. To meet above requirements, it is recommended to improve the design of the adaption layer for transmission of IPv6 packets. ISA100.11a adopts 6LoWPAN as its network layer, but the function of 6LoWPAN in is limited. For example, the operations of scheduling and routing in the wireless subnet are performed by upper data link layer of ISA100.11a rather than network layer. Moreover, ISA100.11a is an integrated solution for industrial control net, including system manager, gateway, provisioning and a series of new protocols for every layer except physical layer. 6LoWPAN is just a part of ISA100.11a system. For simple or lightweight industrial applications which want to use IPv6 technology, the ISA100.11a has too much overhead to deploy. Thus, it is attractive to add direct support mechanism for industrial applications in 6LoWPAN. Industrial users will benefit from more choices for different kinds of applications. Consequently, it's hoped that 6LoWPAN supports the schedule mechanism, and to be more suitable for industrial application. In this case, the MAC layer is based on slot time, while the upper layer, called the adaption layer, is based on non-slot. Therefore, it is necessary to improve the frame format of the adaptation layer, to make it support scheduling operations. Wang, et al. Expires October 21, 2012 [Page 3] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 As a result, this document improves the frame format of the adaptation and defines a scheduling header. In addition, this document also introduces an application example of the Scheduling Header. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 1.2. Terms Uesd MAC: Medium Access Control Industrial Wireless Standard: At present, there are three main industrial wireless standards, ISA100.11a, WirelessHART, and WIA-PA. ISA: ''International Society of Automation''. ISA is an ANSI accredited standards-making society. ISA100 is an ISA committee whose charter includes defining a family of standards for industrial automation. [ISA100.11a] is a working group within ISA100 that is working on a standard for monitoring and non-critical process control applications. HART: ''Highway Addressable Remote Transducer'', a group of specifications for industrial process and control devices administered by the HART Foundation. The specifications include the additions for Wireless HART. WIA-PA: ''Wireless Networks for Industrial Automation-Process Automation'', a Chinese industrial wireless specification, is passed by 96% of IEC(International Electrotechnical Commission) members, and formally released as IEC/PAS 62601 standard document. CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance TDMA: Time Division Multiple Address GTS: Guaranteed Time Slot Safety: It means the system's safety of industrial environment, including the safety of devices and human safety. Security: It means the specific security mechanism or security algorithm. Wang, et al. Expires October 21, 2012 [Page 4] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 Scheduling time: It means the time a node must to wait between the time it wanted to send data or received data and the moment it send data to a special node. When the MAC layer schedules the slot time and channel resources of network with TDMA mechanism, every node get send slots and receive slots. In this case if node A wants to send data to node B, it have to send data at its send slot, which is also the receive slot of node B. The time from the time A wanted to send data to the slot above mentioned is the scheduling time from node A to node B. It is noteworthy that the scheduling time from A to B is usually different from the scheduling time from B to A. Determinism: It is usually meant that access to the control network by a node may be delayed by at most some time t, where t is known. In industrial wireless network, it also means that data is sent and received within the stipulated time. Neighbor domain: It means the neighbors a node could reach to. Node could use neighbor discovery to find its neighbors and store the neighbors' addresses in its neighbor table. 2. Scheduling Header In this section, we define the scheduling dispatch value and the field of Scheduling Header, used for supporting scheduling operations. 2.1. Scheduling dispatch and IPv6 header stack The definition of LoWPAN headers, other than mesh addressing and fragmentation, consists of the dispatch value, and the definition of the header fields that follow. Note that [RFC 4944] has defined some values for some headers. In order to avoid any conflicts with the existing standard documents, including [RFC 4944] and [RFC 6282], we make full use of the reserved symbols of dispatch. Here, we set the value of Scheduling dispatch is 01 000011. The Scheduling dispatch and the Scheduling Header are shown here: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1|0 0 0 0 1 1| Scheduling Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Scheduling dispatch and Scheduling Header The dispatch value may be treated as unstructured namespace. Only a few symbols have been used to represent current LoWPAN functionality Wang, et al. Expires October 21, 2012 [Page 5] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 according to [RFC 4944]. We can use the non-defined values to encode additional functionality. According to RFC 4944, all LoWPAN encapsulated datagrams transported over IEEE 802.15.4 are prefixed by an encapsulated header stack. Whereas in an IPv6 header stack, the Scheduling dispatch and the Scheduling Header follow the Mesh Header and the next are other headers, or options, finally payload. An Ipv6 header stack containing Scheduling Header is shown as figure 2. +---------+------------+--------------------+------------------+-------------+--------+ |Mesh Type| Mesh Header| scheduling dispatch| Scheduling Header| other header| payload| +---------+------------+--------------------+------------------+-------------+--------+ Figure 2 An Ipv6 header stack containing Scheduling Header Here, the other headers contain IPv6 header or other compressed IPv6 headers, and other types of header. 2.2. Scheduling Header The Scheduling Header is shown here: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence ID | Scheduling ID | Scheduling Time Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Scheduling Header Field definitions are as follows: Sequence ID: This 8-bit field is a local counter maintained separately by each node and SHALL be incremented by the originator whenever it sends a datagram with a Scheduling Header. This field is used for follow-up maintenance, for example it could be used to tell new datagrams from old datagrams. Scheduling ID: This 8-bit field is used for identifying paths or other scheduling parameter, which SHALL meet the industrial requirements mentioned in the above section of Introduction, especially the requirements of determinism. During the transmission of the datagram, the Scheduling ID could show the information of propagation path. Wang, et al. Expires October 21, 2012 [Page 6] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 Scheduling Time Limit: This 16-bit field is used mainly to identify the maximum scheduling time a packet allowed to be sent. It is the key field to ensure the requirement of determinism, and in units of milliseconds. This field can contain values up to 65535. Additionally, it is an accumulated metric, an aggregation of scheduling time value of every node along the path. Especially, when a datagram with the requirement of determinism is sent for the first time, this field is necessary for it to choose a satisfying path. It is worth noting that the above definition of the Scheduling Header is originally envisaged. With the subsequent increase in scheduling applications, it MAY be further modified. Meanwhile, the definition of the fields SHOULD be applied flexibly, according to actual needs. 3. An example using Scheduling Header Scheduling Header defined aims to support scheduling operation, and to meet the industrial application requirements of determinism. According to the initial consideration, the Scheduling Time Limit is the key field to ensure determinism, which is used mainly to identify the maximum scheduling time a packet allowed along the transmission path. It is also to say that a datagram must be transmitted from source node to destination node with the given Scheduling Time Limit. So, we can see it as an accumulated routing metric. Along this train of thought, route discovery MAY be an obvious application of Scheduling Header defined above. The aim of this section is simply to provide an example of Scheduling Header application, using it in route discovery. Needless to say that the MAC layer SHOULD based on TDMA and ACA mechanism, which schedules the slot time and channel resources of network. 3.1. Route Discovery The way of route discovery in this section is an on-demand algorithm, that is, it determines a route to some destination only when somebody wants to send packet to this destination within a Scheduling Time Limit. The Scheduling Time Limit is set by users. The route discovery process is similar to AODV (Ad hoc On-demand Distance Vector) routing algorithm. However, the broadcast slots in the deterministic scheduling mechanism are usually for organizing network and time synchronization, using broadcast slots in route discovery MAY effect the functional aspects of whole network. Meanwhile, the route discovery for datagram is on-demand and optional. So, it usually uses the non-broadcast slot for route Wang, et al. Expires October 21, 2012 [Page 7] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 discovery. One of the solutions is that node use a group of unicast messages to realize the broadcast effectiveness. In order to describe route discovery process in detail, we make following assumptions: o The MAC layer is based on TDMA, if node A could send packet to node B in a slot, then node B could send packet to node A in a slot too. o Before the route discovery process, the scheduling process is over, and every node knows its send slot and scheduling time to a special node. o The mesh network can be described by a graph of the nodes (routers + end devices). Two nodes are connected (i.e., have an arc between them in the graph) if they are in each other's neighbor domain. To describe the algorithm, consider the mesh network of figure 4, in which a process on node A wants to send a packet to node H. This algorithm maintains some tables at each node, including: o Scheduling Path History Table, which is maintained by source node, stores information about that destination, including the Path ID, the destination address, as well as the Scheduling Time Limit. o Neighbor Table, which is got from the neighbor discovery process before scheduling process, stores the address information of the node's neighbors. o Route Table, which is maintained by routers, stores information about that destination, including the Path ID, the destination address, as well as the next hop address. o Local History Table, which is maintained by routers, stores the tuple (Source address, Request ID, Destination address) for determining duplicate packet. o Reverse Route Table, which is maintained by every node, stores the reverse route information. This information used to construct the reverse route so the reply packet can get back to the source later. Meanwhile, a timer is also started for the newly-made reverse route entry. If it expires, the entry is deleted. According to the user's requirements, A wants to send data with Scheduling Header to H. Suppose that A looks in its Scheduling Path Wang, et al. Expires October 21, 2012 [Page 8] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 History table and does not find an entry for H to ensure the requirements of Scheduling Time Limit. It now has to discover a path to H, which could meet the constraints. This property of discovering paths only when they are needed is what makes this algorithm ''on demand.'' +-------------------------------------------------------------+ | +---------------+ +---------------+ +---------------+ | | | (A) | | (A) | | (A) | | | | / \ | | / \ | | / \ | | | | / \ | | / \ | | / \ | | | | [B]---[C] | | (B)---(C) | | (B)---(C) | | | | / / \ | | / / \ | | / / \ | | | | / / \ | | / / \ | | / / \ | | | | (E) (F)--(G)| | [E] [F]--[G]| | (E) (F)--(G)| | | | \ / | | \ / | | \ / | | | | \ / | | \ / | | \ / | | | | (H) | | (H) | | [H] | | | +---------------+ +---------------+ +---------------+ | | (a) (b) (c) | +-------------------------------------------------------------+ Figure 4 The process of path discovery In figure 4, every node has a neighbor domain. Node B and node C are in A's neighbor domain, then B and C could receive A's message. In the graph of (a), B and C have received A's messages. In the graph of (b), E, F and G have received A's messages forwarded by B and C. And in the graph of (c), node H has received A's messages forward by E and F. The nodes in [square brackets] are new recipients. To locate H, node A May construct a Scheduling Route Request (SRR) message and send it to all of his neighbors to find a satisfying path to H. This packet reaches B and C, as illustrated in (a) of figure 4. In fact, the reason B and C are connected to A in the graph is that they can receive communication from A. G, for example, is not shown with an arc to A because it cannot receive A's radio signal. Thus, G is not a neighbor to A and also not connected to A. The main format of SRR message is shown in figure 5. It contains the source and destination address, which identify who is looking for whom. It also contains a Request ID, which is a local counter maintained separately by each node and incremented each time a group of SRR packets is sent to its neighbors. Together, the originator address and the Request ID uniquely identify the special group of SRR messages to allow nodes to discard any duplicates they may receive. Wang, et al. Expires October 21, 2012 [Page 9] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 +--------------+----------+-------------------+---------------+---------+---------------------+ |Source address|Request ID|Destination address|Source sequence|Hop limit|Scheduling time limit| +--------------+----------+-------------------+---------------+---------+---------------------+ Figure 5 Main format of a Scheduling Route Request packet In addition to the Request ID counter, there is also a second sequence counter, Source sequence, which is incremented whenever a SRR message is sent (or forward someone else's SRR message). It functions a little bit like a clock. The fourth field of figure 5 is A's sequence counter. The Hop limit of SRR is used for terminating the diffusion of SRR messages in the network. It SHALL be decremented by each forwarding node before sending this packet towards its next hop. The packet is not forwarded any further if Hops Left is decremented to zero. The Scheduling time limit of SRR message is an accumulated limit of path. Every time node sends a packet to its neighbor, the Scheduling time limit will minus the scheduling time value of the send node to its special neighbor, whatever the originator or the forwarding nodes. When it is decremented to zero, the node will discard the packet, and stop to send it to his neighbor. The original value of Scheduling time limit in SRR is the same to the Scheduling Time Limit in Scheduling Header. The use of these fields will become clear shortly. Before sending it to his neighbors, Node A will firstly compute the scheduling time to every neighbor node according to scheduling mechanism, and then compute the Scheduling Time Limit to every neighbor (the old Scheduling time limit minus scheduling time to the neighbor). If the new Scheduling time limit to a neighbor becomes to 0 or negative, A will not send the SRR to the neighbor. When a SRR arrives at a node (B and C in this case), it is processed in the following steps. o Step 1: The tuple of (Source address, Request ID, Destination address) is looked up in a local history table to see if this request has already been seen and processed. If is a duplicate, it is discarded and processing stops. If it is not a duplicate, the tuple is entered into the history table so future duplicates can be rejected, and processing continues. o Step2: The receiver looks up its Neighbor Table, compute the scheduling time to every neighbor node according to scheduling mechanism, and then compute the Scheduling Time Limit to every Wang, et al. Expires October 21, 2012 [Page 10] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 neighbor. If the new Scheduling time limit to a neighbor becomes to 0 or negative, A will not send the SRR to the neighbor. Instead, it will decrease the Hop left, increase the Source sequence and renew the Scheduling time limit, and then resend the SRR message to its neighbor. It is worth noting that if the Hop left field becomes to 0, the sending process is terminated too. o Step3: The receiver also extracts the data from the packet and stories it as a new entry in its Reverse Route Table. This information will be used to construct the reverse route so that the acknowledgement packet can get back to the source later. And a timer is also started for the newly-made reverse route entry. If it expires, the entry is deleted. Neither B nor C knows where H is, so each of them creates a reverse route entry pointing back to A, and resend the SRR with a new Hop Left, a new Source sequence, and a new Scheduling Time Limit. The SRR from B reaches E and C. E makes an entry for it in its reverse route table and resend it. In contrast, C rejects it as a duplicate. Similarly, C's SRR is rejected by B. The process goes on, until H receives the broadcast, and the special datagram reaches a destination that knows where H is, namely H, as illustrated in (c) graph of Figure 4. Note that although we have shown the sending process in three discrete steps here, the SRR forwarded from different nodes are not coordinated in any way. In response to the incoming SRR message, H SHOULD builds an acknowledgement packet, here called Scheduling Route Acknowledgement (SRA) message. The main format of SRA message is shown in figure 6. +--------------+----------+-------------------+-------+---------+ |Source address|Request ID|Destination address|Path ID|Hop count| +--------------+----------+-------------------+-------+---------+ Figure 6 Main format of a Scheduling Route Acknowledgement packet The Source address, Destination address, and Request ID are copied from the incoming request message, but the Hop count field is initialized to 0. The Path ID is a counter maintained by the destination node. Each time, the destination node receives a SRR message sent or forwarded by different node, it will increase the Path ID, which means there is a new path. This message is unicast to the node that the SRR message came from, in this case, E and F. It then follows the reverse path to B or C, and finally to A. At each node, Hop count is incremented so the node can see how far from the destination (H) it is. Wang, et al. Expires October 21, 2012 [Page 11] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 At each intermediate node on the way back, the message is inspected. It is entered into the Route Table as a path to H. In this way, all the nodes on the reverse route learn the path with Path ID to H. And the original node (A) set the Path ID of SRA into the Scheduling ID of the Scheduling header. When data with Scheduling Header is sending, the intermediate nodes will know which path to forward the data. This document only shows the main fields of the SRR and SRA messages, in fact, the SRR and SRA could be extended from the RPL messages or other exiting protocols. The specific extension methods are out of this document. 3.2. Route Maintenance Because nodes can move or be switched off, the topology can change spontaneously. When the topology has changed, the algorithm needs to be able to deal with the failure. 4. IANA Considerations This document defines a new Scheduling Header for 6LoWPAN to support scheduling mechanism and to meet the industrial requirement of determinism. [RFC 4944] has allocated some values of dispatch for some headers. This assignment preempts the assignment of 01 111111 for ESC [RFC 4944]; this preemption is possible because extension bytes that would enable the use of ESC have not been allocated yet. But [RFC 6282] takes 01 000000 as a replacement value for ESC, and allocates the value between 01 100000 to 01 111111 for LoWPAN_IPHC. Meanwhile, it also creates a new IANA registry for LoWPAN_NHC, and has used the value from 1110000 to 1110111. As a result, the document allocates 01 000011 of the dispatch for Scheduling dispatch. 5. Security Considerations In industrial environment, the wireless networks share the same place and time. In this case, if the security mechanism is not very brilliant, it will seriously affect the system's information security. The security mechanism is beyond the scope of this draft. Wang, et al. Expires October 21, 2012 [Page 12] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 6. Conclusions This document describes the method of transmission scheduling information over 6LoWPAN Adaption layer for industrial application. 6LoWPAN nodes use the Scheduling Header to determine the packets scheduling information, including the transmission path and constraints, to meet the requirement of determinism. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P. (Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC4919] N. Kushalnagar, and G. Montenegro, ''IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals'', RFC4919, August 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and Culler, D., "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC6282] J. Hui, Ed, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. 7.2. Informative References [I-D.ietf-roll-indus-routing-reqs] Dust Networks, ''Industrial Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-indus-routing-reqs-06 (work in progress), June 2009. 7.3. External Informative References [HART] HART Communication Foundation, HART 7.0 Specification[S], 2008 [IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006", June 2006 Wang, et al. Expires October 21, 2012 [Page 13] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 [ISA100.11a] ISA100.11a Working Group,''Wireless systems for industrial automation: Process control and related applications,'' ISA100.11a Draft standard, September 2008. [WIA-PA] IEC/PAS 62601 Ed.1.0[S], WIA-PA communication network and communication profile, 2009 Perkins, C.E., and Royer, E., ''The Ad Hoc On-demand Distance Vector Routing,'' IEEE Workshop on Mobile Computing Systems and Applications, IEEE, pp. 90-100, 1999 8. Acknowledgments Thanks to the authors of RFC 4944 and RFC 6282.And, thanks to XXX for edit of this document. Also thanks to XXX et al. This document was prepared using 2-Word-v2.0.template.dot. Wang, et al. Expires October 21, 2012 [Page 14] Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012 Authors' Addresses Heng Wang Chongqing University of Posts and Telecommunications Administrative Building, Chongqing University of Posts and Telecommunications Chongqing, 400065 China Phone: (86) -23- 6248- 7845 Email: wangheng@cqupt.edu.cn Ping Wang Chongqing University of Posts and Telecommunications Administrative Building, Chongqing University of Posts and Telecommunications Chongqing, 400065 China Phone: (86) -23- 6246- 1061 Email: wangping@cqupt.edu.cn Chao Zhou Cisco Systems (China) Research and Development Co., Ltd. 8Floor, Xinsi Mansion 926 Yishan Lu, Caohejing Hi-Tech Park, Shanghai, 200233 China Phone: (86) -21- 2407- 3419 Email: czhou@cisco.com Wang, et al. Expires October 21, 2012 [Page 15]