Internet DRAFT - draft-wang-6tisch-6top-coapie

draft-wang-6tisch-6top-coapie







6TiSCH                                                      Q. Wang, Ed.
Internet-Draft                           Univ. of Sci. and Tech. Beijing
Intended status: Informational                             X. Vilajosana
Expires: January 3, 2016                 Universitat Oberta de Catalunya
                                                             T. Watteyne
                                                       Linear Technology
                                                            R. Sudhaakar
                                                           Cisco Systems
                                                                 P. Zand
                                                    University of Twente
                                                            July 2, 2015


   Transporting CoAP Messages over IEEE802.15.4e Information Elements
                    draft-wang-6tisch-6top-coapie-01

Abstract

   This document describes the format of "CoAP IE", an IEEE802.15.4e
   Information Element which allows CoAP messages to be transported as
   part of the IEEE802.15.4e payload IE.  This enables 6top-to-6top
   communication between neighbor nodes in a 6TiSCH network.

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).  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/.

   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."

   This Internet-Draft will expire on January 3, 2016.

Copyright Notice

   Copyright (c) 2015 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



Wang, et al.             Expires January 3, 2016                [Page 1]

Internet-Draft             6tisch-6top-coapie                  July 2015


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   2
     1.2.  Context within 6TiSCH . . . . . . . . . . . . . . . . . .   2
     1.3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.4.  Status of this Document . . . . . . . . . . . . . . . . .   3
   2.  CoAP IE Format  . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Softcell Negotiation Interface RPC Definition . . . . . . . .   5
   4.  CoAP support  . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  URI setting . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  CoAP Block option . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Management Interface Protocol . . . . . . . . . . . . . .   8
     4.4.  Negotiation interface protocol  . . . . . . . . . . . . .   8
     4.5.  Acknowledgement . . . . . . . . . . . . . . . . . . . . .   9
     4.6.  Observe . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Implementation Considerations . . . . . . . . . . . . . . . .  10
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     6.3.  External Informative References . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

1.1.  Requirements Notation

   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 [RFC2119].

1.2.  Context within 6TiSCH

   This document fits in the work done at the IETF 6TiSCH WG as follows:

   o  [I-D.wang-6tisch-6top-sublayer] defines the operation of the 6top
      sublayer, which monitors and manages the communication schedule
      used in the [IEEE802154e] TSCH network.





Wang, et al.             Expires January 3, 2016                [Page 2]

Internet-Draft             6tisch-6top-coapie                  July 2015


   o  [I-D.ietf-6tisch-6top-interface] defines the interface of the 6top
      sublayer using the YANG data modeling language [RFC6020].

   o  [I-D.ietf-6tisch-coap] translates this YANG model in CoAP
      resources and interactions, allowing an Internet host (possibly
      but not necessarily constrained) to monitor and manage the 6top
      sublayer of a 6TiSCH device.

   o  This document defines a method for transporting those CoAP
      messages as part of the IEEE802.15.4e payload IE.  It does so by
      defining a new IEEE802.15.4e Information Element called "CoAP IE".
      This allows a 6TiSCH node to monitor and manage the 6top sublayer
      and enables pairwise communication for signaling and control
      between neighbor nodes.

1.3.  Motivation

   The 6TiSCH architecture [I-D.ietf-6tisch-architecture] allows for
   both centralized and distributed monitoring and management of a
   6TiSCH schedule.  [I-D.ietf-6tisch-coap] defines the mechanisms
   necessary for the centralized case.  The present document defines a
   mechanism enabling the communication of nodes in a 1 hop
   neighborhood, enabling a distributed approach.

   In particular, it allows a node to monitor and manage its neighbor
   node's MIB.  Through the CoAP IE defined in this document, a node
   sends link-layer frames to its neighbor which contain, as part of the
   link-layer payload IE, the CoAP messages defined in
   [I-D.ietf-6tisch-coap].  This allows a node to interact with the 6top
   interface of its neighbor, in a way equivalent to an Internet host
   interacting with a 6TiSCH device over CoAP.

   In addition, this document describe the frame formats and interaction
   between a node and its neighbor during softcell negotiation
   [I-D.wang-6tisch-6top-sublayer], through the addition of an Remote
   Procedure Call "RPC" element to the YANG model defined in
   [I-D.ietf-6tisch-6top-interface].

   We call "6top-to-6top" communication the interaction between a node
   and its neighbor using the CoAP IE.

1.4.  Status of this Document

   The authors decided to present the CoAP IE as a separate document to
   request discussion and suggestions for improvement from the Internet
   community.





Wang, et al.             Expires January 3, 2016                [Page 3]

Internet-Draft             6tisch-6top-coapie                  July 2015


   If the document gets support, and after suggestions for improvement
   have been integrated, the author propose to merge it in existing
   6TiSCH I-Ds as follows:

   o  Section 3 would go into [I-D.ietf-6tisch-6top-interface];

   o  Section 4 would go into [I-D.ietf-6tisch-coap];

   o  Section 2 and Section 5 would go into
      [I-D.wang-6tisch-6top-sublayer].

2.  CoAP IE Format

   The CoAP IE is a container for transporting CoAP messages as part of
   the IEEE802.15.4e payload IE, as an Information Element.  It is used
   by both the management interface and the softcell negotiation
   interface for 6top-to-6top communication.

   This IE is not present in [IEEE802154e]; it is defined in this
   document.

   Format of a CoAP IE.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |    SubID    |T|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   //                                                              //
   |                   Fragmented CoAP message                     |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

   The fields in CoAP IE header are defined as follows.

   o  Length = 1

   o  SubID = 0x44

   o  T = 0 (short type)

   The content of CoAP IE is a CoAP message compliant to [RFC7252].  The
   CoAP message MAY use the CoAP Block option (see Section 4.2) in order
   to fragment large CoAP messages.






Wang, et al.             Expires January 3, 2016                [Page 4]

Internet-Draft             6tisch-6top-coapie                  July 2015


   Format of CoAP IE with CoAP message.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      CoAP IE header           |Ver| T |  TKL  |   Code        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message ID                   |    Token (0-8B, assume 2B)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Uri-path option                                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  11111111     |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   //                                                              //
   |                 CoAP message payload (variable)               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   The Token Length (TKL)is set to 2;

   Per [RFC7252], the Uri-path field consists of the following sub-
   fields:

   o  Option Delta: 4bits, set to 11

   o  Option Length: 4bits, set to 3

   o  Option value: 3 bytes

   The first byte of the option value is set to "6" (for 6top), "4" (for
   IEEE802.15.4), or "e" (for extension).  The second and third bytes
   refer to the resource name in the corresponding group.

3.  Softcell Negotiation Interface RPC Definition

   This document proposes to replace the "6top Communication Protocol"
   defined in [I-D.wang-6tisch-6top-sublayer] by an extension to the
   YANG data model defined in [I-D.ietf-6tisch-6top-interface].  This
   allows neighbor nodes to negotiate the allocation of soft cells using
   the CoAP IE.










Wang, et al.             Expires January 3, 2016                [Page 5]

Internet-Draft             6tisch-6top-coapie                  July 2015


   rpc softcell-negotiation {
      input {
            leaf Opcode {
               type enumeration {
                  enum RESERVATION;
                  enum REMOVE;
               }
            }
            leaf RequiredBW {
               type uint8;
            }
            leaf SlotframeID {
               type uint8;
           }
           leaf TrackID {
               type uint16;
               description
               "TrackID points to a tuple(TrackOwnerAddr,
               InstanceID)";
           }
           leaf NumofCandidate {
               type uint8;
           }
           List CandidateList {
               key "SlotOffset ChannelOffset";
               leaf SlotOffset{
                  type uint16;
               }
               leaf ChannelOffset{
                  type uint16;
               }
           }
      }
      output {
         leaf NumOfCells {
            type uint8;
         }
         List ResultedCells {
            key "SlotOffset ChannelOffset";
            leaf SlotOffset{
               type uint16;
            }
            leaf ChannelOffset{
               type uint16;
            }
         }
      }
   }



Wang, et al.             Expires January 3, 2016                [Page 6]

Internet-Draft             6tisch-6top-coapie                  July 2015


4.  CoAP support

4.1.  URI setting

         Uri-Host option = target node address;

         Uri-Path option = 6t/6/[6top resource name], or 6t/4/[15.4
         resource name], or 6t/e/[extension resource name], where [6top
         resource name] refers to the data resources or RPC defined by
         6top, [15.4 resource name] refers to the data resources defined
         by IEEE802.15.4, and [extension resource name] refers to the
         data resources defined by an extensions of 6top, e.g.  OTF.
         [6top resource name] , [154 resource name] and [extension
         resource name] are RECOMMENDED to be at most 2 bytes long.

4.2.  CoAP Block option

   In [I-D.ietf-core-block], two block options (Block1 and Block2) are
   defined to support block-wise transfers.  The format of a fragmented
   message in a CoAP IE is defined as follows.

   Format of CoAP IE content with fragmented message.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   CoAP IE header              |Ver| T |  TKL  |   Code        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message ID                   |    Token                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Uri-path option                                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |option |option | option delta  |  NUM                  |M| SZX |
   | delta |length |  extended     |                       | |     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   11111111    |                                               |
   +++++++++++++++++                                               |
   //                                                              //
   |                 fragmented payload (64B)                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 3

   Per [I-D.ietf-core-block], the option Delta is 23 for Block1 and 27
   for Block2.  Related sub-fields are defined as follows.

   o  Option delta: 4bits, set to 13, indicates an 8-bit unsigned
      integer follows the initial byte and the Option Delta minus 13.



Wang, et al.             Expires January 3, 2016                [Page 7]

Internet-Draft             6tisch-6top-coapie                  July 2015


   o  Option length: 4bits, set to 2.

   o  Option delta extended: 8bits, 23-13=10 and 27-13=14 for Block1 and
      Block2, respectively.

   Per [IEEE802154], assuming the IE size constraint is 81 bytes, the
   related fields of the block option are defined as follows.

   o  The size of the block (SZX): 3 bits, representing block size
      16B/32B/64B/128B/256B/512B/1024B.  Considering the IE size
      constrained by [IEEE802154], 16B/32B/64B block size will be used.
      Invalid block size values will cause the packet to be dropped
      quietly.

   o  Whether more blocks are following (M): 1 bit;

   o  The relative number of the block (NUM): 12 bits, within a sequence
      of blocks with the given size.  NUM is 4bits or 12bits, or 20bits

4.3.  Management Interface Protocol

   Management and MIB handling is handled by the protocol specification
   defined in [I-D.ietf-6tisch-coap].

4.4.  Negotiation interface protocol

   The negotiation protocol is used by neighbor nodes to agree at what
   slotOffset/channelOffset to add/remove sotfcells.  It uses a Uri-Path
   option to identify the target resource (i.e the negotiation interface
   of the neighbor).

   The example below illustrates the use of this negotiation interface.
   It assumes the RPC softcell-negotiation is at Uri-Path "6t/6/ng".


















Wang, et al.             Expires January 3, 2016                [Page 8]

Internet-Draft             6tisch-6top-coapie                  July 2015


   nodeA   nodeB
     |       |
     +------>| IEEE802.15.4e type: DATA
     | POST  |        CoAP Header: POST (T=CON)
     |       |           Uri-Path: "6t/6/ng"
     |       |            Payload: CBOR(
     |       |                        Opcode=RESERVATION,
     |       |                        RequiredBW,
     |       |                        SlotframeID,
     |       |                        TrackID,
     |       |                        NumOfCandidate,
     |       |                        CandidateList
     |       |                     )
     |       |
     |<------+ IEEE802.15.4e type: ACK
     |       |
     |<------+ IEEE802.15.4e type: DATA
     | 2.04  |        CoAP Header: 2.04 Changed (T=ACK, Code=2.04)
     |       |            Payload: CBOR(
     |       |                        NumOfCells,
     |       |                        ResultedCells
     |       |                     )
     |       |
     +-------> IEEE802.15.4e type: ACK
     |       |

   Node A send a CoAP POST request, using a confirmable message.  Node B
   sends back a IEEE802.15.4e ACK to confirm reception.  This layer 2
   ACK does not give any indication about the correct handling of the
   command, or even about whether this command is well formatted and
   understood.  Node B parses the CoAP IE, and if correct, calls the
   appropriate 6top command to allocate softcells.  When the allocation
   is done, node B sends back a CoAP Response with the appropriate
   return code to node A as a IEEE802.15.4e data packet.  The CoAP ACK
   MUST be piggybacked on the Response.

4.5.  Acknowledgement

   For both non-fragmented CoAP message and fragmented CoAP message, an
   Acknowledgement message of CoAP is used.  The Acknowledgement message
   of CoAP is inserted into a CoAP IE, which is carried in the Data
   Frame or Enhanced Acknowledgement frame of [IEEE802154e].

4.6.  Observe

   The Observe mechanism is a option for 6top-to-6top communication.
   The Token in the CoAP message is used to bind Observe message and its
   Response messages.



Wang, et al.             Expires January 3, 2016                [Page 9]

Internet-Draft             6tisch-6top-coapie                  July 2015


5.  Implementation Considerations

   Similar to the formatting and the parser modules used by CoAP (Layer
   5), a CoAP formatting and parser modules are present in the 6top
   sublayer.

   +-----------------------------------+
   | PCEP | CoAP |      | 6LoWPAN |    |
   | PCC  | DTLS | PANA |    ND   |RPL |
   +------------------------------------------+
   | TCP  |     UDP     |     ICMP     | RSVP |
   +------------------------------------------+
   |                 IPv6                     |
   +------------------------------------------+
   |               6LoWPAN HC                 |
   +------------------------------------------+
   | +--------------+      +----------------+ |
   | |  CoAP Parser |      | CoAP Formatting| |
   | +--------------+      +----------------+ |
   | +--------------+      +----------------+ |
   | | IE Parser    |      |  IE Formatting | |
   | +--------------+      +----------------+ |
   +------------------------------------------+
   |          IEEE802.15.4e TSCH              |
   +------------------------------------------+
   |             IEEE802.15.4                 |
   +------------------------------------------+

                                 Figure 4

   When the IE parser identifies a CoAP IE in the data packet, it passes
   the IE content (i.e. the fragmented CoAP message) to the CoAP Parser.
   The CoAP Parser then assembles those fragmented CoAP messages, and
   takes the appropriate action based on the CoAP Code, Uri-Path, and
   payload.

   When a CoAP message is formatted, it MAY be fragmented, then passed
   to the IE Formatting module.  The IE Formatting module puts those
   (possibly fragmented) CoAP message(s) into a CoAP IE and pases them
   to the IEEE802.15.4e TSCH layer as separate packets.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Wang, et al.             Expires January 3, 2016               [Page 10]

Internet-Draft             6tisch-6top-coapie                  July 2015


6.2.  Informative References

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

   [I-D.ietf-core-block]
              Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",
              draft-ietf-core-block-17 (work in progress), March 2015.

   [I-D.ietf-6tisch-tsch]
              Watteyne, T., Palattella, M., and L. Grieco, "Using
              IEEE802.15.4e TSCH in an IoT context: Overview, Problem
              Statement and Goals", draft-ietf-6tisch-tsch-06 (work in
              progress), March 2015.

   [I-D.ietf-6tisch-architecture]
              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work
              in progress), May 2015.

   [I-D.ietf-6tisch-terminology]
              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terminology in IPv6 over the TSCH mode of IEEE
              802.15.4e", draft-ietf-6tisch-terminology-04 (work in
              progress), March 2015.

   [I-D.ietf-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", draft-ietf-6tisch-minimal-10 (work in
              progress), June 2015.

   [I-D.ietf-6tisch-6top-interface]
              Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
              Operation Sublayer (6top) Interface", draft-ietf-6tisch-
              6top-interface-03 (work in progress), March 2015.

   [I-D.ietf-6tisch-coap]
              Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
              Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
              in progress), March 2015.







Wang, et al.             Expires January 3, 2016               [Page 11]

Internet-Draft             6tisch-6top-coapie                  July 2015


   [I-D.wang-6tisch-6top-sublayer]
              Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
              Operation Sublayer (6top)", draft-wang-6tisch-6top-
              sublayer-01 (work in progress), July 2014.

6.3.  External Informative References

   [IEEE802154e]
              IEEE standard for Information Technology, "IEEE std.
              802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
              Networks (LR-WPANs) Amendment 1: MAC sublayer", April
              2012.

   [IEEE802154]
              IEEE standard for Information Technology, "IEEE std.
              802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications for Low-Rate
              Wireless Personal Area Networks", June 2011.

   [OpenWSN]  Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
              Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
              a Standards-Based Low-Power Wireless Development
              Environment", Transactions on Emerging Telecommunications
              Technologies , August 2012.

   [morell04label]
              Morell, A., Vilajosana, X., Lopez-Vicario, J., and T.
              Watteyne, "Label Switching over IEEE802.15.4e Networks.
              Transactions on Emerging Telecommunications Technologies",
              June 2013.

Authors' Addresses

   Qin Wang (editor)
   Univ. of Sci. and Tech. Beijing
   30 Xueyuan Road
   Beijing, Hebei  100083
   China

   Phone: +86 (10) 6233 4781
   Email: wangqin@ies.ustb.edu.cn










Wang, et al.             Expires January 3, 2016               [Page 12]

Internet-Draft             6tisch-6top-coapie                  July 2015


   Xavier Vilajosana
   Universitat Oberta de Catalunya
   156 Rambla Poblenou
   Barcelona, Catalonia  08018
   Spain

   Phone: +34 (646) 633 681
   Email: xvilajosana@uoc.edu


   Thomas Watteyne
   Linear Technology
   30695 Huntwood Avenue
   Hayward, CA  94544
   USA

   Phone: +1 (510) 400-2978
   Email: twatteyne@linear.com


   Raghuram S Sudhaakar
   Cisco Systems, Inc
   Building 24
   510 McCarthy Blvd
   San Jose  95135
   USA

   Phone: +1 408 853 0844
   Email: rsudhaak@cisco.com


   Pouria Zand
   University of Twente
   Department of Computer Science
   Zilverling Building
   Enschede  7522 NB
   The Netherlands

   Phone: +31 619040718
   Email: p.zand@utwente.nl











Wang, et al.             Expires January 3, 2016               [Page 13]