Internet DRAFT - draft-wei-roll-scheduling-routing
draft-wei-roll-scheduling-routing
ROLL M. Wei
Internet Draft H. Wang
Interned status: Standards Track P. Wang
Expires: October 15, 2013 Chongqing University of
Posts and Telecommunications
C. Zhou
Cisco Systems
April 15, 2013
Industrial Deterministic Routing Extension for Low-Power and Lossy
Networks
draft-wei-roll-scheduling-routing-02.txt
Abstract
Low power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired and ad-hoc networks. Deterministic
networks is specified in IEEE 802.15.4e which is for deterministic
applications in the industrial environment. Some routing metrics
and constraints has been described in [RFC6551],[RFC5867] [RFC5826],
[RFC5673], and [RFC5548]. There are several special characteristics
and requirements in the industrial environment. This document
defines a new Link Metric/Constraint Object-Scheduling Waiting
Time to make RPL support deterministic scheduling mechanism, which
could improve the determinacy and reliability of the LLNs in
industrial environment.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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.
Wei, et al. Expires Oct. 15, 2013 [Page 1]
Internet-Draft draft-ietf-roll-scheduling-routing-02 Apirl 2013
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.
The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current/.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
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."
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete 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 Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire October 15, 2013.
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 Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Wei, et al. Expires Oct. 15, 2013 [Page 2]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
Table of Contents
1. Introduction ................................................ 3
1.1. Terminology ............................................ 5
1.2. Terms Used ............................................. 5
2. Requirements ................................................ 6
3. Object Formats .............................................. 7
4. Scheduling Waiting Time Object .............................. 7
4.1. Scheduling Waiting Time Description .....................7
4.2. Mode of Operation ...................................... 8
5. RPL instance with Scheduling Waiting Time object .............9
6. Security Considerations .................................... 12
7. IANA Considerations ........................................ 13
8. References ................................................. 14
8.1. Normative References................................... 14
8.2. Informative References ................................ 14
8.3. External Informative References ........................15
Authors' Addresses .............................................17
1. Introduction
This document makes use of the terminology defined in [ROLL-TERMS].
Low-power and Lossy Networks (LLNs) consist largely of constrained
nodes (with limited processing power, memory, and sometimes energy
when they are battery operated or energy scavenging). Low-power and
Lossy Networks (LLNs) have specific routing characteristics compared
with traditional wired or ad hoc networks that have been spelled out
in [RFC5548], [RFC5673], [RFC5826], and [RFC5867].
IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) is
specified in [RFC6550], which provides a mechanism whereby
multipoint-to-point traffic from devices inside the LLN towards a
central control point as well as point-to-multipoint traffic from the
central control point to the devices inside the LLN are supported.
The routing metrics and constraints are specified in [RFC6551], which
provides a high degree of flexibility and a set of routing metrics
and constraints. A variety of node constraints/metrics must be
possible taken into account during path computation (see RFC[6551]).
The routing metrics and constraints specified in [RFC6551] are not
specific to any particular link layer. It is really an excellent
Wei, et al. Expires Oct. 15, 2013 [Page 3]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
design criterion that the independence between RPL and link layer.
However, RPL is expected to be more suitable for industrial
application. In industrial wireless application, cross-layer design
needed to be considered to promote the performances of the
determinism scheduling, which is not only related to link layer, but
also affects the routing. This document focuses on the determinism
applications, such as wireless industrial applications. In this case,
the data link layer is designed based on the determinism scheduling
mechanism to meet the deterministic during communications. The main
factor of influencing the communication latency is scheduling waiting
time. The DLL cannot avoid influencing routing choice. The specific
routing metrics and constraints should be considered to promote using
RPL in the industrial deterministic application. Therefore, we design
a new metrics and constraints, to make RPL support determinism
scheduling applications.
IEEE 802.15.4e specifies some specific application, such as Low
latency deterministic networks (LLDN) and Timeslotted channel
hopping (TSCH) which are organized as a star topologies as well as
partial or full mesh topologies with a superframe structure and using
low latency frames. In this document, we will discuss how to use RPL
with Object-Scheduling Time in IEEE 802.15.4e networks. The network
coordinator of a low latency network indicates the existence of such
a low latency network by periodically sending low latency-beacons.
Allocating a dedicated time slot for each device provides a
deterministic system. The IEEE 802.15.4 DSSS coding together with
the exclusive channel access for each device ensures high reliability
of the system. Small time slots and short packets lead to superframes
as small as 10ms, which provides a latency of less than 10ms and a
low round trip time. The number of slots in a superframe determines
the number of devices that can access each channel.
Determinism is one of the most important requirements in industrial
application. It has two meanings, one is the deterministic during
single-hop communication, and the other is the deterministic during
multi-hop communication. The deterministic during single-hop
communication is guaranteed by the determinism scheduling mechanism.
The determinism scheduling mechanism makes certain nodes communicate
in certain slot. The determinism during multi-hop communication is
guaranteed by routing. Routing could ensure the whole scheduling time
during the path inside the constraint of users.
This document specifies Object-Scheduling Waiting Time as the routing
metrics and constraints to be used in path calculation for Low
Latency Deterministic Networks.
The new metrics and constraints we define in this document could be
advertised as a metric to optimize the computed path and as a
Wei, et al. Expires . 15, 2013 [Page 4]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
constraint. It could be used as one of the multi-metrics and work
with the others. When using a dynamic routing metric in LLND, a RPL
implementation should use multi-threshold schemes to void spurious
and unnecessary routing changes. For the object format structure, the
additional field is not added. The reserved bit is used. However, the
new object needs to be transmitted during the networking stage, which
in fact needs extra overhead of 4 bytes. While the network scheduling
information changes, we need re-send a new value. Otherwise, if
network scheduling information does not change, there is no need to
send new value.
It must be noted that the superframe structure has been decided during
the networking period in IEEE 802.15.4e networks. We assume the
superframe structure has been known for each node.
Note that the deterministic system is based on global synchronization.
Time synchronization is very crucial in industrial wireless
applications. Usually some special mechanisms and protocols are
designed and implemented to ensure time synchronization. This
document focuses on determinism routing. The determinism routing
metrics and constraints specified in this document are not specific
to any particular synchronization mechanism.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
1.2. Terms Used
MAC: Medium Access Control
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.
Wei, et al. Expires Oct. 15, 2013 [Page 5]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
Scheduling waiting time: The time is used to for a node have to wait
to send data to a special node in a period. 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 in
its send time slot, which is also the receive time slot of node B.
The time from the start time of transmit period to the slot above
mentioned is the scheduling waiting time from node A to node B. If
the network supports broadcasting mechanism, when node A broadcast a
messages in a slot, while the other nodes are just at their receive
slots.
Determinism: It is usually meant that access to the control network
by a node may be delayed, where t is known. In industrial wireless
network, it also means that data is sent and received within the
stipulated time.
2. Requirements
Wireless system has been widely used in factory automation area for
its low cost and availability. The requirements from the industrial
environment for a routing protocol in Low power and Lossy Networks
(LLNs) is analyzed in [RFC5673] based on IPv6 to power the next
generation of control technology, such as traffic characteristics
reliability requirements; device-aware routing requirements;
broadcast/multicast requirements; protocol performance requirements;
mobility requirements; manageability requirements; antagonistic
requirements and so on.
RPL has a lot of abilities to support the industrial environments,
which includes:
a)
RPL coexists with optimized routes, for construction of initial
suboptimal routes and for repair of optimized routes;
b)
RPL is adequate for non-production phases (unit startup and
shutdown), for emergency rerouting, for non-critical
applications, for small plants;
c)
Mobile devices (e.g., cranes) may need RPL;
d)
When using a reference (optimize d) DODAG version from a
centralized computer, RPL would provide local repair.
Wei, et al. Expires Oct. 15, 2013 [Page 6]
Internet-Draft draft-ietf-roll-scheduling-routing-02 Apirl 2013
However, an emphasis is placed on the requirements to be met by
deterministic applications with regard to reliability and
availability. In this document, we will discuss the deterministic
networks metrics and design the mechanism to use these metrics to
optimize routing.
3. Object Formats
Routing metrics and constraints are carried within the DAG Metric
Container object defined in [RFC6550].The Routing Metric/Constraint
objects represent a metric or a constraint of a particular type. They
may appear in any order in the DAG Metric Container (specified in
[RFC6550]). They have a common format consisting of one or more bytes
with a common header. The Routing Metric/Constraint Object Generic
Format has been defined in [RFC6551] as following.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Routing Metric/Constraint Object Generic Format
4. Scheduling Waiting Time Object
4.1. Scheduling Waiting Time Description
In this section, the Scheduling Waiting Time Object is defined to be
attached to the Link Metric/Constraint Objects, used for supporting
scheduling operations.
Similar to Link Latency Object, the Scheduling Waiting Time of many
LLN MAC sub-layers can vary over many orders of magnitude, again with
a corresponding change in power consumption. The Scheduling Waiting
Time Object is optional, and it is used based on user's requirement.
The Scheduling Waiting Time object SHOULD be present in the DAG
Wei, et al. Expires Oct. 15, 2013 [Page 7]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
Metric Container. There MUST NOT be more than one Scheduling Waiting
Time object as a constraint per DAG Metric Container, and there MUST
NOT be more than one Scheduling Waiting Time object as a metric per
DAG Metric Container.
The Scheduling Time object is made of Scheduling Waiting Time sub-
objects and MUST at least comprise one Scheduling Time sub-object.
Each Scheduling Waiting Time sub-object has a fixed length of 4 bytes.
The Scheduling Waiting Time object does not contain any additional
TLVs.
The Scheduling Waiting Time object Type is proposed to be set to 9 of
the reserved symbols, which must be confirmed by IANA. The format of
the Scheduling Waiting Time object body is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Scheduling Waiting Time Object Body Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheduling Waiting Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Scheduling Waiting Time sub-object Format
Scheduling Waiting Time: 32 bits. The Scheduling Time is encoded in
32 bits in unsigned integer format, expressed in microseconds.
4.2. Mode of Operation
The Scheduling Waiting Time may be used as a constraint or a path
metric.
For example, user may want the Scheduling Waiting Time not to exceed
some value. In this case, the Scheduling Waiting Time object common
header indicates that the provided value relates to a constraint. In
another example, the Scheduling Waiting Time object may be used as an
aggregated additive metric where the value is updated along the path
to reflect the path Scheduling Waiting Time.
Wei, et al. Expires Oct. 15, 2013 [Page 8]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
5. RPL instance with Scheduling Waiting Time object
There is an instance to explain how to use Scheduling Waiting Time
object to be as a metric and constraint. The topology of the network
is show as Fig.4. D is root node.
+---+
+--- | D | -------+
| +---+ |
| |
| |
+----+ +-----+
| E | | C |
+----+ +-----+
| |
| |
+----+ +-----+
| B | ------- | A |
+----+ +-----+
Figure 4 RPL instance
In the original RPL, DIO and DAO are used to construct and maintain
these DODAGs. The Objective Function (OF) defines how RPL nodes
select and optimize routes within a RPL instance. The OF defines how
nodes translate one or more metrics and constraints, which are
defined in [RFC6551], into a value called Rank, which approximates
the node's distance from a DODAG root.
There are two possible routings from A to D. We will discuss the
situation deterministic system, in the case, Scheduling Waiting Time
object could be used as the metric and constraint. For example, it
is noted that the MAC layer in industrial standards, including
ISA100.11a, WirelessHART and WIA-PA standards, defines the slot time
and channel resources of network with TDMA and ACA Adaptive Channel
Allocation mechanism. In the following example, we define a
timeslot as 10ms. Each node gets the all networks scheduling
information during the network initialization by network manager.
Wei, et al. Expires Oct. 15, 2013 [Page 9]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
+-----------------------------------------------------------------+
| A->B A->C B->A C->A B->E C->D E->B E->D D->E D->C |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
|SF | Y | | Y | Y | | Y | Y | | Y | Y | | Y | | Y | Y | |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| A->B A->C B->A C->A |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| A | Y | | Y | Y | | Y | | | | | | | | | | |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| A->B B->A B->E E->B |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| B | Y | | | Y | | | Y | | | Y | | | | | | |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| A->C C->A C->D D->C |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| C | | | Y | | | Y | | | Y | | | | | | Y | |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| C->D E->D D->E D->C |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| D | | | | | | | | | Y | | | Y | | Y | Y | |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| B->E E->B E->D D->E |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| E | | | | | | | Y | | | Y | | Y | | Y | | |
| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |
| |
| Y----used slot; SF-- superframe |
| |
+-----------------------------------------------------------------+
Figure 5 A scheduling instance in a IEEE802.15.4 network
As mentioned before, node A has two routes choices to send data to
node D. In the case of deterministic system, each node has to receive
or send data in a scheduled timeslots, which is decided by superframe.
As shown in Fig.5, allocating a dedicated time slot for each
device provides a deterministic system. There is a superframe, which
is decided by the system manager. Small time slots and short packets
lead to superframes as small as 10ms, which provides a latency of
less than 10ms and a low round trip time. The number of slots in a
Wei, et al. Expires Oct. 15, 2013 [Page 10]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
superframe determines the number of devices that can access each
channel.
There are 15 timeslots in the superframe, which has been allocated to
each node. We define them as timeslot 1, timeslot 2 ... timeslot 15.
+---+
+---- | D | <------+
| +---+ |
| |
| |
+----+ +-----+
| E | | C |
+----+ +-----+
| ^
| |
+----+ +-----+
| B | ------- | A |
+----+ +-----+
Figure 6 The data flow from A-C-D
The routing construct messages are advertised from node A. In the
timeslot 1, node A could send data to node B. Then in the timeslot 3,
node A could send data to node C. Therefore, the Scheduling Waiting
Time from A to B is 10ms, as well as, the Scheduling Waiting Time
from A to C is 30ms.
As shown in Fig.6, when the message has been sent to node C from node
A, node C forward the message to node D. In this deterministic system,
if node C wants to send data to node D, it have to send data at
timeslot 9 according to the superframe. Therefore the Scheduling
Waiting Time from C to D is 60ms. Then the total schedule waiting
time in the route A-C-D is 9 timeslots, which is equal to 90ms.
Wei, et al. Expires Oct. 15, 2013 [Page 11]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
+---+
+---> | D | -------+
| +---+ |
| |
| |
+----+ +-----+
| E | | C |
+----+ +-----+
^ |
| |
+----+ +-----+
| B | <--- | A |
+----+ +-----+
Figure 7 The data flow from A-B-E-D
It is similar for the situation in the other side as shown in Fig.7.
The Schedule Waiting Time from node A to node B is 10ms. Then the
message has been forward to E, node B has to wait 60ms to get the
send timeslot in timeslot 7. Then node E must wait 5 timeslots. When
the message has been to node D, the total Schedule Waiting Time is
120ms.
The total Schedule Waiting Times of the different routes are
different. There are about 3 timeslots delay could be optimized if we
consider Schedule Waiting Time as a metric.
It is similar to use the Schedule Waiting Time as a metric in
construct downward routes.
The Schedule Waiting Time may be used as a constraint also. When used
as constraint, the Schedule Waiting Time object may be inserted in
the DAG Metric Container to indicate that links with a specific Schedule
Waiting Time should be included or excluded from the computed path.
6. Security Considerations
This document has no requirement for a change to the security models
within associated protocols.
Wei, et al. Expires April 15, 2013 [Page 12]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
7. IANA Considerations
The definition of each field is defined in [RFC6551].
In this document, the Scheduling Waiting Time Object follows the
format. Considering several fields of this format is managed by IANA.
We discuss the possibility of new registry for the new object.
A new top-level registry, called "RPL Routing Metric/Constraint", has
been established by IANA to contain all Routing Metric/Constraint
objects codepoints and sub-registries.
The allocation policy for each new registry is by IETF review: new
values are assigned through the IETF review process (see [RFC5226]).
Specifically, new assignments are made via RFCs approved by the IESG.
Typically, the IESG will seek input on prospective assignments from
appropriate persons (e.g., a relevant working group if one exists).
New bit numbers may be allocated only by an IETF Review action. Each
bit should be tracked with the following qualities:
1. Bit number
2. Capability Description
3. Defining RFC
As shown in Fig.1, Routing Metric/Constraint object types has been
defined by IANA as following, which range from 0 to 255. Value 0 is
unassigned.
Value Meaning Reference
1 Node State and Attribute RFC6551
2 Node Energy RFC6551
3 Hop Count RFC6551
4 Link Throughput RFC6551
5 Link Latency RFC6551
6 Link Quality Level RFC6551
7 Link ETX RFC6551
8 Link Color RFC6551
9 Scheduling Waiting Time This document
This document defines a new Scheduling Waiting Time Object for RPL to
support scheduling mechanism and to meet the industrial requirement
Wei, et al. Expires Oct. 15, 2013 [Page 13]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
of determinism. There we propose to choose 9 for the Link Scheduling
Waiting Time.
8. References
8.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 4234] Crocker, D. and Overell, P. (Editors), "Augmented BNF
for Syntax Specifications: ABNF", RFC 2234, Internet
Mail Consortium and Demon Internet Ltd., November 1997.
[RFC 5673] K. Pister, P. Thubert, S. Dwars, T. Phinney "Industrial
Routing Requirements in Low-Power and Lossy Networks",
October 2009.
[RFC 5867] J. Martocci, P. De Mil, N. Riou, W. Vermeylen "Building
Automation Routing Requirements in Low-Power and Lossy
Networks" June 2010.
[RFC 5826] A. Brandt, J. Buron, G. Porcu, "Home Automation Routing
Requirements in Low-Power and Lossy Networks", April,
2010.
[RFC 5548] M. Dohler, T. Watteyne, T. Winter, D. Barthel "Routing
Requirements for Urban Low-Power and Lossy Networks"
May, 2009.
[RFC 6206] P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko, "The
Trickle Algorithm", RFC 6206, March 2011.
Wei, et al. Expires April 15, 2013 [Page 14]
Wei, et al. Expires Oct. 15, 2013 [Page 14]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
[RFC 6550] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey,
P. Levis, K. Pister, R. Struik, JP. Vasseur,
R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", March 2012.
[RFC 6551] JP. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel,
"Routing Metrics Used for Path Calculation in Low-
Power and Lossy Networks", March 2012.
[RFC 6552] P. Thubert, "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
March 2012.
[draft-palattella-6tsch-terminology-00] MR. Palattella, P. Thubert,
T. Watteyne, Q. Wang, "
Terminology in IPv6 over
Time Slotted Channel Hopping",
March 10, 2013.
[draft-thubert-6tsch-architecture-00] P. Thubert, RA. Assimiti, T.
Watteyne, "An Architecture
for IPv6 over Time Synchronized
Channel Hopping", March 11, 2013.
Wei, et al. Expires April 15, 2013 [Page 15]
[draft-wang-6tsch-6tus-00] Q. Wang, X. Vilajosana,
T. Watteyne, "6tus Adaptation
Layer Specification", March 11,
2013.
[draft-watteyne-6tsch-tsch-lln-context-01] T.Watteyne, "Using IEEE802.15.4e
TSCH in an LLN context: Overview,
Problem Statement and Goals",
February 21, 2013.
8.2. Informative References
[I-D.wang-6lowpan-scheduling-00] H. Wang, P. Wang, C. Zhou,
"Transmission Scheduling of IPv6
Packets over IEEE 802.15.4
Networks--Extension for Industrial
Application Space", draft-wang-
6lowpan-scheduling-00 (work in
progress), April 2012.
8.3. External Informative References
[IEEE802.15.4e] Ludwig Winkel, Zafer Sahinoglu, Liang Li,"
IEEE P802.15.4e/D0.01 Draft Standard for
Information technology-Telecommunications
Wei, et al. Expires Oct. 15, 2013 [Page 16]
Internet-Draft draft-ietf-roll-scheduling-routing-02 Apirl 2013
and information exchange between systems
Local and metropolitan area networks-
Specific requirements-Part 15.4: Wireless
Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks (WPANs)
Amendment 1: Add MAC enhancements for
industrial applications and CWPAN"
[IEC 62591] HCF, WirelessHART Device Specification,
HCF_SPEC-290[S], Revision1.1. HART
Communication Foundation, May 2009.
[IEC 62734] Industrial communication networks - Wireless
communication network and communication
profiles - ISA 100.11a, 2012
[IEC 62601] Industrial communication networks-Fieldbus
specification-WIA-PA communication network
and communication profile. 2011.
9 . Acknowledgments
Thanks to the authors of RFC 6550, RFC 6551 and RFC 6552. And, thanks
to JP. Vasseur for giving some comments for this document. And, thanks
to experts who were giving some comments for this document.And, thanks
to Wang Na and Pu Chenggen editing of this document. This document
was prepared using 2-Word-v2.0.template.dot.
Wei, et al. Expires Oct. 15, 2013 [Page 17]
Internet-Draft draft-ietf-roll-scheduling-routing-02 April 2013
Authors' Addresses
Min Wei
Chongqing University of Posts and Telecommunications
2 Chongwen Road,
Chongqing, 400065, China
Phone: (86) -13452333003
EMail: weimin@cqupt.edu.cn
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 Yinshan Lu, Caohejing Hi-Tech Park,
Shanghai, 200233
China
Phone: (86) -21- 2407- 3419
Email: czhou@cisco.com
