Skip to main content

LDP Extensions for Pseudo Wire (PW) Transfer in an MPLS-TP Network
draft-bao-pwe3-pw-transfer-02

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 Qilei Wang , Muliu Tao , Xihua Fu , Ruiquan Jing , Xiaoli Huo
Last updated 2011-12-29 (Latest revision 2011-04-13)
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-bao-pwe3-pw-transfer-02
Network Working Group                                         Qilei Wang
Internet-Draft                                                 Muliu Tao
Intended status: Standards Track                                Xihua Fu
Expires: July 1, 2012                                    ZTE Corporation
                                                            Ruiquan Jing
                                                              Xiaoli Huo
                                                           China Telecom
                                                            Dec 29, 2011

   LDP Extensions for Pseudo Wire (PW) Transfer in an MPLS-TP Network
                   draft-bao-pwe3-pw-transfer-02.txt

Abstract

   As defined in [RFC5654] MPLS-TP transport path includes LSP and PW.
   And the possibility of transferring the ownership and control of an
   existing and in-use path between the management plane and the control
   plane, without actually affecting data plane traffic being carried
   over it, is a valuable option for carrier.  [RFC5493] and [RFC5852]
   describe the LSP transfer.  This memo gives the requirement and LDP
   extensions for PW transfer in an MPLS-TP 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 July 1, 2012.

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

Qilei Wang, et al.        Expires July 1, 2012                  [Page 1]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Comparison with Make-before-Break  . . . . . . . . . . . .  3
     1.2.  Conventions used in this document  . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of the PW Transfer  . . . . . . . . . . . . . . . . .  4
   4.  Requirements for PW Transfer . . . . . . . . . . . . . . . . .  5
   5.  LDP Extension for PW Transfer  . . . . . . . . . . . . . . . .  6
     5.1.  LDP Extension  . . . . . . . . . . . . . . . . . . . . . .  6
       5.1.1.  Support PW Transfer Capability with LDP  . . . . . . .  6
       5.1.2.  PW Ownership Transfer TLV  . . . . . . . . . . . . . .  6
     5.2.  Procedures . . . . . . . . . . . . . . . . . . . . . . . .  7
       5.2.1.  PW Ownership Transfer from MP to CP  . . . . . . . . .  7
         5.2.1.1.  MP2CP PW Transfer Failure  . . . . . . . . . . . .  8
       5.2.2.  PW Ownership Transfer from CP to MP  . . . . . . . . .  9
         5.2.2.1.  CP2MP PW Transfer Failure  . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Qilei Wang, et al.        Expires July 1, 2012                  [Page 2]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

1.  Introduction

   As defined in [RFC5654], MPLS-TP transport path corresponds to an LSP
   or a PW which is carried in an LSP.  And LSP includes unidirectional
   LSP, co-routed bidirectional LSP and associated bidirectional LSP,
   while PW includes Single-Segment Pseudowire (SS-PW) and Multi-Segment
   Pseudowire (MS-PW).

   For MPLS-TP LSP, it can be created/deleted via GMPLS signaling, see
   [RFC3945].  However, the creation/deletion of PW can be completed by
   LDP, and [RFC4447] gives these procedures of SS-PW while [RFC6073]
   and [DYNAMIC-MS-PW] decribes the ones of MS-PW.

   Nowdays, some service providers have deployed MPLS-TP network for
   mobile backhaul.  However, most PWs are statically configured by
   management plane in the first stage.  So if control plane is deployed
   massively, it is desirable for provider to transfer the control of
   PWs from the management plane (MP) to control plane (CP) in the
   future.  In addition, the control transfer in the opposite direction,
   i.e. from CP to MP, should be considered as well if operators want
   to.

   Both the requirement 55 in [RFC5654] and requirement 47 in [RFC6373]
   state that an MPLS-TP control plane MUST provide a mechanism for
   dynamic ownership transfer of the control of MPLS-TP transport paths
   from the management plane to the control plane and vice versa.
   Furthermore, section 5.3.3 of [RFC6373] describes the requirement for
   PW transfer.  Since [RFC5493] and [RFC5852] give the requirements and
   RSVP-TE extensions and procedures for LSP transfer, this memo
   considers the procedures and LDP extensions for PW transfer.

1.1.  Comparison with Make-before-Break

   The Make-Before-Break (MBB) technology is an alternative method for
   PW transfer which has three steps.  Firstly, a new PW (has the same
   parameters with the one to be transferred) will be created; then the
   PW will be switched from old PW to the new one; and after the PW
   switching completed successfully the old PW will be deleted.  From
   this process, we can find there're many drawbacks with MBB.

   The creation and swithing steps of MBB will lead to instant
   interruption which is acceptable if it can be controlled within 50ms.
   Furthermore, extra resource is need, in the circumstance that the
   network is almost saturated, there maybe not enough resource for the
   new PWs, so MBB will be unavailable.  Otherwise, MBB will lead to
   label modification which will make the bundling relationship between
   PW and LSP modified at the same time.  This will triggre many
   problems, and a new detection mechanism needs to be defined which may

Qilei Wang, et al.        Expires July 1, 2012                  [Page 3]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

   be very complex.  In addition, since control plane is used to create
   the new PW while management plane is responsible for the deletion of
   the old PW.  Thus batch operation can't be used for this process.  If
   there're a large number PWs needed to be transfered, the operator's
   time will be engaged by this tedious operation which is inefficiency.
   However, the PW transfer method described in this document will not
   affect the data plane, the traffic and it's configuration.  So it's
   preference for PW transfer.

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

2.  Terminology

   o  Transport Path: A network connection as defined in G.805
      [ITU.G805.2000].  In an MPLS-TP environment, a transport path
      corresponds to an LSP or a PW (see RFC5654).

   o  Single-Segment Pseudowire (SS-PW): A PW setup directly between two
      T-PE devices.  Each PW in one direction of a SS-PW traverses one
      PSN tunnel that connects the two T-PEs.

   o  Multi-Segment Pseudowire (MS-PW): A static or dynamically
      configured set of two or more contiguous PW segments that behave
      and function as a single point-to-point PW.  Each end of a MS-PW
      by definition MUST terminate on a T-PE.

   o  PW Segment: A part of a single-segment or multi-segment PW, which
      traverses one PSN tunnel in each direction between two PE devices,
      T-PEs and/or S-PEs.

   o  Resource Ownership: A resource used by an MPLS-TP path is said to
      be 'owned' by the plane that was used to set up the MPLS-TP path
      through that part of the network.  So, a resource owned by the
      management/control plane means the resource was used to set up the
      MPLS-TP path through the management/control plane.  See RFC5493
      for detailed description.

3.  Overview of the PW Transfer

   The PW transfer includes two reverse procedures.  One is the MP to CP
   (MP2CP) transfer procedure, another is the CP to MP (CP2MP) transfer
   procedure.

Qilei Wang, et al.        Expires July 1, 2012                  [Page 4]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

   For MP2CP transfer procedure, a PW set up and owned by MP needs to be
   transferred to CP control.  To conduct this transfer, the T-LDP
   session will be created in CP for PW.  After this transfer procedure,
   the resource ownership is transferred from MP to CP.

   The CP2MP transfer procedure is the reverse one compared to MP2CP
   procedure.  However, since a LDP session may be shared by multi PWs,
   the T-LDP session may be retained after one PW transferring from CP
   to MP, if there're still other PWs remain controlled by CP.  So, the
   CP2MP procedure needs to check whether this signaling session should
   be retained or not.

   As an requirement listed in [RFC5493], during both MP2CP and CP2MP
   transfer procedures, if PW is carrying traffic, its control transfer
   has to be done without any disruption to the data plane traffic.

   Furthermore, both MP2CP and CP2MP transfer procedures can be
   conducted in a batch manner, that is, multiple LSPs or PWs can be
   transferred all at one time.  For example, all PWs on a node can be
   transferred at one time.  However, this transfer manner is out of
   this document.

4.  Requirements for PW Transfer

   [RFC5493] describes the requirements for the conversion between
   permanent connection (PC) and switched connection (SC) in a GMPLS
   network.  The terminologies "PC" and "SPC" come from ITU-T standard
   [G.8081], Because associated bidirectional LSP isn't defined in ITU-T
   standard.  So, both PC and SPC can only be considered as
   unidirectional LSP and co-routed bidirectional LSP.  Therefore, these
   requirements fully apply to unidirectional LSP and co-routed
   bidirectional LSP in a MPLS-TP network.  Although, some requirements
   defined in [RFC5493] apply to PW, but other new requirements also
   need to be explored.

   This section lists the special requirements for PW transfer.

   1)  PW attributes MUST not be changed

       The PW attributes, such as bandwith, PWid , PW type, Control
       Word, VCCV, Interface Parameter, MUST not be changed during and
       after the PW transfer.

   2)  PW transfer MUST be independent of LSP

       The PW transfer SHOULD not depend on whether the LSP (bearing
       this PW) is controlled by MP or CP.  Since PW transfer procedure

Qilei Wang, et al.        Expires July 1, 2012                  [Page 5]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

       will not impact the data plane path, so PW transfer MUST leave
       LSP alone.  The relationship between PW and LSP MUST NOT be
       changed.

   3)  Support partial MS-PW segments transfer

       Since a MS-PW transit multi domains and these domains may belong
       to different providers.  In this scenario, if some providers have
       deployed control plane while others not, the PW segments in these
       domains that control plane are deployed SHOULD be allowed to
       transfer between MP and CP while other PW segments keep their
       original states.

5.  LDP Extension for PW Transfer

5.1.  LDP Extension

5.1.1.  Support PW Transfer Capability with LDP

   A new Capability Parameter TLV is defined, the PW Transfer
   Capability.  Following is the format of the PW Transfer Capability
   Parameter.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|0|PW Transfer Capability(TBD)|     Length (= 1)              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1| Reserved    |
     +-+-+-+-+-+-+-+-+

                     Figure 1: PW Transfer Capability

   The PW Transfer Capability TLV MUST be supported in the LDP
   Initialization Message([RFC5561]).  Advertisement of the PW Transfer
   Capability indicates support of the procedures for PW transfer
   between MP and CP detailed in this document.  If the peer has not
   advertised the corresponding capability, then no PW transfer label
   messages should be sent to the peer.

5.1.2.  PW Ownership Transfer TLV

   To ensure the PW ownership transfer between MP and CP automatically,
   T-PE/S-PE SHOULD be notified by the PW transfer signaling message.
   So, the PW path and PW transfer indication MUST be carried in the LDP
   Label Mapping message.

Qilei Wang, et al.        Expires July 1, 2012                  [Page 6]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

   Since [RFC6073] has defined PW switching point TLV (S-PE TLV) and
   Sub-TLV to the switching points that the PW traverses, these TLV and
   Sub-TLV can be used to carry the PW path which is needed to be
   transferred.

   ER-TLV which is defined in [draft-ietf-pwe3-mspw-er] can also be used
   to carry the information of PW path which is needed to be transferred
   in the scenario of setting up MS-PW using generalized FEC 129 from
   source PE to destination PE.

   Therefore, this section only defines a new LDP TLV - Transfer TLV -
   which can be used to indicate a PW transfer signaling procedure.

   The PW Ownership Transfer TLV (PW-OH TLV), is defined as follows (TLV
   type needs to be assigned by IANA):

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|   PW Transfer  (0x0105)   |         Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |POT|                    Reserved                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: PW Ownership Transfer TLV

      POT (2 bits):  PW Ownership Transfer.  PE MUST carry this TLV in
        LDP Label Mapping and Notification message defined in [RFC5036]
        when transferring from MP to CP, or CP to MP.  The value of POT
        is following:

        1 - PW ownership transfer from management plane to control plane

        2 - PW ownership transfer from control plane to management plane

      Reserved(30 bits):  This field MUST be set to zero on transmission
        and MUST be ignored on receipt.

5.2.  Procedures

5.2.1.  PW Ownership Transfer from MP to CP

   Before transferring from MP to CP, there MUST be a T-LDP session
   between two T-PE for SS-PW, or T-PE and S-PE for MS-PW.  During the
   LDP initialization stage, the LDP speaker MUST announce it's PW
   transfer capability according to [RFC5561] by sending the peer a
   Capability message carrying the PW transfer capability TLV.

Qilei Wang, et al.        Expires July 1, 2012                  [Page 7]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

   To conduct the MP2CP PW transfer, operator sends the MP2CP PW
   transfer command to the source and destination T-PEs which will
   inform MP and CP to initiate the MP2CP PW transfer process.  When CP
   gets all the information of the PW to be transferred , the CP of
   source and destination nodes will build the LDP mapping message based
   on the procedures described in [RFC 4447], and send the mapping
   message to its peer T-PE or S-PE.

   The differences between the normal and the MP2CP PW transfer Label
   Mapping message are:

   1.  PW-OH TLV with POT value equals 1 will be encoded into the
       "Optional Parameters" of the Mapping message for both SS-PW and
       MS-PW MP2CP transfer.

   2.  For MS-PW, the PW path will be encoded into S-PE TLVs and Sub-
       TLVs with local S-PE address according to [RFC6073] or ER-TLV
       defined in [draft-ietf-pwe3-mspw-er].

   When the Label Mapping message is build up, it will be send to
   source/destination T-PE for SS-PW and to S-PE for MS-PW.

   For SS-PW, when the source/destination T-PE receives the MP2CP PW
   transfer Label Mapping message, and also send MP2CP PW transfer Label
   Mapping message to its peer, it will transfer the PW control from MP
   to CP.

   For MS-PW, when the S-PE receives the MP2CP PW transfer Label Mapping
   message, it will decode the next hop S-PE from local IP address Sub-
   TLVs in S-PE TLVs then forward this Label Mapping message to the next
   hop S-PE.  Only when S-PE receive the MP2CP PW transfer label mapping
   message from the reverse direction of PW, it will transfer the PW
   control from MP to CP.  When the source/destination T-PE receives the
   MP2CP PW transfer Label Mapping message, it will deal with it in the
   same way as SS-PW described above.

   When ER-TLV is used in MP2CP transfer label mapping message, the next
   hop S-PE information can be get from ER-TLV.  Transfer label mapping
   message then is forwarded to the next hop S-PE.  Only when
   S-PEreceive the MP2CP PW transfer label mapping message from the
   reverse direction, it will transfer the PW control from MP to CP.
   When T-PE receives the MP2CP PW transfer label mapping message, it
   will also deal with it in the same way as SS-PW.

5.2.1.1.  MP2CP PW Transfer Failure

   If T-PEs or S-PEs fail to negotiate PW transfer capability, the
   procedures in [RFC5561] SHOULD be performed.

Qilei Wang, et al.        Expires July 1, 2012                  [Page 8]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

   Since T-LDP runs over TCP, and there is only one hop between T-PEs in
   SS-PW, if the T-LDP sesseion is created successfully, the PW transfer
   Label Mapping can be sent and received reliably.

   For MS-PW, if one of the PW segment fails to transfer from MP to CP,
   a Notification message SHOULD be sent to source/destionation T-PE to
   report the failure.  Reverse control from CP to MP is needed.  And
   the PW segments successfully transferred SHOULD be remained.

5.2.2.  PW Ownership Transfer from CP to MP

   Since multiple PWs can share a single T-LDP session, when a PW
   transferred from CP to MP, the LDP session may be retained for other
   PWs.  So when a PW transfers from CP to MP, a Notification message
   carring the corresponding PW FEC and PW-OH TLV with the POT value
   equals 2 SHOULD be send out.  All the other S-PEs along the PW
   received this Notification message, SHOULD send the notification
   message to next hop S-PE.  Only when S-PE receives notification
   message from reverse direction of PW, it will transfer the PW control
   from CP to MP and remain the corresponding LDP session.  When there
   is no PW, the session MAY be still remained for the future use.
   Thus, whether to delete the LDP session depends on the provider's
   policy.  If the provider want to delete the LDP session in which
   there is no PW, the procedures in [RFC5036] can be conducted.

5.2.2.1.  CP2MP PW Transfer Failure

   Since the PW transfer capability is negotiated before T-LDP session
   set up, and the T-LDP runs over TCP, CP2MP PW transfer can be
   performed reliably.

   For MS-PW, if one PW segment fails to transfer from CP to MP, a
   Notification message SHOULD be sent to source/destionation T-PE to
   report the failure.

6.  Security Considerations

   [RFC5036] and [RFC4447] describe the security considerations that
   apply to the T-LDP specification.  The same security framework and
   considerations apply to the capability mechanism described in this
   document.

7.  IANA considerations

   TBD.

Qilei Wang, et al.        Expires July 1, 2012                  [Page 9]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

8.  Acknowledgements

   The authors would like to thank Weilian Jiang, and Kan Hu for their
   useful comments.

9.  References

9.1.  Normative References

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

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5493]  Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
              "Requirements for the Conversion between Permanent
              Connections and Switched Connections in a Generalized
              Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
              April 2009.

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
              and S. Ueno, "Requirements of an MPLS Transport Profile",
              RFC 5654, September 2009.

   [RFC5852]  Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
              Bardalai, "RSVP-TE Signaling Extension for LSP Handover
              from the Management Plane to the Control Plane in a GMPLS-
              Enabled Transport Network", RFC 5852, April 2010.

   [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
              Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.

Qilei Wang, et al.        Expires July 1, 2012                 [Page 10]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

9.2.  Informative References

   [DYNAMIC-MS-PW]
              Luca Martini, Matthew Bocci, and Florin Balus, "Dynamic
              Placement of Multi Segment Pseudo Wires",
              draft-ietf-pwe3-dynamic-ms-pw-10.txt .

   [G.8081]   International Telecommunications Union, "Terms and
              definitions for Automatically Switched Optical Networks
              (ASON)", Recommendation G.8081/Y.1353, June 2004 .

   [MPLS-TP-CP-FWK]
              Loa Andersson, Lou Berger, and Luyuan Fang, "MPLS-TP
              Control Plane Framework",
              draft-ietf-ccamp-mpls-tp-cp-framework-02.txt .

   [MPLS-TP-FWK]
              M. Bocci and S. Bryant etc., "A Framework for MPLS in
              Transport Networks", draft-ietf-mpls-tp-framework-11.txt .

Authors' Addresses

   Qilei Wang
   ZTE Corporation

   Email: wang.qilei@zte.com.cn

   Muliu Tao
   ZTE Corporation

   Phone: +86 755 26773923
   Email: tao.muliu@zte.com.cn

   Xihua Fu
   ZTE Corporation
   ZTE Plaza, No.10, Tangyan South Road, Gaoxin District
   Xi'an  210012
   P.R.China

   Email: fu.xihua@zte.com.cn

Qilei Wang, et al.        Expires July 1, 2012                 [Page 11]
Internet-Draft        LDP Extension for PW Transfer             Dec 2011

   Ruiquan Jing
   China Telecom

   Email: jingrq@ctbri.com.cn

   Xiaoli Huo
   China Telecom

   Email: huoxl@ctbri.com.cn

Qilei Wang, et al.        Expires July 1, 2012                 [Page 12]