Network Working Group                                        B. Sarikaya
Internet-Draft                                                    F. Xia
Expires: April 23, 2010                                       Huawei USA
                                                        October 20, 2009


                   Dual-stack Lite Mobility Solutions
             draft-sarikaya-softwire-dslitemobility-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 April 23, 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.









Sarikaya & Xia           Expires April 23, 2010                 [Page 1]


Internet-Draft             Mobility Solutions               October 2009


Abstract

   Two solutions are presented to show how to use Dual-Stack Lite
   transition technique in mobile networks: one for Proxy Mobile IPv6
   and the other for Dual-Stack Mobile IPv6.  Proxy Mobile IPv6 allows
   IPv4 nodes to receive mobility services using an IPv4 home address.
   Mobile node can have IPv4 only operation by sending IPv4 datagrams
   which are encapsulated by the Mobile Access Gateway (MAG) at the DS-
   lite home router and and tunneled to Local Mobility Anchor (LMA)
   which is also DS-lite carrier-grade Network Address Translator (NAT).
   In case of client based mobility using DSMIPv6, mobile node is a
   dual-stack node and it can receive an IPv4 home address from the home
   agent which is co-located with DS-lite carrier-grade NAT.  Mobile
   node (MN) encapsulates IPv4 datagrams in IPv6 which are decapsulated
   at the home agent (HA).  Mobile network could be WiMAX network or
   3GPP Long Term Evolution network.



































Sarikaya & Xia           Expires April 23, 2010                 [Page 2]


Internet-Draft             Mobility Solutions               October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Proxy Mobile IPv6 Solution . . . . . . . . . . . . . . . . . .  5
     3.1.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Combined Operation of LMA and CGN  . . . . . . . . . . . .  7
     3.3.  Other Considerations . . . . . . . . . . . . . . . . . . .  8
   4.  Mobile IPv6 Solution . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Combined Operation of HA and CGN . . . . . . . . . . . . . 10
     4.3.  Other Considerations . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
































Sarikaya & Xia           Expires April 23, 2010                 [Page 3]


Internet-Draft             Mobility Solutions               October 2009


1.  Introduction

   Dual-stack lite is a new IPv6 transition scheme that is being defined
   in IETF [I-D.ietf-softwire-dual-stack-lite].  There is a strong
   interest on DS-lite by mobile operators due to the earlier-than-
   expected depletion of IPv4 addresses.  DS-lite enables sharing of
   IPv4 addresses by the nodes by using the same set of IPv4 addresses.

   DS-lite network is IPv6 based.  This way IPv4 is pushed to the edge.
   Hosts can be dual-stack.  DS-lite also supports IPv4-only hosts.
   Currently only two architectures are defined in DS-lite
   [I-D.ietf-softwire-dual-stack-lite]: router-based and host-based.  In
   router-based architecture IPv4 hosts send and receive IPv4 datagrams
   from the DS-lite home router.  DS-lite home router is the softwire
   initiator and it encapsulates IPv4 datagrams in IPv6 and sends them
   to DS-lite carrier-grade NAT which is the softwire concentrator.
   Carrier-grade NAT decapsulates the datagrams, does address
   translation and then transmits IPv4 datagrams outbound.  Inbound IPv4
   datagrams receive the reverse treatment.  This architecture is
   defined to handle installed base of IPv4-only devices.

   In host-based architecture, the host is the softwire initiator and it
   encapsulates IPv4 datagrams in IPv6 and then sends them to the
   carrier-grade NAT which is a softwire concentrator.  All the hosts
   are assigned the same IPv4 addresses (yet to be defined by IANA).
   Carrier-grade NAT decapsulates and then translates IPv4 packet and
   sends it out.  Inbound IPv4 datagrams go through address translation
   and then they are sent to the host using IPv4-in-IPv6 encapsulation.

   In this document we present two mobility solutions for DS-lite: Proxy
   Mobile IPv6 [RFC5213] and Client Mobile IPv6 [RFC5555].  In Proxy
   Mobile IPv6 we use the router-based architecture.  Home router is
   also PMIPv6 MAG.  Carrier-grade NAT should be co-located with LMA.

   Proxy Mobile IPv6 IPv4 support [I-D.ietf-netlmm-pmip6-ipv4-support]
   allows IPv4-only mobile nodes to receive IPv4 home addresses and then
   PMIPv6 handles their mobility.  PMIPv6 also allows IPv4 transport
   between MAG and LMA.  For DS-lite PMIPv6 scenario the solution in
   this document covers the case of IPv4 local link operation but IPv4
   transport between MAG and LMA is not supported in DS-lite since DS-
   lite network is IPv6 only.

   For client Mobile IPv6, we use the host-based architecture of DS-
   lite.  In this case MN is the softwire initiator and it encapsulates
   IPv4 datagrams in IPv6 and sends them to the carrier-grade NAT which
   is co-located with the home agent.  Home agent receives the
   encapsulated datagram and depsulates and then hands it to the NAT
   box.  IPv4 datagram is translated and then sent out.  Inbound



Sarikaya & Xia           Expires April 23, 2010                 [Page 4]


Internet-Draft             Mobility Solutions               October 2009


   datagrams are first address translated.  HA then searches its binding
   cache and finds IPv6 care-of address and then encapsulates the
   datagram and sends it to MN.

   Client Mobile IPv6 defines other scenarios as well in [RFC5555].
   IPv4-only scenario and its variations such as mobile node behind a
   NAT which could be located at the home router and therefore requires
   NAT traversal mechanisms and home agent behind NAT but home agent has
   a globally unique IPv4 address.  Using DS-lite host-based
   architecture, the need for these more complicated operations is
   eliminated.


2.  Terminology

   This document uses the terminology defined in
   [I-D.ietf-softwire-dual-stack-lite], [RFC5121] and [3GPP23402].


3.  Proxy Mobile IPv6 Solution

   MN is IPv4-only host.  MAG functionality of PMIPv6 is hosted in
   ASN-GW and LMA is in the CSN in WiMAX architecture [WiMAXnwg].  MAG
   is at the Serving Gateway and LMA at the Packet Data Network Gateway
   in 3GPP architecture [3GPP23402].  DS-lite needs to be supported in
   these networks, i.e.  R3 between ASN-GW and LMA in WiMAX and S8
   between the serving gateway and PDN Gateway in LTE are IPv6-only.
   ASN-GW/Serving Gateway is DS-lite home router and LMA/PDN Gateway is
   DS-lite carrier-grade NAT [I-D.ietf-softwire-dual-stack-lite].

   PMIPv6 IPv4 MN operation is shown in Figure 1.  MN first gets an IPv4
   home address (IPv4-MN-HoA, a private address from RFC 1918) assigned
   using DHCPv4.  MN sends IPv4 datagrams on the wireless link.  MAG
   tunnels (IPv4-in-IPv6) the datagrams to LMA.  MAG has no NAT
   functionality.  The tunnel end points are Proxy-CoA and LMAA which
   are both IPv6 addresses.  LMA keeps Proxy Mobile IPv6 MN state in the
   binding cache and also has NAT functionality.














Sarikaya & Xia           Expires April 23, 2010                 [Page 5]


Internet-Draft             Mobility Solutions               October 2009


            MN       MAG    LMA
            |        |        |
            |------->|        |      DHCP DISCOVER
            |        |------->|      PBU
            |        |<-------|      PBA (IPv4 HoA)
            |<-------|        |      DHCP Offer
            |------->|        |      DHCP Request
            |<-------|        |      DHCP Ack
            |------->|        |      IPv4 Datagram1
            |        |--------|
            |        |------->|      IPv4 Datagram2
            |        |--------|--->  IPv4 Datagram3
            |        |        |
            |        |--------|<---  IPv4 Datagram4
            |        |<-------|      IPv4 Datagram5
            |        |--------|
            |------->|        |      IPv4 Datagram6


                         Figure 1: PMIPv6 IPv4 MN

3.1.  Scenarios

   Scenario in Figure 1 has these steps:

   1.  MN sends DHCPDISCOVER to DHCP Proxy at MAG.  MAG sends PBU to LMA
       and asks for an IPv4 HoA to be assigned to this MN.  LMA sends
       back PBA with the assigned IPv4-HoA.  PBU and PBA are IPv6
       messages as defined in [RFC5213].  DHCP Proxy sends IPv4 HoA to
       MN using DHCPOFFER.  MN and DHCP Proxy exchange DHCPREQUEST and
       DHCPACK.
   2.  MN sends IPv4 datagram1 to MAG.  Destination address is CN
       address (128.0.0.1).  Source address is IPv4 HoA (10.0.0.1).
       Destination TCP port is 80 and source port is 10000.  MAG
       encapsulates Datagram1 in IPv4 in IPv6 Datagram2.  Destination
       address is LMAA (2001:0:0:2::1) and source address is Proxy-CoA
       (2001:0:0:1::1).  LMA decapsulates the datagram and searches the
       binding cache for the destination IPv4 address (128.0.0.1).  If
       not found, LMA next invokes its NAT function.  The NAT determines
       that TCP source port 10000 should be translated to TCP source
       port 5000 and IP source address 10.0.0.1 to 129.0.0.1.  This new
       IPv4 datagram is IPv4 Datagram3 shown in Figure 1.  LMA sends
       IPv4 datagram3 on its WAN interface.
   3.  IPv4 Datagram 4 is received on LMA's network interface.  IPv4
       destination address is 129.0.0.1, source address is 128.0.0.1,
       TCP destination port is 5000 and source port is 80.  First
       carrier-grade NAT operation takes place: destination address is
       changed to MN' IPv4 HoA 10.0.0.1, TCP destination port to 10000.



Sarikaya & Xia           Expires April 23, 2010                 [Page 6]


Internet-Draft             Mobility Solutions               October 2009


       Next, LMA searches the destination address in its binding cache
       and finds the MN and its latest MAG address, Proxy-CoA which is
       2001:0:0:1::1.  LMA encapsulates IPv4 datagram as an IPv6
       datagram5 with IPv6 source address 2001:0:0:2::1 and IPv6
       destination address 2001:0:0:1::1 and sends it on the tunnel.
       MAG receives IPv6 datagram 5 and decapsulates it obtaining IPv4
       Datagram 6 with IPv4 destination address 128.0.0.1, IPv4 source
       address 10.0.0.1, TCP destination port 10000, source port 80.
       MAG/ASN-GW forwards IPv4 Datagram6 to MN.
   4.  MN handoffs and gets connected to a different MAG.  IPv4 default
       router address of MN MUST be used as the DHCP server ID on any of
       the links.  After handoff, MN sends DHCPREQUEST message for
       renewing its IPv4-HoA.  The new MAG (ASN-GW or Serving Gateway)
       sends PBU to LMA and receives IPv4-HoA in PBA.  MAG returns this
       address in DHCPACK.

3.2.  Combined Operation of LMA and CGN

   CGN keeps track of all the sessions of IPv4 MNs using a NAT table.
   The NAT table has entries like:
   - IPv4 header fields of source and destination address and protocol
   fields
   - Transport header fields of source and destination ports
   - CGN also adds to NAT table IPv6 address of MAG to which MN is
   connected.


   If GRE tunneling is used CGN must add GRE keys to NAT table.

   IPv4 header fields and transport header fields can be obtained from
   the inner header of IPv6 encapsulated IPv4 datagram but IPv6 address
   of MAG is the source address of the outer IPv6 header.  For the
   datagrams coming from MAGs, CGN needs to access the encapsulated
   packet so that it can determine IPv6 address of MAG this MN belongs
   and place it in the NAT table.  This requires LMA pass the full
   datagram to CGN by not removing the outer header.  GRE keys (uplink
   and downlink) if received in the GRE header must also be passed to
   CGN to be placed in the NAT Table.

   For datagrams received from the network CGN receives IPv4 datagram
   first.  CGN looks up in the NAT table and finds the matching entry.
   CGN changes destination IPv4 address and destination port.  When CGN
   passes the new datagram to LMA, CGN must also pass IPv6 address of
   MAG or GRE keys associated with this MN.  LMA can identify MN
   uniquely using this additional information (IPv6 address of MAG or
   GRE keys).  MNs with the same private address connected to different
   MAGs are identified using IPv6 address of MAG and MNs with the same
   private address connected to the same MAG are identified using GRE



Sarikaya & Xia           Expires April 23, 2010                 [Page 7]


Internet-Draft             Mobility Solutions               October 2009


   keys.

3.3.  Other Considerations

   MAG to LMA tunnel may use GRE tunneling for several purposes, e.g. to
   separate the flows from different MNs with the same private home
   address [I-D.ietf-netlmm-grekey-option].

   Proxy Mobile IPv6 scenario uses legacy IPv4 private addresses and
   each MN is assigned a different address.  There is no limitation on
   the use of ports due to MNs sharing the same IPv4 address.  All
   considerations related to the use of private addresses apply here
   also.

   Since DS-lite network is IPv6 based IPv4 transport between MAG and
   LMA is not needed.  This simplifies IPv4 support in Proxy Mobile
   IPv6.

   When MN sends a DNS query to find the destination address in IPv4,
   MAG MUST proxy IPv4 DNS queries.  MAG MUST conform to the DNS Proxy
   Implementation guidelines in [RFC5625].


4.  Mobile IPv6 Solution

   Dual-stack MN can get an IPv4 home address by sending an IPv6 Binding
   Update to the Home Agent.  MN MUST include IPv4 home address option
   defined in [RFC5555] in the BU and set the address to 0.0.0.0.  HA
   assigns an IPv4 home address and returns it in a BA.  MN tunnels
   (IPv4-in-IPv6) datagrams to HA.  HA has NAT functionality.

   HA is a standalone entity in WiMAX [WiMAXnwg], HA MUST be dual-stack
   and col-located with DS-lite carrier-grade NAT.  MN is the softwire
   initiator.  PDN Gateway is the home agent in LTE [3GPP23402], co-
   located with DS-lite carrier-grade NAT
   [I-D.ietf-softwire-dual-stack-lite].  PDN gateway MUST be dual-stack.















Sarikaya & Xia           Expires April 23, 2010                 [Page 8]


Internet-Draft             Mobility Solutions               October 2009


            MN       DHCP    HA
            |        |        |
            |------->|        |      DHCP Information Request
            |<-------|        |      DHCP Information Reply
            |---------------->|      BU
            |<----------------|      BA (IPv4 HoA)
            |-----------------|
            |-IPv6 Datagram1->|
            |-----------------|--->  IPv4 Datagram2
            |        |        |
            |-----------------|<---  IPv4 Datagram3
            |<-IPv6 Datagram4-|
            |-----------------|



                 Figure 2: Mobile IPv6 Dual-Stack Lite MN

4.1.  Scenarios

   The scenario in Figure 2 has the following steps:

   1.  MN enters the network.  MN autoconfigures IPv6 care-of address
       (2001:0:0:1::1).  MN needs to be assigned an IPv6 HA address
       (2001:0:0:2::1) and an IPv6 home address.  MN sends DHCP
       Information Request message to DHCP Proxy/Server
       [I-D.ietf-mip6-hiopt].  DHCP Proxy/Server will send Reply message
       with IPv6 and IPv4 address of IPv6 HA and Home Network Prefix
       values for MN (see also Section 4.8.4.1.1 of Stage 3 document for
       WiMAX [WiMAXnwg]).
   2.  MN registers its CoA by sending a BU to HA.  MN adds IPv4 Home
       Address option and sets IPv4 Home Address field to 0.0.0.0.  HA
       sends BA with IPv4 Address Acknowledgement option.  HA assigns an
       IPv4 HoA to MN (a.b.c.d) and sets this value in IPv4 Home Address
       field.  HA creates a binding in its binding cache for both MN
       IPv6 HoA and IPv4 HoA.
   3.  Note that 3GPP also supports dynamic home address configuration
       for MN [3GPP24303].  Static allocation, e.g.  DHCP server
       returning IPv4 HoA in its reply message to DHCP Information
       Request message is possible but dynamic allocation is the
       preferred way.
   4.  MN sends IPv4 datagrams encapsulated in IPv6.  MN acts as
       Softwire Initiator (SI) of the Softwire NAT (SNAT).  In IPv6
       header, the source address is IPv6 care-of address
       (2001:0:0:1::1) and destination address is IPv6 HA address (2001:
       0:0:2::1).  TCP destination port is 80 and source port is 10000.
       IPv4 packet's source address MUST be IPv4 home address (a.b.c.d)
       [RFC3775].  Destination address is CN's IPv4 address (128.0.0.1).



Sarikaya & Xia           Expires April 23, 2010                 [Page 9]


Internet-Draft             Mobility Solutions               October 2009


       The encapsulated datagram is sent over the tunnel to HA whose
       IPv6 address is 2001:0:0:2::1.  HA decapsulates the datagram and
       hands in the resulting IPv4 datagram to SNAT softwire
       concentrator (SC) for translation.  Based on the translation
       table, SC generates IPv4 datagram 2.  IPv4 destination address is
       128.0.0.1, source address is 129.0.0.1, TCP source port is 5000
       and destination port is 80.
   5.  SNAT SC receives a datagram whose source address is 128.0.0.1,
       destination address is 129.0.0.1, TCP destination port is 5000
       and source port is 80.  After NAT translation, the header changes
       to: IPv4 destination address a.b.c.d, source address 128.0.0.1,
       TCP destination port is 10000 and source port is 80.  HA receives
       IPv4 datagram.  It searches the binding cache for the destination
       address.  It finds the binding cache entry containing IPv6 home
       address, IPv6 care-of address.  HA encapsulates IPv4 datagram in
       IPv6 header.  The source address is IPv6 HA address
       2001:0:0:2::1, destination address is IPv6 MN care-of address
       2001:0:0:1::1.  The resulting IPv6 datagram 4 is sent over HA to
       MN tunnel.  MN decapsulates IPv6 datagram 4 and obtains IPv4
       datagram.  IPv4 datagram destination address is a.b.c.d, source
       address is 128.0.0.1, TCP destination port is 10000, source port
       is 80.
   6.  MN handoffs and gets connected to a different ASN-GW.  MN gets
       another IPv6 care-of address, possibly using stateless address
       configuration or using DHCPv6.  MN sends a BU to HA to register
       its new care-of address.  MN MUST include IPv4 Home Address
       option.  IPv4 home address field must be set to a.b.c.d.  MN
       receives a BA.

4.2.  Combined Operation of HA and CGN

   Similar considerations described above in Section 3.2 apply here also
   for the combined operation of HA and CGN.

4.3.  Other Considerations

   One important aspect of DS Lite operation is that all MNs share the
   same IPv4 home address of a.b.c.d.  This address is to be assigned by
   IANA.  The disambiguation at SNAT SC is done using the tunnel
   endpoints.

   Due to the sharing of the same IPv4 address, there is a restriction
   on the number of ports each MN can use.  If at a given moment 100 MNs
   are sharing the same address the number of ports available to each MN
   is approximately 650.  However if the ports are allocated dynamically
   the number of ports each MN gets may be increased depending on the
   usage at each MN.




Sarikaya & Xia           Expires April 23, 2010                [Page 10]


Internet-Draft             Mobility Solutions               October 2009


   The fact that DS-lite network is IPv6 based and Mobile IPv6 hosts are
   capable of encapsulating/decapsulating IPv4 datagrams in IPv6 several
   scenarios in dual-stack Mobile IPv6 are not needed.  This simplifies
   the client Mobile IPv6 operation for dual-stack MN.


5.  Security Considerations

   This document does not by itself introduce any security issues.


6.  IANA Considerations

   None.


7.  Acknowledgements

   TBD.


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.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-stack lite broadband deployments
              post IPv4 exhaustion",
              draft-ietf-softwire-dual-stack-lite-01 (work in progress),
              July 2009.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
              BCP 152, RFC 5625, August 2009.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [I-D.ietf-netlmm-pmip6-ipv4-support]



Sarikaya & Xia           Expires April 23, 2010                [Page 11]


Internet-Draft             Mobility Solutions               October 2009


              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
              (work in progress), September 2009.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

8.2.  Informative references

   [RFC5121]  Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
              Madanapalli, "Transmission of IPv6 via the IPv6
              Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
              February 2008.

   [I-D.ietf-netlmm-grekey-option]
              Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
              "GRE Key Option for Proxy Mobile IPv6",
              draft-ietf-netlmm-grekey-option-09 (work in progress),
              May 2009.

   [I-D.ietf-mip6-hiopt]
              Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
              Options for Home Information Discovery in MIPv6",
              draft-ietf-mip6-hiopt-17 (work in progress), May 2008.

   [3GPP23402]
              "3GPP TS  23.402. Architecture enhancements for non-3GPP
              accesses.", June 2009.

   [3GPP24303]
              "3GPP TS  24.303. Mobility Management Using Dual-Stack
              Mobile IPv6.", March 2009.

   [WiMAXnwg]
              "WiMAX Forum Networking Working Group Stage 3
              Specification Release 1.5.", March 2009.















Sarikaya & Xia           Expires April 23, 2010                [Page 12]


Internet-Draft             Mobility Solutions               October 2009


Authors' Addresses

   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org


   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com

































Sarikaya & Xia           Expires April 23, 2010                [Page 13]