Internet DRAFT - draft-wang-p2psip-event-notification-extension

draft-wang-p2psip-event-notification-extension



p2psip 
                                                               Jun Wang 
                                                           Zhifeng Chen 
                                                                Yu Meng 
                                                             Jiong Shen 
Internet Draft                                         ZTE Corporation 
Intended status: Informational                             July 2, 2009 
Expires: January 2010 
                                   
 
                    P2PSIP Event Notification Extension 
           draft-wang-p2psip-event-notification-extension-01.txt 


    

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and BCP 79. 

   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. 

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

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on January 2, 2010. 

Copyright Notice 

   Copyright (c) 2009 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 in effect on the date of 
   publication of this document (http://trustee.ietf.org/license-info). 
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 
 
 
 
Wang                  Expires January 2, 2010                [Page 1] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

Abstract 

   The p2p technology is data centric. Data objects are distributed in 
   the p2p overlay according to routing algorithm.Applications access 
   the data objects via peer/client protocol or gateways, some of which 
   need data replicas to be synchronized in real time. This can be 
   achieved by introducing a Subscribe/Notify mechanism to p2psip. This 
   document describes the Subscribe/Notify mechanism extension for 
   p2psip, and also defines several new methods as needed. 

Table of Contents 

    
   1. Introduction................................................3 
   2. Conventions used in this document............................4 
   3. Overview of the Subscriber/Notifier behavior.................5 
      3.1. Subscription model in p2psip............................5 
         3.1.1. Explicit subscription..............................5 
         3.1.2. Implicit subscription..............................6 
      3.2. Subscriber Behavior.....................................7 
         3.2.1. Subscription Duration..............................7 
         3.2.2. Subscription Event.................................7 
         3.2.3. Creating a Subscription............................8 
         3.2.4. Refreshing a Subscription..........................8 
         3.2.5. Canceling a Subscription...........................8 
         3.2.6. Processing Notify messages.........................8 
      3.3. Notifier Behavior.......................................9 
         3.3.1. Processing a Subscribe request.....................9 
         3.3.2. Processing Refreshing request......................9 
         3.3.3. Generating a Notify request........................9 
      3.4. SubscribeGateway Behavior..............................10 
   4. Protocol details...........................................11 
      4.1. Subscribe method.......................................11 
         4.1.1. Request Definition................................11 
         4.1.2. Response Definition...............................12 
      4.2. Notify method.........................................13 
         4.2.1. Request Definition................................13 
         4.2.2. Response Definition...............................15 
      4.3. Implicit subscription extension........................16 
   5. Security Considerations.....................................16 
   6. IANA Considerations........................................16 
   7. References.................................................17 
      7.1. Normative References...................................17 
      7.2. Informative References.................................17 
   8. Acknowledgments............................................17 
    

 
 
Wang                  Expires January 2, 2010                [Page 2] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

1. Introduction 

   Some applications, such as push mail, telecom call server, require 
   the real-time data synchronization between service logic function and 
   data storage function. If the latter is built by p2p technology, the 
   real time data access mechanism must be implemented in the p2p 
   overlay so that any data modification can be conveyed to the 
   application immediately. The Subscribe/Notify mechanism is the best 
   solution for doing this. 

   In the p2psip architecture, considering following scenarios: 

   1. client subscribes the data through indirect conection 

   The subscriber is not a p2p peer node. It connects the p2p overlay 
   via a peer while the target data object is stored in another peer. 
   The protocol used to access the overlay may be a p2p client protocol 
   or other overlay agnostic one, such as diameter, LDAP etc. See Figure 
   1.  

   2. client subscribes the data through direct connection  

   The subscriber is not a p2p peer node. It connects the p2p overlay 
   via a peer which is just the one data object stored. 

   3. peer subscribes the data  

   The subscriber is a normal peer locating in the same overlay with the 
   target data object storing peer. 

                           +------------------+ 
                           |Data-Storage Peer | 
                           +------------------+ 
                                    | 
                                    | 
                           +------------------+ 
                           |   Access Peer    | 
                           +------------------+ 
                                    | 
                                    | 
                           +------------------+ 
                           | Subscriber Client| 
                           +------------------+ 
    
                            Figure 1 Scenario 1 

    
 
 
Wang                  Expires January 2, 2010                [Page 3] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

                           +------------------+ 
                           |Data-Storage Peer | 
                           +------------------+ 
                                    | 
                                    | 
                           +------------------+ 
                           | Subscriber Client| 
                           +------------------+ 
    
                            Figure 2 Scenario 2 

    

                           +------------------+ 
                           |Data-Storage Peer | 
                           +------------------+ 
                                    | 
                                    | 
                           +------------------+ 
                           | Subscriber Peer  | 
                           +------------------+ 
    
                            Figure 3 Scenario 3 

    

2. Conventions used in this document 

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

   In the document we use the terminology and definitions from the 
   following drafts: the Concepts and Terminology for Peer to Peer SIP 
   [I-D.ietf-p2psip-concepts]; REsource LOcation And Discovery (RELOAD) 
   Base Protocol [I-D. draft-ietf-p2psip-base-02]. 

   Other terms used in this document are defined inline when used and 
   are also defined below for reference. 

   Subscribe request: The Subscribe request message is used to request 
             current state and state update of a resource from a remote 
             node. 

   Subscribe response: The Subscribe response message is used to inform 
             the subscriber the result of the Subscribe request. 

 
 
Wang                  Expires January 2, 2010                [Page 4] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

   Notify request:  The Notify request message is used to inform the 
             subscriber of the resource state changes to which has a 
             subscription. 

   Notify response: The Notify response message is used to inform the 
             notifier of the result of the Notify request. 

   Subscription: The Subscription is the action of a Subscriber sending 
             a Subscribe message to a notifier to request current state 
             and state update of a resource. By definition, subscription 
             data exists in both the subscriber and the notifier. 

   Notification: The Notification is the action of a notifier sending a 
             Notify message to a subscriber to inform the subscriber of 
             the state or state update of a resource. 

   Notifier: A Notifier is a peer who generates Notify request for the 
             purpose of notifying subscriber of the state of a resource.  
             Notifier typically also accepts Subscribe request to create 
             a subscription. Typically, notifier is the data-storage 
             peer of the resource. 

   Subscriber: A Subscriber is a node who receives Notify requests from 
             Notifiers. These Notify requests contain information about 
             the state of a resource in which the subscriber is 
             interested. Subscribers typically also generate Subscribe 
             requests and send them to Notifiers to create subscriptions. 

   SubscribeGateway: A SubscribeGateway is a peer which is adjacent to 
             the non-peer subscriber and do protocol translation between 
             p2p peer protocol and other protocols. Accordingly, the 
             SubscribeGateway forwards the Subscribe/Notify messages 
             between Notifiers and Subscribers. 

3. Overview of the Subscriber/Notifier behavior 

3.1. Subscription model in p2psip 

   There are two p2psip subscription models: one model is explicit 
   subscription, the other is implicit subscription. 

3.1.1. Explicit subscription 

   The explicit subscription is created by a Subscribe request and a 
   successful Subscribe response. The subscriber create an explicit 
   subscription by sending Subscribe request to notifier and receiving 
   successful Subscribe response. 
 
 
Wang                  Expires January 2, 2010                [Page 5] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

   The explicit subscription's flow of messages as followed: 

    
              +------------+                   +------------+ 
              | Subscriber |                   |  Notifier  | 
              +-----+------+                   +------+-----+ 
                    |                                 | 
                    |----- F01.Subscribe Request ---->| 
                    |<---- F02.Subscribe Response ----| 
                    |                                 | 
                    |<------ F03.Notify Request ------| 
                    |------ F04.Notify Response ----->| 
                    |                                 | 
                    |<------ F05.Notify Request ------| 
                    |------ F06.Notify Response ----->| 
                    |                                 | 
                    |                                 | 
                                      
                 Figure 4 A flow of explicit subscription 

   In figure4, F01 and F02, explicit Subscribe request and a Subscribe 
   response message create a Subscription, so called the explicit 
   subscription. 

3.1.2. Implicit subscription 

   The implicit subscription is typically established by a non-Subscribe 
   message. Assuming a kind of shared resource exists, one application 
   put a resource into the overlay while the other applications make 
   changes. Each application needs to know the real time state of the 
   resource. Additional explicit Subscribe requests can meet above 
   requirements, but for the performance optimization purpose, the 
   subscriptions should better be carried out by the data manipulation 
   itself in case of excess subscription operations. 

   The figure 5 shows a flow of implicit subscription: 










 
 
Wang                  Expires January 2, 2010                [Page 6] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

              +------------+                   +------------+ 
              | Subscriber |                   |  Notifier  | 
              +-----+------+                   +------+-----+ 
                    |                                 | 
                    |--- F01.non-Subscribe Request -->| 
                    |<-- F02.non-Subscribe Response --| 
                    |                                 | 
                    |<------ F03.Notify Request ------| 
                    |------ F04.Notify Response ----->| 
                    |                                 | 
                    |<------ F05.Notify Request ------| 
                    |------ F06.Notify Response ----->| 
                    |                                 | 
                    |                                 | 
                                      
                 Figure 5 A flow of implicit subscription 

   In the above figure, F01 and F02 build an implicit subscription. 

3.2. Subscriber Behavior 

3.2.1. Subscription Duration 

   The "Expires" parameter in a Subscribe request indicates the lifetime 
   of the subscription. The value set to 0xffffffff indicates that the 
   subscription is always available until the resource deleted or an 
   explicit subscription cancel operation accepted. 

   In order to keep subscriptions effective beyond the duration 
   suggested by the "Expires" value, subscriber needs to refresh the 
   subscription periodically using a new Subscribe request message. 

   The notifier can override the subscription period by putting a new 
   Expires value in the response. The "Expires" value in the Subscribe 
   response could be less than or equal to that specified in the request, 
   but MUST NOT be longer. 

3.2.2. Subscription Event 

   A Subscribe message MUST contain at least one event indicates the  
   events the subscriber concerns. Once one of these events happens, the 
   notifier MUST immediately construct a Notify request and send it to 
   the subscriber. The Notify request SHOULD include the event list 
   triggering itself.  

   After a subscription is established, the subscriber MAY add or remove 
   partial events of the subscription by an update request. 
 
 
Wang                  Expires January 2, 2010                [Page 7] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

3.2.3. Creating a Subscription 

   When a subscriber wishes to Subscribe a particular event of a 
   resource, it generates a Subscribe request. The request MUST contain 
   the following information: a resource id, a subscription id , an 
   "Expires" value, and an event set. 

   The notifier acknowledges the request by a Subscribe response. A 
   Subscribe response indicates that the subscription whether has been 
   accepted, and that a Notify message will be sent immediately. An 
   response with the message code 0xffff indicates that the Subscribe 
   request has been rejected, and no Notify message will be sent. 
   Otherwise, the notifier accepts the request and stores the resource 
   id, subscription id and event list for further processing. 

3.2.4. Refreshing a Subscription 

   Before a subscription expires, the subscriber MAY refresh the 
   subscription duration by sending another Subscribe request which has 
   the same resource id and subscription id with the original one. The 
   handling for such a request is the same as the original one. 

3.2.5. Canceling a Subscription 

   Before a subscription expires, the subscriber MAY cancel the 
   subscription. The cancel request is same with the normal Subscribe 
   request, except the "Expires" value MUST be set to 0. 

3.2.6. Processing Notify messages 

   When receiving a Notify request, the subscriber SHOULD check that:  

   a) Whether the resource id in the request matches at least one of its 
      own subscriptions or not. If not, the subscriber MUST stop 
      checking and return an ERROR response to notifier. 

   b) Whether the subscription id in the request matches at least one of 
      its own subscriptions or not. If not, the subscriber MUST stop 
      checking and return an ERROR response to notifier. 

   c) If the events of the Notify request are not supported, the 
      subscriber SHOULD respond with an ERROR response to notifier. 

   Once all checks passed, the notification is deemed acceptable to the 
   subscriber and the subscriber SHOULD return a successful Notify 
   response. 

 
 
Wang                  Expires January 2, 2010                [Page 8] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

   The "Expires" values presented in Subscribe response behavior is: the 
   Notifier MAY shorten the lifetime of the subscription, but MUST NOT 
   lengthen it. 

3.3. Notifier Behavior 

3.3.1. Processing a Subscribe request 

   When receiving a Subscribe request, the notifier SHOULD check that: 

   a) Whether the resource specified in the request is belong to the 
      notifier or not. If not, the notifier MUST return an ERROR 
      response to indicate that the resource can not be found. 

   b) Whether the events specified in the request is understood or not. 
      If not, the notifier MUST return an ERROR response to indicate 
      that the specified event can not be understood. 

   c) Whether the duration in the "Expires" value is too small small or 
      not. If the expires parameteris larger than zero AND smaller than 
      the minimum that notifier has configured, the notifier MAY return 
      an ERROR response which contains a recommended "min-expires" value. 

   Once all checks passed, the subscription is deemed acceptable to the 
   notifier; and the notifier SHOULD return Subscribe response to the 
   subscriber. 

   If the notifier do not support the permanent subscription expected by 
   a subscriber, it SHOULD set the expires parameter  within the 
   Subscribe response as the maximum value. 

   Upon successfully subscription creating or refreshing operation, a 
   notifier MUST send a Notify message with the current resource state  
   immediately to the subscriber . If the resource has no meaningful 
   state when the Subscribe message is processed, this Notify message 
   MAY contain an empty or neutral body. 

3.3.2. Processing Refreshing request 

   The handling for such a request is the same with  the original 
   creation of a subscription. 

3.3.3. Generating a Notify request 

   After a Subscribe request is accepted and answered by a Subscribe 
   response, the notifier MUST immediately construct and send a Notify 
   request to the subscriber. 
 
 
Wang                  Expires January 2, 2010                [Page 9] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

   Once a subscribed event occurs, the notifier MUST immediately 
   construct and send a Notify request to the subscriber. 

3.4. SubscribeGateway Behavior 

   A subscriber which can not communicate with the notifier directly 
   SHOULD Subscribe to the resource state through a SubscribeGateway. 

   If the subscriber acts as a p2psip client, the SubscribeGateway MAY 
   not store the subscription state and it forwards the Subscribe 
   request and Notify response from Subscriber to Notifier, the 
   Subscribe response and Notify request from Notifier to Subscriber 
   according to the p2p routing rules. 

   If the subscriber accesses the overlay via a protocol other than 
   p2psip , the subscribegateway does protocol translation between the 
   protocol used by subscriber to p2psip. When receiving a Subscribe 
   request from the subscriber, the SubscribeGateway translates non-
   p2psip protocol used by subscriber to p2psip protocol. Similarly, the 
   SubscribeGateway translates Notify request from p2psip to other 
   protocol. The typical flow of messages as followed: 

    
    +------------+          +------------------+          +------------+ 
    | Subscriber |          | SubscribeGateway |          |  Notifier  | 
    +-----+------+          +---------+--------+          +------+-----+ 
          |                           |                          | 
          |- F01.Subscribe Request -->|                          | 
          |                           |- F02.Subscribe Request ->| 
          |                           |<-F03.Subscribe Response -| 
          |<-F04.Subscribe Response --|                          | 
          |                           |<-- F05.Notify Request ---| 
          |<--- F06.Notify Request ---|                          | 
          |-- F07.Notify Response --->|                          | 
          |                           |-- F08.Notify Response -->| 
          |                           |                          | 
          |                           |                          | 
                                      
                    Figure 6 A flow of SubscribeGateway 

    






 
 
Wang                  Expires January 2, 2010               [Page 10] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

4. Protocol details 

4.1. Subscribe method 

   The Subscribe method is used to create a Subscription which used to 
   request current state and state updates of a resource from a remote 
   node. 

4.1.1. Request Definition 

   The Subscribe request message is defined by the SubscribeReq 
   structure as followed: 

 

     struct { 

       Uint32      EventNumber; 

       Uint32      EventId<0...2^8-1>; 

     } EventList; 

   enum EventId { 

     evCreated=1, 

     evModify, 

     evDeleted, 

     evAppSpecificStart=0x8000 

   } 

   This document only defines three basic event type, other documents 
   may introduce more values for EventId. Furthermore, applications can 
   define new value beyond evAppSpecificStart without standardization. 

    

     struct { 

       ResourceId     Resource_id; 

       Unit64        Subscription_id; 

 
 
Wang                  Expires January 2, 2010               [Page 11] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

       Uint32        Expires; 

       EventList      Event; 

       Opaque        Specific_data<0...2^32-1>; 

     } SubscribeReq; 

    

   The contents of the structure are: 

     Resource_id 

         The ID of the resource which is subscribed.  

     Expires 

         The Expiration duration value of the subscription. Expires set 
         to 0xffffffff indicates the subscription always be available. 
         Expires set to 0 indicates the subscription is to be canceled. 

     Subscription_id 

         The ID of the subscription.  

     Event 

         The event list which is subscribed.  

     Specific_data 

         Other opaque data used for the subscription.  

4.1.2. Response Definition 

   The Subscribe response message is defined by the SubscribeAns 
   structure as followed: 

    

     struct { 

       ResourceId     Resource_id; 

       Uint32        Expires; 

 
 
Wang                  Expires January 2, 2010               [Page 12] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

       Unit64        Subscription_id; 

       EventList      Event; 

       Opaque        Specific_data<0...2^32-1>; 

     } SubscribeAns; 

    

   The contents of the SubscribeAns structure are: 

     Resource_id 

         The ID of the resource which is subscribed.  

     Expires 

         The Expiration duration value of the subscription.  

     Subscription_id 

         The ID of the subscription.  

     Event 

         The event list which is subscribed.  

     Specific_data 

         Other opaque data used for the subscription.  

4.2. Notify method 

   The Notify method is used to send current state and state updates for 
   a resource which has been subscribed to the corresponding subscriber. 

4.2.1. Request Definition 

   The Notify request message is defined by the NotifyReq structure as 
   followed: 

 

     enum { 

       Reserved (0), 
 
 
Wang                  Expires January 2, 2010               [Page 13] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

       Active (1), 

       Pending (2), 

       Terminated (3), 

       (255) 

     } SubsrcriptionState; 

    

     struct { 

       ResourceId         Resource_id; 

       Unit64            Subscription_id; 

       SubsrcriptionState    State; 

       ReasonCode         Reason; 

       EventList          Event; 

       Opaque            Specific_data<0...2^32-1>; 

     } NotifyReq; 

    

   The NotifyReq contents of the structure are: 

     Resource_id 

         The ID of the resource which is subscribed.  

     State 

         The state of the subscription.  

         If the value is "Active (1)", it means that the subscription 
         has been accepted by notifier.  

         If the value is "Pending (2)", it means that the subscription 
         has been received by the notifier, but has not enough 
         information to accept or reject the subscription.  

 
 
Wang                  Expires January 2, 2010               [Page 14] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

         If the value is "Terminated (3)", it informs that the 
         subscription is being removed.  

     Reason 

         Used to describe the reason of non-active state.  

     Expires 

         The Expiration duration value of the subscription.  

     Subscription_id 

         The ID of the subscription.  

     Event 

         The event list which is subscribed.  

     Specific_data 

         Other opaque data used for the subscription. 

4.2.2. Response Definition 

   The Notify response message is defined by the NotifyAns structure as 
   followed: 

    

     struct { 

       ResourceId         Resource_id; 

       Unit64            Subscription_id; 

       EventList          Event; 

       Opaque            Specific_data<0...2^32-1>; 

     } NotifyAns; 

    

   The contents of the structure are: 

     Resource_id 
 
 
Wang                  Expires January 2, 2010               [Page 15] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

         The ID of the resource which is subscribed. 

     Subscription_id 

         The ID of the subscription.  

     Event 

         The event list which is subscribed.  

     Specific_data 

         Other opaque data used for the subscription.  

4.3. Implicit subscription extension 

   [notes]TBD 

5. Security Considerations 

   Subscribe operations introduce some extra states be stored in p2p 
   overlay and trigger significant traffic when data modification 
   happens. Malicious nodes can use this extension for DoS attack.To 
   alleviate such risk, the overlay SHOULD reject any unauthorized 
   Subscribe request.    

6. IANA Considerations 

                                      
             +-------------------+----------------+----------+ 
             | Message Code Name |     Code Value |      RFC | 
             +-------------------+----------------+----------+ 
             | Subscribe_req     |             29 | RFC-AAAA | 
             | Subscribe_ans     |             30 | RFC-AAAA | 
             | Notify_req        |             31 | RFC-AAAA | 
             | Notify_ans        |             32 | RFC-AAAA | 
             +-------------------+----------------+----------+ 
    








 
 
Wang                  Expires January 2, 2010               [Page 16] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

    

7. References 

7.1. Normative References 

   [RFC3265] A. B. Roach, "Session Initiation Protocol (SIP)-Specific 
             Event Notification", RFC 3265, June 2002 

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

   [RFC4981]  Risson, J., "Survey of Research towards Robust Peer-to- 

                 Peer Networks: Search Methods", September 2007. 

   [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 
             Baset, S., and H. Schulzrinne, " REsource LOcation And 
             Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-
             02 (work in progress), March 2009. 

7.2. Informative References 

    

8. Acknowledgments 

    














 
 
Wang                  Expires January 2, 2010               [Page 17] 

Internet-Draft     P2PSIP Event Notification Extension     July 2009 
    

Authors' Addresses 

    
   Jun Wang 
   ZTE Corporation 
   No.68, Zijinghua Road 
   Nanjing, Jiangsu province 210012 
   China 
   Email: wang.jun17@zte.com.cn 
    
   Zhifeng Chen 
   ZTE Corporation 
   No.68, Zijinghua Road 
   Nanjing, Jiangsu province 210012 
   China 
   Email: chen.zhifeng@zte.com.cn 
    
   Yu Meng 
   ZTE Corpoporation 
   C1-04,RD Building 1,Zijinghua Road 
   Yuhuatai District,Nanjing 210012 
   P.R.China 
   Phone: +86-025-5287-2045 
   Email: meng.yu@zte.com.cn 
    
   Jiong Shen 
   ZTE Corpoporation 
   4F,RD Building 2,Zijinghua Road 
   Yuhuatai District,Nanjing 210012 
   P.R.China 
   Phone: +86-025-5287-7648 
   Email: shen.jiong@zte.com.cn 
    













 
 
Wang                  Expires January 2, 2010               [Page 18]