ROLL M. Wei Internet Draft H. Wang Interned status: Standards Track P. Wang Expires: April 12, 2013 Chongqing University of Posts and Telecommunicatis C. Zhou Cisco Systems October 12, 2012 Industrial Deterministic Routing Extension for Low-Power and Lossy Networks draft-wei-roll-scheduling-routing-00.txt Abstract Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks. Low Latency Deterministic Networks(LLDN) 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 April 12, 2013 [Page 1] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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 April 12, 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 April 12, 2013 [Page 2] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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 April 12, 2013 [Page 3] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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 it support determinism scheduling applications. Low Latency Deterministic Networks(LLDN) is specified in IEEE 802.15.4e which is organized as a star network with a superframe structure and using low latency frames. In this document, we will discuss how to use RPL with Object-Scheduling Time in LLDN. 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 LLDN device provides a deterministic system. The IEEE 802.15.4 DSSS coding together with the exclusive channel access for each LLDN 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 LLDN 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 April 12, 2013 [Page 4] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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 be decided during the networking period in LLDN. 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 [RFC 2119]. 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 April 12, 2013 [Page 5] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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 April 12, 2013 [Page 6] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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, we define the Scheduling Waiting Time Object 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 April 12, 2013 [Page 7] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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 April 12, 2013 [Page 8] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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. +---+ +--- | A | -------+ | +---+ | | | | | +----+ +-----+ | B | | C | +----+ +-----+ | | | | +----+ +-----+ | E | ------- | D | +----+ +-----+ 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 E. 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 10 ms. Wei, et al. Expires April 12, 2013 [Page 9] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 +-----------------------------------------------------------------+ | 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 LLDN As mentioned before, node A has two routes choices to send data to node E. 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 LLDN 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 April 12, 2013 [Page 10] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 superframe determines the number of LLDN 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. +---+ +---- | A | -------+ | +---+ | | | | V +----+ +-----+ | B | | C | +----+ +-----+ | | | V +----+ +-----+ | E | ------- | D | +----+ +-----+ 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 April 12, 2013 [Page 11] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 +---+ +--- | A | -------+ | +---+ | | | V | +----+ +-----+ | B | | C | +----+ +-----+ | | V | +----+ +-----+ | E | ----> | D | +----+ +-----+ 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 90ms to get the send timeslot in timeslot 10. Then node E must wait 3 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 12, 2013 [Page 12] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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 April 12, 2013 [Page 13] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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. [RFC2234] Crocker, D. and Overell, P. (Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC6206] P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko, "The Trickle Algorithm", RFC 6206, March 2011. [RFC6550] 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. [RFC6551] JP. Vasseur, M. Kim, K. Pister, N. Dejean, D. Barthel, "Routing Metrics Used for Path Calculation in Low- Power and Lossy Networks", March 2012. [RFC6552] P. Thubert, "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", March 2012. 8.2. Informative References [I-D.wang-6lowpan-scheduling-00] H. Wang, P. Wang, C. Zhou, Wei, et al. Expires April 12, 2013 [Page 14] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 "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 1212. 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 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. Wei, et al. Expires April 12, 2013 [Page 15] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 [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 Wang Na editing of this document. This document was prepared using 2-Word-v2.0.template.dot. Wei, et al. Expires April 12, 2013 [Page 16] Internet-Draft draft-ietf-roll- scheduling-routing -00 October 2012 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 Wei, et al. Expires April 12, 2013 [Page 17]