Network Working Group                                            G. Zorn
Internet-Draft                                               Network Zen
Intended status: Standards Track                               R. Schott
Expires: December 2, 2011                               Deutsche Telekom
                                                                   Q. Wu
                                                                R. Huang
                                                                  Huawei
                                                            May 31, 2011


       RTCP XR for Application Layer Statistics Metrics Reporting
                 draft-zorn-xrblock-rtcp-xr-al-stat-01

Abstract

   This document defines an RTCP XR Report Block and associated SDP
   parameters that allows the reporting of application layer summary,
   loss discard and burst metrics for use in a range of RTP
   applications.

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 December 2, 2011.

Copyright Notice

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



Zorn, et al.            Expires December 2, 2011                [Page 1]


Internet-Draft     Application Layer Statistics Blocks          May 2011


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Standards Language . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Application Layer Metrics  . . . . . . . . . . . . . . . . . .  3
     4.1.  Application Layer Statistics Summary Report Block  . . . .  4
     4.2.  Application Layer Loss and Discard Metrics Block . . . . .  6
     4.3.  Application Layer Burst Metrics Block  . . . . . . . . . .  8
   5.  SDP Signaling  . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13















Zorn, et al.            Expires December 2, 2011                [Page 2]


Internet-Draft     Application Layer Statistics Blocks          May 2011


1.  Introduction

   RFC 3611 [RFC3611] defines seven report block formats for network
   management and quality monitoring.  However, some of these metrics
   are mostly for multicast inference of network characteristics (MINC)
   or voice over IP (VoIP) monitoring and not widely applicable to other
   applications, e.g., video quality monitoring.  This document focuses
   on specifying new additional report block types used to convey video
   related parameters at application layer that are generically designed
   for use in audio and video services.

   The metrics belong to the class of application layer metrics defined
   in [MONARCH] (work in progress).


2.  Terminology

2.1.  Standards Language

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

   In addition, the following terms are defined:

   Picture Type

      Picture types used in the different video algorithms compose of
      the key-frame and the Derivation frame.  Key-frame is also called
      a reference frame and used as a reference for predicting other
      pictures.  It is coded without prediction from other pictures.
      The Derivation frame is derived from Key-frame using prediction
      from the reference frame.



3.  Applicability

   The Metric Block defined in this document can be applied to any real
   time applications that convey video related parameters at application
   layer.


4.  Application Layer Metrics







Zorn, et al.            Expires December 2, 2011                [Page 3]


Internet-Draft     Application Layer Statistics Blocks          May 2011


4.1.  Application Layer Statistics Summary Report Block

   This block reports statistics beyond the information carried in the
   Statistics Summary Report Block RTCP packet specified in the section
   4.6 of RFC 3611 [RFC3611].  Information is recorded about lost frames
   ,duplicated frames, lost partial frames.  Such information can be
   useful for network management and video quality monitoring.

   The Application Layer Statistics Summary Report Block has the
   following 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     BT=TBD    |  rsd. |T|P|rsd|        block length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          begin_seq            |             end_seq           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Number of frames expected                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      lost_full_frames                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          dup_frames                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      lost_partial_frames                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Block type (BT): 8 bits

      The Application Layer Statistics Summary Report Block is
      identified by the constant <ALSS>.

   Rsd.: 4 bits

      This field is reserved for future definition.  In the absence of
      such a definition, the bits in this field MUST be set to zero and
      MUST be ignored by the receiver.

   Picture type indicator (T): 1 bit

      Picture types used in the different video algorithms compose of
      key-frame and derivation frame.  This field is used to indicate
      the frame type to be reported.  Bits set to 0 if the lost_frames
      field or dup_frames field contain a key_frame report or reference
      frame report, 1 if the lost_frames field and dup_frames field
      contain other derivation frame report.





Zorn, et al.            Expires December 2, 2011                [Page 4]


Internet-Draft     Application Layer Statistics Blocks          May 2011


   P: 1 bit

      Bit set to 1 if the partial_lost_frames field or the partial_dup_
      frames field contains a report, 0 otherwise.

   Rsd.: 2 bits

      This field is reserved for future definition.  In the absence of
      such a definition, the bits in this field MUST be set to zero and
      MUST be ignored by the receiver.

   Block length: 16 bits

      The constant 5, in accordance with the definition of this field in
      Section 3 of RFC 3611 [RFC3611].

   begin_seq: 16 bits

      As defined in Section 4.1 of RFC 3611 [RFC3611].

   end_seq: 16 bits

      As defined in Section 4.1 of RFC 3611 [RFC3611].

   number of frames expected:32bits

      A count of the number of frames expected, estimated if necessary.
      If no frames have been received then this count shall be set to
      Zero.

   lost_full_frames: 32 bits

      If one frame is completely lost, this frame is regarded as one
      lost full_frame.  The lost_full_frames is equivalent to the number
      of lost_full_frames in the above sequence number interval.

   dup_frames: 32 bits

      Number of dup_frames in the above sequence number interval.

   lost_partial_frames: 32 bits

      If one frame is partially lost, this frame is regarded as one lost
      fractional frame.  The lost_partial_frames is equivalent to the
      number of lost_partial_frames in the above sequence number
      interval.





Zorn, et al.            Expires December 2, 2011                [Page 5]


Internet-Draft     Application Layer Statistics Blocks          May 2011


4.2.  Application Layer Loss and Discard Metrics Block

   A frame shall be regarded as lost if it fails to arrive within an
   implementation-specific time window.  A frame that arrives within
   this time window but is too early or late to be played out shall be
   regarded as discarded.  A frame shall be classified as one of
   received (or OK), discarded or lost.


   This block reports Loss and Discard metrics statistics beyond the
   information carried in the standard RTCP packet format.  The block
   reports separately on packets lost on the IP channel, and those that
   have been received but then discarded by the receiving jitter buffer.

   It is very useful to distinguish between frames lost by the network
   and those discarded due to jitter.  Both have equal effect on the
   quality of the video stream, however, having separate counts helps
   identify the source of quality degradation.  These fields MUST be
   populated, and MUST be set to zero if no frames have been received.

   The Loss and Discard metrics are determined after the effects of FEC,
   redundancy (RFC2198) or other similar process.  Implementations MUST
   provide values for all the fields defined here.  For certain metrics,
   if the value is undefined or unknown, then the specified default or
   unknown field value MUST be provided.

   The block is encoded as six 32-bit words:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     BT=TBD    |I| rsv |T| rsv.|        block length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Frame Loss rate        |     Frame Discard rate        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   block type (BT): 8 bits

      A Application Layer Metrics Report Block is identified by the
      constant <ALLDM>.

   Interval Metric flag (I): 1 bit

      This field is used to indicate whether the metrics block is an
      Interval or a Cumulative report,






Zorn, et al.            Expires December 2, 2011                [Page 6]


Internet-Draft     Application Layer Statistics Blocks          May 2011


   reserved: 3 bits

      This field is reserved for future definition.  In the absence of
      such a definition, the bits in this field MUST be set to zero and
      MUST be ignored by the receiver.

   Picture type indicator (T): 1 bit

      Picture types used in the different video algorithms compose of
      key-frame and derivation frame.  This field is used to indicate
      the picture type to be reported.  Bits set to 0 if the Loss rate
      field and discard rate field contain a Key_frame report or
      reference frame report, 1 if the Loss rate field and discard rate
      field contain other derivation frame reports.

   reserved: 3 bits

      This field is reserved for future definition.  In the absence of
      such a definition, the bits in this field MUST be set to zero and
      MUST be ignored by the receiver.

   block length: 16 bits

      The constant 1, in accordance with the definition of this field in
      Section 3 of RFC 3611 [RFC3611].

   Frame Loss rate: 8 bits

      The proportion of frames lost since the beginning of reception,
      expressed as a fixed point number with the binary point at the
      left edge of the field.  This value is calculated by dividing the
      total number of lost frames containing specified frame (e.g., Key
      frame) (after the effects of applying any error protection such as
      FEC) by the total number of frames expected, multiplying the
      result of the division by 256, limiting the maximum value to 255
      (to avoid overflow), and taking the integer part.  The numbers of
      duplicated frames and discarded frames do not enter into this
      calculation.  Since receivers cannot be required to maintain
      unlimited buffers, a receiver MAY categorize late-arriving frames
      as lost.  The degree of lateness that triggers a loss SHOULD be
      significantly greater than that which triggers a discard.

   Frame Discard rate: 8 bits

      The proportion of frames discarded since the beginning of
      reception, due to late or early arrival, under-run or overflow at
      the receiving jitter buffer.  This value is expressed as a fixed
      point number with the binary point at the left edge of the field.



Zorn, et al.            Expires December 2, 2011                [Page 7]


Internet-Draft     Application Layer Statistics Blocks          May 2011


      It is calculated by dividing the total number of discarded frames
      containing specified frame (e.g., Key Frame) (excluding duplicate
      frames discards) by the total number of frames expected,
      multiplying the result of the division by 256, limiting the
      maximum value to 255 (to avoid overflow), and taking the integer
      part.


4.3.  Application Layer Burst Metrics Block

   This block reports Burst metrics statistics beyond the information
   carried in the standard RTCP packet format.  It reports on the
   combined effect of losses and discards, as both have equal effect on
   video quality.

   In order to properly assess the quality of a video stream, it is
   desirable to consider the degree of burstiness of packet loss RFC
   3357 [RFC3357].  Following the one-way loss pattern sample metrics
   discussed in [RFC3357], a measure of the spacing between consecutive
   network packet loss or error events, is a "loss distance".  The loss
   distance metric captures the spacing between the loss periods.  The
   duration of a loss or error event (e.g. and how many packets are lost
   in that duration) is a "loss period", the loss period metric captures
   the frequency and length (burstiness) of loss once it starts.  Delay
   reports include the transit delay between RTP end points and the end
   system processing delays, both of which contribute to the user
   perceived delay.

   Implementations MUST provide values for all the fields defined here.
   For certain metrics, if the value is undefined or unknown, then the
   specified default or unknown field value MUST be provided.

   The block is encoded as three 32-bit words:

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     BT=TBD    |I|     Rsv.    |        block length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Loss Distance        |          Loss Period          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Threshold            |           Reserved.           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Zorn, et al.            Expires December 2, 2011                [Page 8]


Internet-Draft     Application Layer Statistics Blocks          May 2011


   block type (BT): 8 bits

      Appliation Layer Metrics Report Block is identified by the
      constant <ALBM>.

   reserved: 8 bits

      This field is reserved for future definition.  In the absence of
      such a definition, the bits in this field MUST be set to zero and
      MUST be ignored by the receiver.

   Interval Metric flag (I): 1 bit

      This field is used to indicate whether the metrics block is an
      Interval or a Cumulative report,

   reserved: 7 bits

      This field is reserved for future definition.  In the absence of
      such a definition, the bits in this field MUST be set to zero and
      MUST be ignored by the receiver.

   block length: 16 bits

      The constant 2, in accordance with the definition of this field in
      Section 3 of RFC 3611 [RFC3611].

   Loss Period: 16 bits

      The average duration of a burst of lost and discarded frames.  The
      mean duration, expressed in milliseconds, of the loss intervals
      that have occurred since the beginning of reception [DSLF].  The
      duration of each loss period is calculated based upon the frame
      packets that mark the beginning and end of that period.  It is
      equal to the timestamp of the end frame, plus the duration of the
      end frame, minus the timestamp of the beginning frame.  If the
      actual values are not available, estimated values MUST be used.
      If there have been no burst periods, the burst duration value MUST
      be zero.

   Loss Distance: 16 bits

      The average duration of periods between bursts.  The mean
      duration, expressed in milliseconds, of the gap periods that have
      occurred since the beginning of reception [DSLF].  The duration of
      each period is calculated based upon the frame packets that marks
      the end of the prior burst and the frame packet that marks the
      beginning of the subsequent burst.  It is equal to the timestamp



Zorn, et al.            Expires December 2, 2011                [Page 9]


Internet-Draft     Application Layer Statistics Blocks          May 2011


      of the subsequent burst frame packet, minus the timestamp of the
      prior burst frame packet, plus the duration of the prior burst
      frame packet.  If the actual values are not available, estimated
      values MUST be used.  In the case of a gap that occurs at the
      beginning of reception, the sum of the timestamp of the prior
      burst packet and the duration of the prior burst packet are
      replaced by the reception start time.  In the case of a gap that
      occurs at the end of reception, the timestamp of the subsequent
      burst packet is replaced by the reception end time.  If there have
      been no gap periods, the gap duration value MUST be zero.

   Threshold: 16 bits

      The maximum duration, expressed in milliseconds, of the loss
      distance that have occurred since the beginning of reception.

   Reserved: 16 bits

      All bits SHALL be set to 0 by the sender and SHALL be ignored on
      reception.

   block length: 16 bits

      The constant 2, in accordance with the definition of this field in
      Section 3 of RFC 3611 [RFC3611].



5.  SDP Signaling

   Three new parameter is defined for the six report blocks defined in
   this document to be used with Session Description Protocol (SDP)
   [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234].
   They have the following syntax within the "rtcp-xr" attribute
   [RFC3611]:
















Zorn, et al.            Expires December 2, 2011               [Page 10]


Internet-Draft     Application Layer Statistics Blocks          May 2011


     rtcp-xr-attrib =  "a=rtcp-xr:"
                       [xr-format *(SP xr-format)] CRLF
           xr-format =
                       / application-loss-metrics
                       / application-burst-metrics
                       / application-stat-summary

   application-burst-metrics = " application-burst-metrics"
                                 ["=" max-size]
         max-size = 1*DIGIT ; maximum block size in octets

   application--loss-metrics = " application-loss-metrics"
                          ["=" stat-flag *("," stat-flag)]
            stat-flag = "key Frame loss and duplication"
                           / "derivation Frame loss and duplication"

   application-stat-summary = "application-stat-summary"
                         ["=" stat-flag *("," stat-flag)]
               stat-flag = "key Frame loss and duplication"
                      / "derivation Frame loss and duplication"

   Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description
   and the full syntax of the "rtcp-xr" attribute.


6.  IANA Considerations

   New report block types for RTCP XR are subject to IANA registration.
   For general guidelines on IANA allocations for RTCP XR, refer to
   Section 6.2 of [RFC3611].

   This document assigns three new block type value in the RTCP XR Block
   Type Registry:


         Name:       ALSS
         Long Name:  Application Layer Statistics Summary
         Value       <ALSS>
         Reference:  Section 4.1

         Name:       ALLDM
         Long Name:  Application Layer Loss and Discard Metrics
         Value       <ALLDM>
         Reference:  Section 4.2







Zorn, et al.            Expires December 2, 2011               [Page 11]


Internet-Draft     Application Layer Statistics Blocks          May 2011


         Name:       ALBM
         Long Name:  Application Layer Burst Metrics
         Value       <ALBM>
         Reference:  Section 4.3
   This document also registers three new SDP [RFC4566] parameters for
   the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry:

      *  "application-layer-loss-metrics"
      *  "application-layer -burst-metrics"
      *  "application-layer -stat-summary"

   The contact information for the registrations is:

                     Glen Zorn
                     Network Zen
                     77/440 Soi Phoomjit, Rama IV Road
                     Phra Khanong, Khlong Toie
                     Bangkok  10110
                     Thailand


7.  Security Considerations

   The new RTCP XR report blocks proposed in this document introduces no
   new security considerations beyond those described in [RFC3611].


8.  Acknowledgements

   The authors would like to thank Bill Ver Steeg, David R Oran, Ali
   Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang
   Hu for their valuable comments and suggestions on this document.


9.  References

9.1.  Normative References

   [I-D.ietf-avt-rtp-svc]
              Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
              "RTP Payload Format for Scalable Video Coding",
              draft-ietf-avt-rtp-svc-27 (work in progress),
              February 2011.

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

   [RFC2250]  Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar,



Zorn, et al.            Expires December 2, 2011               [Page 12]


Internet-Draft     Application Layer Statistics Blocks          May 2011


              "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250,
              January 1998.

   [RFC3357]  Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
              Metrics", RFC 3357, August 2002.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611,
              November 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

9.2.  Informative References

   [DSLF]     Rahrer, T., Ed., Fiandra, Ed., and Wright, Ed., "Triple-
              play Services Quality of Experience (QoE) Requirements",
              DSL Forum Technical Report TR-126, December 2006.

   [MEASIDENT]
              Hunt, G. and A. Clark, "RTCP XR Measurement Identifier
              Block", ID draft-ietf-avt-rtcp-xr-meas-identity-02,
              May 2009.

   [MONARCH]  Wu, Q., "Monitoring Architectures for RTP",
              ID draft-ietf-avtcore-monarch-00, April 2011.

   [PMOL]     Clark, A., "Framework for Performance Metric Development",
              ID draft-ietf-pmol-metrics-framework-08, January 2011.


Appendix A.  Change Log

   This document is separated from
   draft-wu-xrblock-rtcp-xr-quality-monitoring-01 with a few editorial
   changes and focuses on application layer summary, loss, discard, and
   burst metrics.







Zorn, et al.            Expires December 2, 2011               [Page 13]


Internet-Draft     Application Layer Statistics Blocks          May 2011


Authors' Addresses

   Glen Zorn
   Network Zen
   77/440 Soi Phoomjit, Rama IV Road
   Phra Khanong, Khlong Toie
   Bangkok  10110
   Thailand

   Phone: +66 (0) 87 502 4274
   Email: gwz@net-zen.net


   Roland Schott
   Deutsche Telekom
   Deutsche-Telekom-Allee 7
   Darmstadt  64295
   Germany

   Email: Roland.Schott@telekom.de


   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: sunseawq@huawei.com


   Rachel Huang
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing  210012
   China

   Email: Rachel@huawei.com













Zorn, et al.            Expires December 2, 2011               [Page 14]