Network Working Group H. Yokota
Internet-Draft D. Kim
Expires: June 24, 2012 KDDI Lab
B. Sarikaya
F. Xia
Huawei USA
December 22, 2011
Home Agent Initiated Flow Binding for Mobile IPv6
draft-yokota-mext-ha-init-flow-binding-01
Abstract
There are scenarios in which the home agent needs to trigger flow
binding operations towards the mobile node such as moving a flow from
one access network to another based on the network resource
availability. In order for the home agent to be able to initiate
interactions for flow bindings with the mobile node, this document
defines new signaling messages and sub-options for Mobile IPv6. Home
agent initiated flow bindings are supported for both IPv4 and IPv6
enabled mobile nodes.
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 June 24, 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
Yokota, et al. Expires June 24, 2012 [Page 1]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Over-the-air Flow Binding Provisioning . . . . . . . . . . 3
3.2. Traffic Offload . . . . . . . . . . . . . . . . . . . . . 4
3.3. Flow Binding Revocation . . . . . . . . . . . . . . . . . 4
3.4. Exceeding traffic quota . . . . . . . . . . . . . . . . . 4
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Adding flow bindings . . . . . . . . . . . . . . . . . . . 5
4.2. Deleting flow bindings . . . . . . . . . . . . . . . . . . 5
4.3. Modifying flow bindings . . . . . . . . . . . . . . . . . 6
4.4. Refreshing flow bindings . . . . . . . . . . . . . . . . . 6
4.5. Moving flow bindings . . . . . . . . . . . . . . . . . . . 6
4.6. Revoking flow bindings . . . . . . . . . . . . . . . . . . 7
5. Handling of the Flow Bindings List . . . . . . . . . . . . . . 7
6. Flow Binding Messages and Options . . . . . . . . . . . . . . 8
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 8
6.1.1. Flow Binding Indication . . . . . . . . . . . . . . . 8
6.1.2. Flow Binding Acknowledgement . . . . . . . . . . . . . 9
6.1.3. Flow Binding Revocation Extensions . . . . . . . . . . 10
6.2. New Options . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. New Actions in Flow Identification Mobility Option . . 11
6.2.2. Target Care-of-Address sub-option . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Protocol constants . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative references . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Yokota, et al. Expires June 24, 2012 [Page 2]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
1. Introduction
[RFC6089] allows a mobile node to bind a particular flow to a care-of
address without affecting other flows using the same home address.
Binding Update (BU)/Binding Acknowledgement(BA) messages are extended
for the mobile node to add, modify, remove and refresh flow binding
in a home agent. The operations are always initiated by the mobile
node.
In some cases, the home agent would like to initiate flow binding
operations. e.g, the home agent revokes a flow binding for reasons
such as accounting insufficiency of the mobile node; for the mobile
node equipped with multiple interfaces, the home agent moves a flow
binding from one interface to another based on network resource
availability; the home agent provisions default flow binding rules to
the mobile node based on the mobile node's default profile.
This document defines one new Mobility Header and two new messages
for the home agent to control flow bindings in the mobile node. Flow
mobility for the mobile nodes with IPv4 home address and IPv4 address
of the home agent as described in [RFC5555] is also supported.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terminology in this document is based on the definitions in
[RFC3775] and [RFC6089].
3. Use Cases
3.1. Over-the-air Flow Binding Provisioning
When a new subscriber purchases a dual mode phone equipped with both
3GPP and WiFi interfaces, depending on the services that the
subscriber can use, the operator provisions the mobile phone over the
air with the following information:
o 3GPP access takes priority over WiFi access when providing Voice-
over-IP (VoIP) service. That is, when making a call, the 3GPP
network is always used as far as the network is accessible.
o WiFi access is primarily selected to serve IPTV service.
Yokota, et al. Expires June 24, 2012 [Page 3]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
o Peer-to-peer (p2p) download is only allowed through WiFi access.
The above profile can be downloaded through the home agent to the
mobile node when registering.
3.2. Traffic Offload
The 3G operator may want to move traffic flows from the 3G access to
another due to ever-increasing traffic load in the 3G access network.
Fine-grained traffic offload is desirable. For example, IMS-based
VoIP flows must stay in the mobile core network while video streaming
flows provided by servers on the Internet could bypass the mobile
core network via WiFi access. Since the network knows more about its
conditions and has access to the policy server, more timely and well-
controlled traffic offloading is possible. To this end, already
established sessions are moved by the home agent by sending down an
updated flow descriptor to the mobile node.
3.3. Flow Binding Revocation
For administrative reasons, such as the utilization of CPU of a home
agent reaches a threshold or the home agent needs to reboot some of
it line cards, sometimes it becomes necessary to inform the mobile
node that its flow binding has been revoked and the mobile node is no
longer able to receive IP mobility service for a given flow. Apart
from revocation, the home agent may decide to delete a flow binding
with a delete operation.
3.4. Exceeding traffic quota
The 3G operator offers a mobile broadband service with a flat rate
subscription limited to 5G Byte per month. Once the quota is reached
the service is downgraded to 64 K bit per second. This limitation
does not prevent the user from using the 3G access for mobile
broadband services and there is no reason for the operator to change
the policy since the service is still available. However, since the
operator has more information available than the user, the operator
can indicate this to the user by sending modified flow descriptors to
the user as a proposal to change access for an ongoing session.
4. Protocol Operation
[RFC6089] makes use of Binding Update (BU) /Binding
Acknowledgement(BA) signalling to forward, i.e. register or discard a
flow binding in a home agent. That is, flow binding operations are
always initiated from the mobile node. The mechanism specified in
this document is complimentary to the method described in [RFC6089].
Yokota, et al. Expires June 24, 2012 [Page 4]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
It is assumed that the home agent has already created Binding Cache
entries for the mobile node before launching flow binding operations.
In this document, one new Mobility Header and two new messages are
defined, that is, Flow Binding Indication (FBI) Section 6.1.1 and
Flow Binding Acknowledgement (FBA)Section 6.1.2. FBI is used by the
home agent to initiate flow binding operations, while FBA is used for
acknowledging FBI.
Due to access network change on the mobile node side, some interface
that used to be active may not be valid at the time of flow binding
operation by the home agent, in which case, even if the HA sends the
FBI to the MN, the FBA will not return. After retransmitting the
FBIs for MAX_FBI_RETRIES times and not receiving the FBA, the HA
determines that the target interface is not available.
4.1. Adding flow bindings
Adding the flow binding implies associating a flow with a particular
care-of address for the mobile node. The care-of address concerned
with the flow binding is present in the destination address of the
packet or the alternate care-of address option. Alternatively, the
care-of address may be indicated by the Target Care-of Address sub-
option defined in Section 6.2.2. Binding Identification number (BID)
described in [RFC5648] is not used in the flows initiated by the home
agent.
When adding a new flow binding, the home agent sends a FBI with a
Flow Identification Mobility option to the mobile node. The Flow
Identification Mobility option defined in [RFC6089] includes a unique
Flow Identifier (FID). The Action field of the option MUST indicate
an Add operation defined in Section 6.2.1. The FID needs only be
unique for the receiver of the message that adds a flow, i.e. the
same FID can be used across different receivers of the message. A
lifetime value is included to indicate the remaining lifetime of the
flow binding.
4.2. Deleting flow bindings
When removing a flow binding, the home agent node sends a FBI with a
Flow Identification Mobility option in which Action field indicates
Delete operation. The Flow Identification Mobility option includes a
unique FID for the mobile node to locate the flow binding and remove
it.
The trigger for the delete operation is MN sending a BU with Flow
Identification Mobility Option that registers a new flow. Using the
delete operation the home agent deletes the new flow registered by
Yokota, et al. Expires June 24, 2012 [Page 5]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
MN.
4.3. Modifying flow bindings
When modifying a flow binding (either the care-of address or other
attributes of the flow), the home agent sends the mobile node a FBI
message with Flow Identification Mobility option. The option
includes the FID for the binding being modified. A Traffic Selector
sub-option may come with the Flow Identification Mobility Option and
contain the new attributes needed to classify the flow such as in
[RFC6088]. Hence, flow modification is essentially a process where
an existing flow definition is removed and a new flow (included in
the option) is added and given the same FID as the flow that was
removed.
4.4. Refreshing flow bindings
A flow binding is refreshed by simply including the Flow
Identification Mobility option with Refresh Action field in the FBI
message. The message should be sent before the expiration of the
flow binding. The message updates existing bindings with new
information. Hence, all information previously sent in the last
refreshing message need to be resent, otherwise such information will
be lost.
4.5. Moving flow bindings
The home agent can move a flow associated to one interface of the
multi-interfaced mobile node to another by sending a FBI message to
the mobile node. A Flow Identification Mobility option whose Action
field is set to Move is included. The address of the target
interface is also included in the Flow Identification Mobility option
in Target Care-of Address sub-option.
In some cases the mobile node manually decides to move an IP Flow
from one interface, e.g. 3GPP to another e.g. WLAN. The home agent
receives such a request to forward a flow and performs the action.
We recognize that the manual intervention is always possible and
generally has precedence to other policies. On such a flow HA-
initiated move operation SHOULD not be used. If used, MN will move
it back and a set of ping-pong move operations will take place. Home
agent SHOULD move such a flow only if network conditions require it
to be moved such as congestion on the current interface because such
conditions can best be detected by the home agent only and not by the
mobile nodes.
Yokota, et al. Expires June 24, 2012 [Page 6]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
4.6. Revoking flow bindings
Home agent revokes a flow binding registration by the mobile node,
i.e. flow identification mobility option sent by MN with action set
to forward. One possible reason is the home agent is overloaded.
There could be other reasons.
HA sends the mobile node a FBI message with flow identification
mobility option. HA includes the flow identification mobility option
received from MN. HA sets the action field to Revoke.
MN MUST send a FBA message to indicate that it has received FBI
message of flow revocation. If MN accepts the revocation it MUST set
the status code to 0 for success.
5. Handling of the Flow Bindings List
Flow bindings list defined in [RFC6089] needs to be modified after
each protocol operation defined above as follows:
If FBI contains a flow binding add operation and if the corresponding
FBA has a status code equal to zero, home agent MUST add a new entry
to the flow bindings list. FID, Flow Descriptor, FID-PRI and Action
fields are taken from the Flow Identification Mobility Option. BID
is copied from the Binding Reference sub-option. Active/Inactive
Flag is set to Active. Note that if BID is not available it may be
replaced by Care-of-Address.
If FBI contains a flow binding delete operation and if the
corresponding FBA has a status code equal to zero, home agent MUST
locate the list entry corresponding to this flow and then delete the
entry.
If the home agent sends a Binding Revocation Indication message with
Flow Mobility Option where the action field is set to Revoke and if
the corresponding Binding Revocation Acknowledgement message
indicates acceptance, home agent MUST locate the list entry
corresponding to this flow and then delete the entry.
If FBI contains a flow binding modify operation and if the
corresponding FBA has a status code equal to zero, home agent MUST
delete the list entry corresponding to this flow and then add a new
entry setting the values as defined in the Flow Identification
Mobility Option.
If FBI contains a flow binding refresh operation and if the
corresponding FBA has a status code equal to zero, home agent MUST
Yokota, et al. Expires June 24, 2012 [Page 7]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
locate the list entry corresponding to this flow and then set Active/
Inactive Flag to Active.
If FBI contains a flow binding move operation and if the
corresponding FBA has a status code equal to zero, home agent MUST
locate the list entry corresponding to this flow and then change the
BID value to the Care-of-Address in the Flow Identification Mobility
Option.
If FBI contains a flow binding switch operation and if the
corresponding FBA has a status code equal to zero, home agent MUST
locate the list entry corresponding to this flow and then delete the
entry.
Flow binding operations apply equally to IPv6 packets as well as IPv4
packets as in Dual-Stack Mobile IPv6 [RFC5555].
6. Flow Binding Messages and Options
6.1. Mobility Header
The messages described below follow the Mobility Header format
specified in Section 6.1 of [RFC3775].
6.1.1. Flow Binding Indication
The Flow Binding Indication messages are used by the home agent to
initiate flow binding operations to the mobile node. The Flow
Binding Indication messages use the MH Type value (IANA-TBD1) for
Flow Binding message and a Flow Binding Type value of 1, and the
format of the Message Data field in the Mobility Header is as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Binding Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Trigger |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Flow Binding Indication Message Type
Yokota, et al. Expires June 24, 2012 [Page 8]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
Sequence #
A 16-bit unsigned integer used by the home agent to match a
returned Flow Binding Acknowledgement with this Flow Binding
Indication. It could be a random number.
Trigger
8-bit unsigned integer indicating the event which triggered the
home agent to send the Flow Binding Indication message. The
following Trigger values are currently defined:
0 Reserved
1 Unspecified
2 Administrative Reason
3 Possible Out-of Sync BCE State
250-255 Reserved For Testing Purposes only
All the other values are reserved
Acknowledge (A)
The Acknowledge (A) bit is set by the home agent to request a Flow
Binding Acknowledgement be returned upon receipt of the Flow
Binding Indication.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Flow
Identification Mobility Options are included in this field.
6.1.2. Flow Binding Acknowledgement
The Flow Binding Acknowledgement is used to acknowledge receipt of a
Flow Binding Indication. The mobile node sends FBA message to
acknowledge the reception of FBI to Add, Delete, Modify, Refresh,
Move, or Switch a flow binding. On receiving messages with Flow
Identification Mobility Option(s), the mobile node should copy each
Flow Identification Mobility Option to the Acknowledgement messages.
The Flow Binding Acknowledgement has the MH Type value (IANA-TBD1)
for Flow Binding message and a Flow Binding Type value of 2. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
Yokota, et al. Expires June 24, 2012 [Page 9]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Binding Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flow Binding Acknowledgement Message Type
Sequence #
The sequence number in the Flow Binding Acknowledgement is copied
from the Sequence Number field in the Flow Binding Indication.
Status
8-bit unsigned integer indicating the result of processing the
Flow Binding Indication message by the receiving mobile node.
Values of the Status field less than 128 indicate that the Flow
Binding Indication was processed successfully by the receiving
node. Values greater than or equal to 128 indicate that the Flow
Binding Indication was rejected by the receiving node. The
following status values are currently defined:
0 success
128 Binding Does NOT Exist
All the other values are reserved
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. Flow
Identification Mobility Options are included in this field.
6.1.3. Flow Binding Revocation Extensions
This specification enables Binding Revocation Indication and Binding
Revocation Acknowledgement messages to carry Flow Identification
Mobility Options as defined in [RFC6089] with extensions defined in
this document.
Yokota, et al. Expires June 24, 2012 [Page 10]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
6.2. New Options
6.2.1. New Actions in Flow Identification Mobility Option
This specification defines new actions to be carried in Action
parameter of the Flow Identification Mobility Option defined in
[RFC6089].
Action
This is a 8-bit field that describes the required processing for
the option. It can be assigned one of the following new values in
addition to 0-2 already assigned:
11 Add a flow binding
12 Delete a flow binding
13 Modify a flow binding
14 Refresh a flow binding
15 Move a flow binding
16 Revoke a flow binding
All the other values are reserved
6.2.2. Target Care-of-Address sub-option
This section introduces the Target Care-of-Address, which may be
included in the Flow Identification Mobility Option. This sub-option
is used to indicate the mobile node to move a flow binding from one
interface to another.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-opt Type | Sub-opt Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Care-of-Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Target Care-of-Address Sub-option
Sub-opt Type
To be assigned by IANA
Sub-opt Len
Length of the sub-option in 8-octet units
Yokota, et al. Expires June 24, 2012 [Page 11]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Target Care-of-Address
The address of an interface that the flow is moved to. This
address could be IPv4 or IPv6 address.
7. Security Considerations
Security issues for this document follow those of [RFC6088],
[RFC6089] and [RFC5846]. This specification allows the home agent to
manipulate only the binding of a flow(s) that is currently registered
with it, which is the same principle described in [RFC5846]. No
additional security issue specific to this document is identified.
8. Protocol constants
Maximum FBI retries (MAX_FBI_RETRIES)
This variable specifies the maximum number of times the HA MAY
retransmit a Flow Binding Indication message when FBA is not
returned within the time period specified by MAX_FBA_TIMEOUT. The
default value for this parameter is 3.
Maximum FBA timeout (MAX_FBA_TIMEOUT)
This variable specifies the maximum time in seconds the HA MUST
wait before retransmitting another FBI message. The default for
this parameter is 3 seconds.
9. IANA considerations
This document defines one new Mobility Header and two new mobility
options to be used in Flow Binding Initiate and Flow Binding
Acknowledge messages. A new Mobility Header Type and new mobility
option values (IANA-TBD1 and IANA-TBD2) need to be assigned by IANA.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Yokota, et al. Expires June 24, 2012 [Page 12]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088,
January 2011.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
January 2011.
10.2. Informative references
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
Yokota, et al. Expires June 24, 2012 [Page 13]
Internet-Draft HA Initiated Flow Binding for Mobile IPv6 December 2011
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara
Fujimino
Saitama, Japan 356-8502
Phone:
Email: yokota@kddilabs.jp
Dae-Sun Kim
KDDI Lab
2-1-15 Ohara
Fujimino
Saitama, Japan 356-8502
Phone:
Email: da-kim@kddilabs.jp
Behcet Sarikaya
Huawei USA
5340 Legacy Drive Building 3
Plano, TX 75024
Phone: +1 469-277-5839
Email: sarikaya@ieee.org
Frank Xia
Huawei USA
5430 Legacy Dr. Building 3
Plano, TX 75024
Phone:
Email: xiayangsong@huawei.com
Yokota, et al. Expires June 24, 2012 [Page 14]