Skip to main content

Differentiated Service Class Recommendations for LLN Traffic
draft-svshah-lln-diffserv-recommendations-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Shitanshu Shah , Pascal Thubert
Last updated 2012-07-03
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-svshah-lln-diffserv-recommendations-00
Network Working Group                                            S. Shah
Internet-Draft                                                P. Thubert
Intended status: Informational                             Cisco Systems
Expires: January 4, 2013                                    July 3, 2012

      Differentiated Service Class Recommendations for LLN Traffic
              draft-svshah-lln-diffserv-recommendations-00

Abstract

   Differentiated services architecture is widely deployed in
   traditional networks.  There exist well defined recommendations for
   the use of appropriate differentiated service classes for different
   types of traffic (eg. audio, video) in these networks.  Per-Hop
   Behaviors are typically defined based on this recommendations.  With
   emerging Low-power and Lossy Networks (LLNs), traffic originated in a
   LLN, such as metering, command and control, may transit over a
   converged campus IP network, or even a Wide Area Network, and will
   share resources with traditional classes of traffic such as voice,
   video and data.  It is important to have defined differentiated
   services recommendations for LLN traffic to co-exist with traditional
   class of traffic.

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 4, 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

Shah & Thubert           Expires January 4, 2013                [Page 1]
Internet-Draft          Diffserv for LLN traffic               July 2012

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Shah & Thubert           Expires January 4, 2013                [Page 2]
Internet-Draft          Diffserv for LLN traffic               July 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Application Types and Traffic Patterns . . . . . . . . . . . .  5
     3.1.  Alert signals  . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Control signals  . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Monitoring data  . . . . . . . . . . . . . . . . . . . . .  7
       3.3.1.  Video data . . . . . . . . . . . . . . . . . . . . . .  7
       3.3.2.  Query based data . . . . . . . . . . . . . . . . . . .  8
       3.3.3.  Periodic reporting/logging, Software downloads . . . .  8
     3.4.  Traffic Class Characteristics Table  . . . . . . . . . . .  9
   4.  Differentiated Service recommendations for LLN traffic . . . .  9
     4.1.  Alert signals  . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Control signals  . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Monitoring Data  . . . . . . . . . . . . . . . . . . . . . 10
       4.3.1.  Video Data . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.2.  Query based data . . . . . . . . . . . . . . . . . . . 10
       4.3.3.  Periodic reporting/logging, Software downloads . . . . 10
     4.4.  Summary of Differentiated Code-points and QoS
           Mechanics for them . . . . . . . . . . . . . . . . . . . . 11
   5.  Deployment Scenario  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Shah & Thubert           Expires January 4, 2013                [Page 3]
Internet-Draft          Diffserv for LLN traffic               July 2012

1.  Introduction

   With emerged LLNs, it is anticipated that more and more such networks
   will be connected to existing Campus, WANs, Provider core networks.
   As deployments of LLNs grow, traffic out of such Networks will also
   grow which is to co-exist with traditional types of traffic.  Per-Hop
   Behaviors (PHB) and Inter-domain Service Level Agreements (SLAs), not
   only at the LLN Border but also in the managed IP networks, will have
   to be defined considering all types of traffic.

   We will first categorize different types of LLN traffic into service
   classes and then provide recommendations for Differentiated Service
   Code-Point(DSCP) for those service classes.  Mechanisms to be used,
   like Traffic Conditioning and Active Queue Management, for
   differentiated services is well defined in RFC4594.  This document
   does not focus to re-call them again here but the document will call
   out any specific mechanism that requires particular consideration.
   Though nodes inside LLNs MAY use code-points recommended here.

   This document focuses on Diffserv recommendations for LLN class of
   traffic in managed IP networks outside of LLNs that is for the
   traffic from LLN to the Campus, WAN, Provider Core as well as for the
   traffic in the reverse direction.  It does not focus on Diffserv
   architecture or any other QoS recommendations within the LLNs.  Given
   constraints of LLNs and their unique requirements, it is expected of
   a focus within a separate efforts.

   In Section 3 we categorize different types of traffic from Different
   LLNs.  Section 4 recommends differentiated services, including DSCPs
   and QoS mechanics, for categorized classes of traffic.  Section 5
   evaluates one of the deployment scenario.

Shah & Thubert           Expires January 4, 2013                [Page 4]
Internet-Draft          Diffserv for LLN traffic               July 2012

1.1.  Definitions

    DSCP: Differentiated Service Code Point. It is a 6-bits value in the
          TOS and Traffic Class field of the IPv4 and IPv6 header
          respectively. This 6-bits numerical value defines standard set
          of behavior to be performed by Differentiated Services capable
          hops.

    Diffserv
    Class: Diffser Class in this document is used to refer to DSCP code-
           point(s) and associated Per-hop Behaviors for it.

    LLN: Low-power and lossy Network. Network constructed with sensors,
         actuators, routers that are low-power and with higher loss/
         success transmission ratio, due to transmission medium and
         nature of dynamics of changing topology, compare to wired and
         other traditional networks.

    SLA: Service Level Agreement. It is a collection of Traffic
         classification rules and set of services associated with each
         Traffic Class. Traffic classification may be defined based
         on just DSCP code-points or additionally (or otherwise)
         based on some other packet attributes.

    WAN: Wide Area Network. Broader area of network that connects
         multiple LANs, LLNs to each other including LAN, LLN networks
         from different sites across regions.

2.  Terminology

   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.

3.  Application Types and Traffic Patterns

      Different types of traffic can be collapsed into following network
      service classes.

      - Alert signals
      - Critical control signals
      - Monitoring data
        - Video data
        - Query-based response data
        - Periodic reporting/logging, Software downloads

Shah & Thubert           Expires January 4, 2013                [Page 5]
Internet-Draft          Diffserv for LLN traffic               July 2012

3.1.  Alert signals

   Alerts/alarms reporting fall in this category where such signal is
   triggered in a rare un-usual circumstances.  An alert may be
   triggered for an example when environmental hazard level goes beyond
   certain threshold.  Such alerts require to be reported with in the
   human tolerable time.  Note that certain critical alert reporting in
   certain automation systems may be reported via very closely and
   tightly managed method that is not implemented within LLNs, due to
   the nature of transmission media of LLNs and due to the stringent
   latency requirement for those alerts.  Such types of signals are not
   considered here since they are not within the scope of LLN or any
   other IP networks.

Examples :
    - Environmental hazard level goes beyond certain threshold
    - Measured blood pressure exceeds the threshold or a person falls to
      the ground
    - Instructional triggers like start/stop traffic lights during
      certain critical event

Traffic Pattern:

   Typically size of such packets is very small. any specific device of
   LLN is expected to trigger only handful of packets (may be only 1
   packet).  That too only during an event which is not a common
   occurrence.

   In an affected vicinity, only a designated device or each affected
   devices may send alerts.  In certain type of sensor networks, it is
   predictable and expected to have only a designated device to trigger
   such an alert while in certain other types scale number of alert
   flows may be expected.

   Latency required for such traffic is not stringent but is to be
   within human tolerable time bound.

3.2.  Control signals

   Besides alerts, LLNs also trigger and/or receive different types of
   control signals, to/from control applications outside of LLNs.  These
   control signals are important enough for the operation of sensors,
   actuators and underneath network.  Administrator controlling
   applications, outside of LLN network, may trigger a control signal in
   response to alerts/data received from LLN (in some cases control
   signal trigger may be automated without explicit human interaction in
   the loop) or administrator may trigger an explicit control signal for
   a specific function.

Shah & Thubert           Expires January 4, 2013                [Page 6]
Internet-Draft          Diffserv for LLN traffic               July 2012

 Examples:
     - auto [demand] response (e.g. manage peak load, service
                                   disconnect, start/stop street lights)
     - manual remote service disconnect, remote demand reset

     - open-loop regulatory control
     - non-critical close-loop regulatory control
     - trigger to start Video surveillance

 Traffic Pattern:

   Variable size packets but typically size of such packets is small.
   Certain control signals may be regular and so with number of devices
   in a particular LLN, it is predictable on average, how many such
   signals to expect.  However, certain other control signals are
   irregular or on-demand.

   Typically most of the open-loop, that requires manual interaction,
   signals are tolerant to latency above 1 second.  Certain close-loop
   control signals require low jitter and low latency, latency in the
   order of 100s of ms.

   Some of the tightly coupled closed loop control signals are very
   sensitive to latency and jitter.  However they today, just like
   critical alerts, are implemented via other management methods outside
   of LLN.

3.3.  Monitoring data

   Reaction to control signals may initiate flow of data-traffic in
   either direction.  Sensors/Actuators in LLNs may also trigger
   periodic data (eg. monitoring, reporting data).  All different types
   of data may be categorized in following classes.

3.3.1.  Video data

   A very common example of this type of monitoring data is Video
   surveillance or Video feed, triggered thru control signals.  This
   Video feed is typically from LLN towards an application outside of
   LLN.

   Traffic Pattern:

   Video frame size is expected to be big with a flow of variable rate.

Shah & Thubert           Expires January 4, 2013                [Page 7]
Internet-Draft          Diffserv for LLN traffic               July 2012

3.3.2.  Query based data

   Application at the controller, outside the LLN, or user explicitly
   may launch query for the data.  For example, query for an urban
   environmental data, query for health report etc.  Since this data is
   query based data, it is important to report data with reasonable
   latency though not stringent.  In addition, some periodic logging
   data also may require timely reporting and so may expect same type of
   service (eg. at-home health reporting).

   Traffic Pattern:

   Size of packets can vary from small to big.  While rate may be
   predictable in some cases, in most of the cases traffic rate for such
   data is variable.  The traffic is bursty in the nature.

3.3.3.  Periodic reporting/logging, Software downloads

   Many sensors/actuator in different LLNs report data periodically.
   With some exceptions, as mentioned above for healthcare monitoring
   logs, most of such data do not have any latency requirement and can
   be forwarded either thru lower priority assured forwarding or with
   service of store and forward or even best effort.

   Sensors/actuators may require software/firmware upgrades where
   software/ firmware may be downloaded on demand bases.  These upgrades
   and so downloads do not have stringent requirement of timely delivery
   to the accuracy of seconds.  This data also can be forwarded thru
   lower priority assured forwarding.

   Traffic Pattern:

   Periodic reporting/logging typically can be predicated as constant
   rate.  Data may be bursty in the nature.  Software download data also
   may be bursty in nature.  Such traffic is tolerant to jitter and
   latency.

Shah & Thubert           Expires January 4, 2013                [Page 8]
Internet-Draft          Diffserv for LLN traffic               July 2012

3.4.  Traffic Class Characteristics Table

    -------------------------------------------------------------------
   |Traffic Class  |                              |    Tolerance to    |
   |    Name       |  Traffic Characteristics     | Loss |Delay |Jitter|
   |===============+==============================+======+======+======|
   |   Alerts/     |Packet size = small           | Low  |Low   |  N/A |
   |   alarms      |Rate = typically 1-few packets|      |      |      |
   |               |Short lived flow              |      |      |      |
   |               |Burst = not bursty            |      |      |      |
   |---------------+------------------------------+------+------+------|
   |   Control     |Packet size = variable,       | Yes  |Low   |  Yes |
   |   Signals     |              typically small |      |      |      |
   |               |Rate = few packets            |      |      |      |
   |               |Short lived flow              |      |      |      |
   |               |Burst = none to some-what     |      |      |      |
   |---------------+------------------------------+------+------+------|
   |   Very low    |Packet size = variable,       | Low  |Very  |  Low |
   |   latency     |              typically small |      |Low   |      |
   |  close-loop   |Rate = few packets            |      |      |      |
   |   Control     |Short lived flow              |      |      |      |
   |   Signals     |Burst = none to some-what     |      |      |      |
   |---------------+------------------------------+------+------+------|
   |     Video     |Packet size = big             | Low  |Low - |  Low |
   |Monitoring/feed|Rate = variable               |      |Medium|      |
   |               |Long lived flow               |      |      |      |
   |               |Burst = non-bursty            |      |      |      |
   |---------------+------------------------------+------+------+------|
   |  Query-based  |Packet size = variable        | Low  |Medium|  Yes |
   |      Data     |Rate = variable               |      |      |      |
   |               |Short lived elastic flow      |      |      |      |
   |               |Burst = bursty                |      |      |      |
   |---------------+------------------------------+------+------+------|
   |   Periodic    |variable packet size, rate    | Yes  |Medium|  Yes |
   |Reporting/log, |bursty                        |      |- High|      |
   |  Software     |                              |      |      |      |
   |   downloads   |                              |      |      |      |
    -------------------------------------------------------------------

4.  Differentiated Service recommendations for LLN traffic

4.1.  Alert signals

   Alerts/alarms signaling service requires transmission of few packets
   with low delay, tolerable to human.  This requirement is very similar
   to signaling traffic in the traditional networks.  Alert signals MAY
   use Diffserv code-point CS5.

Shah & Thubert           Expires January 4, 2013                [Page 9]
Internet-Draft          Diffserv for LLN traffic               July 2012

4.2.  Control signals

   As described in earlier section, control signals over IP are divided
   in two categories.  Control signals that require very low latency,
   service inline with EF PHB, and control signals that require low
   delay but do not mandate lowest latency.  Service requirement for
   later class of control signals is very similar to service for
   signaling traffic in the traditional networks.  Recommendation for
   this class of control signals is to use Diffserv code-point CS5.

   Control signals, like some of the closed-loop signals, that require
   lower delay and jitter compare to CS5 class of control signals, are
   recommended to use EF Diffserv class.  These control signals are
   expected to be of the small packet size and short-lived flows.
   Specifically while sharing EF class with voice traffic, any big
   control packets can cause additional latency to voice packets and so
   care MUST be taken either to use a different Diffserv class for them
   or compress such packets to smaller size.

4.3.  Monitoring Data

4.3.1.  Video Data

   RFC4594 has well documented recommendations for different types of
   Video traffic.  If there is any Video traffic from/to LLNs to/from
   outside of LLNs, they should use same recommended dscp from RFC4594.
   For example, surveillance video feed is recommended to use dscp CS3.

4.3.2.  Query based data

   Low latency data, like query based report and non-critical signals,
   is recommended to use AF2 assured forwarding service.  Also, certain
   periodic reporting/logging data that are critical to be reported with
   regular interval with relatively low jitter is recommended to use
   AF2x service.

4.3.3.  Periodic reporting/logging, Software downloads

   Non-critical periodic reporting/logging and rest all other data MAY
   use AF1x or BE service class.

Shah & Thubert           Expires January 4, 2013               [Page 10]
Internet-Draft          Diffserv for LLN traffic               July 2012

4.4.  Summary of Differentiated Code-points and QoS Mechanics for them

    - Alert Signals                          CS5

    - Control Signaling                      CS5

    - Lower latency control-signals          EF

    - Video broadcast/feed                   CS3

    - Query-based data                       AF2x

    - Assured monitoring data                AF1x
      high throughput

    - Best Effort monitoring data            BE
      Reporting (periodic reporting.certain types of periodic monitoring
                 MAY require assured forwarding)
     ------------------------------------------------------------------
    |  Service      | DSCP | Conditioning at   |   PHB   | Queuing| AQM|
    |   Class       |      |    DS Edge        |  Used   |        |    |
    |===============+======+===================+=========+========+====|
    | lower latency |  EF  |Police using sr+bs | RFC3246 |Priority| No |
    |control signals|      |Police using sr+bs |         |        |    |
    |---------------+------+-------------------+---------+--------+----|
    |Alert  signals/|      |                   |         |        |    |
    |Control signals| CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
    |---------------+------+-------------------+---------+--------+----|
    |   Video feed  | CS3  |Police using sr+bs | RFC2474 |  Rate  | No |
    |---------------+------+-------------------+---------+--------+----|
    |    Query-     | AF21 | Using single-rate,|         |        | Yes|
    |    based      | AF22 |three-color marker | RFC2597 |  Rate  | per|
    |    Data       | AF23 | (such as RFC 2697)|         |        |DSCP|
    |---------------+------+-------------------+---------+--------+----|
    |  Periodic     | AF11 |  Using two-rate,  |         |        | Yes|
    |  Reporting/   | AF12 |three-color marker | RFC2597 |  Rate  | per|
    |    logging    | AF13 | (such as RFC 2698)|         |        |DSCP|
     ------------------------------------------------------------------
    *  "sr+bs" represents a policing mechanism that provides single rate
       with burst size control [RFC4594]

5.  Deployment Scenario

   Industrial Automation, as described in [RFC5673] and [ISA100.11a],
   classifies different types of traffic in following six classes
   ranging in complexity from Class 5 to Class 0 where Class 0 is the
   most time sensitive class.

Shah & Thubert           Expires January 4, 2013               [Page 11]
Internet-Draft          Diffserv for LLN traffic               July 2012

    o  Safety

      *  Class 0: Emergency action - Always a critical function

    o  Control

      *  Class 1: Closed-loop regulatory control - Often a critical
         function

      *  Class 2: Closed-loop supervisory control - Usually a non-
         critical function

      *  Class 3: Open-loop control - Operator takes action and controls
         the actuator (human in the loop)

   o  Monitoring

      *  Class 4: Alerting - Short-term operational effect (for example,
         event-based maintenance)

      *  Class 5: Logging and downloading / uploading - No immediate
         operational consequence (e.g., history collection, sequence-of-
         events, preventive maintenance)

    It might not be appropriate to transport Class 0 traffic over a
    wireless network or a multihop network, unless tight mechanisms are
    put in place such as TDM and frequency hopping. Today this class of
    traffic is expected to use other tightly managed method outside of
    IP networks. Excluding class 0 traffic, following table maps Class 1
    thru Class 5 service classes to Diffserv code-point.

     -------------------------
    |  Service      | DSCP    |
    |   Class       |         |
    |===============+=========|
    |   Class 1*    | EF      |
    +-------------------------+
    |   Class 2     | CS5     |
    +-------------------------+
    |   Class 3     | CS5     |
    +-------------------------+
    |   Class 4     | AF2x    |
    +-------------------------+
    |   class 5     | AF1x/BE |
    +-------------------------+

    * Any Class 1 traffic that requires very tight control over latency
    and jitter falls in the same category as Class 0 traffic.

Shah & Thubert           Expires January 4, 2013               [Page 12]
Internet-Draft          Diffserv for LLN traffic               July 2012

6.  Security Considerations

   A typical trust model, as much is applicable in traditional networks,
   is applicable with LLN traffic as well.  At the border of the LLN, a
   trust model needs to be established for any traffic coming out of
   LLN.  Without appropriate trust model to accept/mark dscp code-point
   for LLN traffic, misbehaving flow may attack a specific Diffserv
   class disrupting expected service for other traffic from the same
   Diffserv class.  Trust models are typically established at the border
   router by employing rate-limiting and even marking down dscp code-
   point to Best Effort for non-trusted flows or dropping them as
   required.

7.  Acknowledgements

   Thanks to Fred Baker for his valuable comments and suggestions.

8.  References

8.1.  Normative References

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

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              August 2006.

   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
              Diffserv Service Classes", RFC 5127, February 2008.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.

Shah & Thubert           Expires January 4, 2013               [Page 13]
Internet-Draft          Diffserv for LLN traffic               July 2012

8.2.  Informative References

   [ISA100.11a]
              ISA, "ISA-100.11a-2011 - Wireless systems for industrial
              automation: Process control and related applications",
              May 2011.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC6272]  Baker, F. and D. Meyer, "Internet Protocols for the Smart
              Grid", RFC 6272, June 2011.

Authors' Addresses

   Shitanshu Shah
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   US

   Email: svshah@cisco.com

   Pascal Thubert
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Email: pthubert@cisco.com

Shah & Thubert           Expires January 4, 2013               [Page 14]