Network Working Group W. Dec, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track T. Mrugalski
Expires: March 13, 2012 ISC
T. Sun
China Mobile
B. Sarikaya
Huawei USA
September 10, 2011
DHCPv6 Route Options
draft-ietf-mif-dhcpv6-route-option-03
Abstract
This document describes DHCPv6 Route Options for provisioning IPv6
routes on DHCPv6 client nodes. This is expected to improve the
ability of an operator to configure and influence a nodes' ability to
pick an appropriate route to a destination when this node is multi-
homed and where other means of route configuration may be
impractical.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 March 13, 2012.
Copyright Notice
Dec, et al. Expires March 13, 2012 [Page 1]
Internet-Draft DHCPv6 Route Options September 2011
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
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. Problem overview . . . . . . . . . . . . . . . . . . . . . . . 3
3. DHCPv6 Based Solution . . . . . . . . . . . . . . . . . . . . 4
3.1. Default route configuration . . . . . . . . . . . . . . . 4
3.2. Configuring on-link routes . . . . . . . . . . . . . . . . 5
3.3. Deleting obsolete route . . . . . . . . . . . . . . . . . 5
3.4. Applicability to routers . . . . . . . . . . . . . . . . . 5
3.5. Updating Routing Information . . . . . . . . . . . . . . . 5
3.6. Limitations . . . . . . . . . . . . . . . . . . . . . . . 6
4. DHCPv6 Route Options . . . . . . . . . . . . . . . . . . . . . 7
4.1. Next Hop Option Format . . . . . . . . . . . . . . . . . . 7
4.2. Route Prefix Option Format . . . . . . . . . . . . . . . . 8
5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 10
6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Contributors and Acknowledgements . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Dec, et al. Expires March 13, 2012 [Page 2]
Internet-Draft DHCPv6 Route Options September 2011
1. Introduction
The Neighbor Discovery (ND) protocol [RFC4861] provides a mechanism
for hosts to discover one or more default routers on a directly
connected network segment. Extensions to the Router Advertisement
(RA) protocol defined in [RFC4191] allow hosts to discover the
preferences for multiple default routers on a given link, as well as
any specific routes advertised by these routers. This allows network
administrators to better handle multi-homed host topologies and
influence the route selection by the host. This ND based mechanism
however is sub optimal or impractical in some multi-homing scenarios,
where DHCPv6 [RFC3315] is seen to be more viable.
This draft defines the DHCPv6 Route Options for provisioning IPv6
routes on DHCPv6 clients. The proposed option is primarily envisaged
for use by DHCPv6 client nodes that are capable of making basic IP
routing decisions and maintaining an IPv6 routing table, broadly in
line with the capabilities of a generic host as described in
[RFC4191].
Throughout the document the words node and client are used as a
reference to the device with such routing capabilities, hosting the
DHCPv6 client software. The route information is taken to be
equivalent to static routing, and limited in the number of required
routes to a handful.
2. Problem overview
The solution described in this document applies to multi-homed
scenarios including ones where the client is simultaneously connected
to multiple access network (e.g. WiFi and 3G). The following
scenario is used to illustrate the problem as found in typical multi-
homed residential access networks. It is duly noted that the problem
is not specific to IPv6, occurring also with IPv4, where it is today
solved by means of DHCPv4 classless route information option
[RFC3442], or alternative configuration mechanisms.
In multi-homed networks, a given user's node may be connected to more
than one gateway. Such connectivity may be realized by means of
dedicated physical or logical links that may also be shared with
other users nodes. In such multi-homed networks it is quite common
for the network operator to offer the delivery of a particular type
of IP service via a particular gateway, where the service can be
characterised by means of specific destination IP network prefixes.
Thus, from an IP routing perspective in order for the user node to
select the appropriate gateway for a given destination IP prefix,
recourse needs to be made to classic longest destination match IP
Dec, et al. Expires March 13, 2012 [Page 3]
Internet-Draft DHCPv6 Route Options September 2011
routing, with the node acquiring such prefixes into its routing
table. This is typically the remit of dynamic Internal Gateway
Protocols (IGPs), which however are rarely used by operators in
residential access networks. This is primarily due to operational
costs and a desire to contain the complexity of user nodes and IP
Edge devices to a minimum. While, IP Route configuration may be
achieved using the ICMPv6 extensions defined in [RFC4191], this
mechanism does not lend itself to other operational constraints such
as the desire to control the route information on a per node basis,
the ability to determine whether a given node is actually capable of
receiveing/processing such route information. A preferred mechanism,
and one that additionally also lends itself to centralized management
independent of the management of the gateways, is that of using the
DHCP protocol for conveying route information to the nodes.
3. DHCPv6 Based Solution
A DHCPv6 based solution allows an operator an on demand and node
specific means of configuring static routing information. Such a
solution also fits into network environments where the operator
prefers to manage Residential Gateway (RG) configuration information
from a centralized DHCP server.
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] provides additional
background to the need for a DHCPv6 solution to the problem.
In terms of the high level operation of the solution defined in this
draft, a DHCPv6 client interested in obtaining routing information
request the route options using the DHCPv6 Option Request Option
(ORO) sent to a server. A Server, when configured to do so, provides
the requested route information as part of a nested options structure
covering; the next-hop address; the destination prefix; the route
metric; any additional options applicable to the destination or next-
hop.
3.1. Default route configuration
Defined mechanism may be used to configure default route. Default
route may be specified in two ways.
In bandwidth constrained networks, server MAY send NEXT_HOP option
without any RT_PREFIX options. NEXT_HOP option that does not contain
any RT_PREFIX options designate default router. Second way of
defining default route is to convey RT_PREFIX option that specifies
::/0 route, included as suboption in NEXT_HOP. First approach has
the benefit of consuming less bandwidth, while the second one allows
definition of default route lifetime and metric.
Dec, et al. Expires March 13, 2012 [Page 4]
Internet-Draft DHCPv6 Route Options September 2011
Server MUST NOT define more than one default prefix (i.e. both
defined configuration methods are mutually exclusive). Unless there
are significant bandwidth restrictions, mechanism that uses ::/0
RT_PREFIX option SHOULD be used.
3.2. Configuring on-link routes
Server may also configure on-link routes, i.e. routes that are
available directly over the link, not via routers. To specify on-
link routes, server MAY include RTPREFIX option directly in Advertise
and Reply messages.
3.3. Deleting obsolete route
There are two mechanisms that allow removing a route. Each defined
route has a route lifetime. If specific route is not refreshed and
its timer reaches 0, client MUST remove corresponding entry from
routing table.
In cases, where faster route removal is needed, server SHOULD return
RT_PREFIX option with route lifetime set to 0. Client that receives
RT_PREFIX with route lifetime set to 0 MUST remove specified route
immediately, even if its previous lifetime did not expire yet.
3.4. Applicability to routers
Contrary to Router Adverisement mechanism, defined in [RFC4861] that
explicitly limits configuration to hosts, routing configuration over
DHCPv6 defined in this document may be used by both hosts and
routers.
One of the envisaged usages for this solution are residential
gateways (RG) or Customer Premises Equipment (CPE). Those devices
very often perform routing. It may be useful to configure routing on
such devices over DHCPv6. One example of such use may be a class of
premium users that are allowed to use dedicated router that is not
available to regular users.
3.5. Updating Routing Information
Network configuration occassionally changes, due to failure of
existing hardware, migration to newer equipment or many other
reasons. Therefore there a way to inform clients that routing
information have changed is required.
There are several ways to inform clients about new routing
information. Every client SHOULD periodically refresh its
configuration, according to Information Refresh Time Option, so
Dec, et al. Expires March 13, 2012 [Page 5]
Internet-Draft DHCPv6 Route Options September 2011
server may send updated information the next time client refreshes
its information. New routes may be configured at that time. As
every route has associated lifetime, client is required to remove its
routes when this timer expires. This method is particularly useful,
when migrating to new router is undergoing, but old router is still
available.
Server MAY also announce routes via soon to be removed router with
lifetimes set to 0. This will cause the client to remove its routes,
despite the fact that previously received lifetime may not yet
expire.
Aforementioned methods are useful, when there is no urgent need to
update routing information. Bound by timer set by value of
Information Refresh Time Option, clients may use outdated routing
information until next scheduled renewal. Depending on configured
value this delay may be not acceptable in some cases. In such
scenarios, administrators are advised to use RECONFIGURE mechanism,
defined in [RFC3315]. Server transmits RECONFIRGURE message to each
client, thus forcing it to immediately start renewal process.
See also Section 3.6 about limitations regarding dynamic routing.
3.6. Limitations
Defined mechanism is not intended to be used as a dynamic routing
protocol. It should be noted that proposed mechanism cannot
automatically detect routing changes. In networks that use dynamic
routing and also employ this mechanism, clients may attempt using
routes configured over DHCPv6 even though routers or specific routes
ceased to be available. This may cause black hole routing problem.
Therefore it is not recommended to use this mechanism in networks
that use dynamic routing protocols. This mechanism SHOULD NOT be
used in such networks, unless network operator can provide a way to
update DHCP server information in case of router availability
changes.
Discussion: It should be noted that DHCPv6 server is not able to
monitor health of existing routers. As there are currently more than
60 options defined for DHCPv6, it is infeasible to implement
mechanism that would monitor huge set of services and stop announcing
its availability in case of service outage. Therefore in case of
prolonged unavailability human interverntion is required to change
DHCPv6 server configuration. If that is considered a problem,
network administrators should consider using other alternatives, like
RA and ND mechanisms (see [RFC4861]).
Dec, et al. Expires March 13, 2012 [Page 6]
Internet-Draft DHCPv6 Route Options September 2011
4. DHCPv6 Route Options
A DHCPv6 client interested in obtaining routing information includes
the NEXT_HOP and RT_PREFIX options as part of its Option Request
Option (ORO) in messages directed to a server (as allowed by
[RFC3315], i.e. Solicit, Request, Renew, Rebind or Information-
request messages). A Server, when configured to do so, provides the
requested route information using zero, one or more NEXT_HOP options
in messages sent in response (Advertise, and Reply). So as to allow
the route options to be both extensible, as well as conveying
detailed info for routes, use is made of a nested options structure.
Server sends one or more NEXT_HOP options that specify the IPv6 next
hop addresses. Each NEXT_HOP option conveys in turn zero, one or
more RT_PREFIX options that represents the IPv6 destination prefixes
reachable via the given next hop. Server includes RT_PREFIX directly
in message to indicate that given prefix is available directly on-
link. Server MAY send a single NEXT_HOP without any RT_PREFIX
suboptions or with RT_PREFIX that contains ::/0 to indicate available
default route. The Formats of the NEXT_HOP and RT_PREFIX options are
defined in the following sub-sections.
The DHCPv6 Route Options format borrows from the principles of the
Route Information Option defined in [RFC4191].
4.1. Next Hop Option Format
Each IPv6 route consists of an IPv6 next hop address, an IPv6
destination prefix (a.k.a. the destination subnet), and a host
preference value for the route. Elements of such route (e.g. Next
hops and prefixes associated with them) are conveyed in NEXT_HOP
option that contains RT_PREFIX suboptions.
The Next Hop Option defines the IPv6 address of the next hop, usually
corresponding to a specific next-hop router. For each next hop
address there can be zero, one or more prefixes reachable via that
next hop.
Dec, et al. Expires March 13, 2012 [Page 7]
Internet-Draft DHCPv6 Route Options September 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NEXT_HOP | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next Hop Address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NEXT_HOP options |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Next Hop Option Format
option-code: OPTION_NEXT_HOP (TBD).
option-len: 16 + Length of NEXT_HOP options field.
IPv6 Next Hop Address: 16 octet long field that specified IPv6
address of the next hop.
NEXT_HOP options: Options associated with this Next Hop. This
includes, but is not limited to, zero, one or more
RT_PREFIX options that specify prefixes reachable through
the given next hop.
4.2. Route Prefix Option Format
The Route Prefix Option is used to convey information about a single
prefix that represents the destination network. The Route Prefix
Option is used as a sub-option in the previously defined Next Hop
Option. It may also be sent directly in message to indicate that
route is available directly on-link.
Dec, et al. Expires March 13, 2012 [Page 8]
Internet-Draft DHCPv6 Route Options September 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RT_PREFIX | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route lifetime |
+-------------------------------+-------------------------------+
| Prefix-Length | Metric | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Prefix |
| (16 octets) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. RT_PREFIX options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Route Prefix Option Format
option-code: OPTION_RT_PREFIX (TBD).
option-len: 18 + length of RT_PREFIX options.
Route lifetime 32-bit unsigned integer. Specifies lifetime of the
route information, expressed in seconds. There are 2
special values defined. 0 means that route is no longer
valid and must be removed by clients. 0xffffffff means
infinity.
Prefix Length: 8-bit unsigned integer. The length in bits of the IP
Prefix. The value ranges from 0 to 128. This field
represents the number of valid leading bits in the prefix.
Metric: Route Metric. 8-bit signed integer. The Route Metric
indicates whether to prefer the next hop associated with
this prefix over others, when multiple identical prefixes
(for different next hops) have been received.
Prefix: Fixed length 16 octet field containing an IPv6 prefix.
RT_PREFIX options: Options specific to this particular prefix.
Dec, et al. Expires March 13, 2012 [Page 9]
Internet-Draft DHCPv6 Route Options September 2011
5. DHCPv6 Server Behavior
When configured to do so, a DHCPv6 server shall provide the Next Hop
and Route Prefix Options in ADVERTISE and REPLY messages sent to a
client that requested the route option. Each Next Hop Option sent by
the server must convey at least one Route Prefix Option.
Server includes NEXT_HOP option with possible RT_PREFIX suboptions to
designate that specific routes are available via routers. Server
includes RT_PREFIX options directly in Advertise and Reply messages
to inform that specific routes are available directly on-link.
If there is more than one route available via specific next hop,
server MUST send only one NEXT_HOP for that next hop, which contains
multiple RT_PREFIX options. Server MUST NOT send more than one
identical (i.e. with equal next hop address field) NEXT_HOP option.
Servers SHOULD NOT send Route Option to clients that did not
explicitly requested it, using the ORO.
Servers MUST NOT send Route Option in messages other than ADVERTISE
or REPLY.
Servers MAY also include Status Code Option, defined in Section 22.13
of the [RFC3315] to indicate the status of the operation.
Servers MUST include the Status Code Option, if the requested routing
configuration was not successful and SHOULD use status codes as
defined in [RFC3315] and [RFC3633].
The maximum number of routing information in one DHCPv6 message
depend on the maximum DHCPv6 message size defined in [RFC3315]
6. DHCPv6 Client Behavior
A DHCPv6 client compliant with this specification MUST request the
NEXT_HOP and RT_PREFIX Options in an Option Request Option (ORO) in
the following messages: Solicit, Request, Renew, Rebind, and
Information-Request. The messages are to be sent as and when
specified by [RFC3315].
When processing a received Route Options a client MUST substitute a
received 0::0 value in the Next Hop Option with the source IPv6
address of the received DHCPv6 message. It MUST also associate a
received Link Local next hop addresses with the interface on which
the client received the DHCPv6 message containing the route option.
Such a substitution and/or association is useful in cases where the
Dec, et al. Expires March 13, 2012 [Page 10]
Internet-Draft DHCPv6 Route Options September 2011
DHCPv6 server operator does not directly know the IPv6 next-hop
address, other than knowing it is that of a DHCPv6 relay agent on the
client LAN segment. DHCPv6 Packets relayed to the client are sourced
by the relay using this relay's IPv6 address, which could be a link
local address.
The Client SHOULD refresh assigned route information periodically.
The generic DHCPv6 Information Refresh Time Option, as specified in
[RFC4242], can be used when it is desired for the client to
periodically refresh of route information.
The routes conveyed by the Route Option should be considered as
complimentary to any other static route learning and maintenance
mechanism used by, or on the client with one modification: The client
MUST flush DHCPv6 installed routes following a link flap event on the
DHCPv6 client interface over which the routes were installed. This
requirement is necessary to automate the flushing of routes for
clients that may move to a different network.
Client MUST confirm that routers announced over DHCPv6 are reachable,
using one of methods suitable for specific network type. The most
common mechanism is Neighbor Unreachability Detection (NUD),
specified in [RFC4861]. Client SHOULD use NUD to verify that
received routers are reachable before adjusting its routing tables.
Client MAY use other reachibality verification mechanisms specific to
used network technology. To avoid potential long-lived routing black
holes, client MAY periodically confirm that router is still
reachable.
7. IANA Considerations
A DHCPv6 option number of TBD for the introduced Route Option. IANA
is requested to allocate three DHCPv6 option codes referencing this
document: OPTION_NEXT_HOP and OPTION_RT_PREFIX.
8. Security Considerations
The overall security considerations discussed in [RFC3315] apply also
to this document. The Route option could be used by malicious
parties to misdirect traffic sent by the client either as part of a
denial of service or man-in-the-middle attack. An alternative denial
of service attack could also be realized by means of using the route
option to overflowing any known memory limitations of the client, or
to exceed the client's ability to handle the number of next hop
addresses.
Dec, et al. Expires March 13, 2012 [Page 11]
Internet-Draft DHCPv6 Route Options September 2011
Neither of the above considerations are new and specific to the
proposed route option. The mechanisms identified for securing DHCPv6
as well as reasonable checks performed by client implementations are
deemed sufficient in addressing these problems.
It is essential that clients verify that announced routers are indeed
reachable, as specified in Section 6. Failing to do so may create
black hole routing problem.
This mechanism may introduce severe problems if deployed in networks
that use dynamic routing protocols. See Section 3.6 for details.
Reader is also encouraged to read DHCPv6 security considerations
document [I-D.ietf-dhc-secure-dhcpv6].
9. Contributors and Acknowledgements
This document would not have been possible without the significant
contribution provided by: Arifumi Matsumoto, Hui Deng, Richard
Johnson, and Zhen Cao.
The authors would also like to thank Alfred Hines, Ralph Droms, Ted
Lemon, Ole Troan, Dave Oran, Dave Ward, Joel Halpern, Marcin
Siodelski and Alexandru Petrescu for their comments and useful
suggestions.
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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
10.2. Informative References
[I-D.ietf-dhc-secure-dhcpv6]
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
draft-ietf-dhc-secure-dhcpv6-03 (work in progress),
Dec, et al. Expires March 13, 2012 [Page 12]
Internet-Draft DHCPv6 Route Options September 2011
June 2011.
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address
Translation",
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01 (work
in progress), August 2011.
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Authors' Addresses
Wojciech Dec (editor)
Cisco Systems
Haarlerbergweg 13-19
1101 CH Amsterdam
The Netherlands
Email: wdec@cisco.com
Tomasz Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1 650 423 1345
Email: tomasz.mrugalski@gmail.com
Dec, et al. Expires March 13, 2012 [Page 13]
Internet-Draft DHCPv6 Route Options September 2011
Tao Sun
China Mobile
Unit2, 28 Xuanwumenxi Ave
Beijing, Xuanwu District 100053
China
Phone:
Email: suntao@chinamobile.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
United States
Phone: +1 972-509-5599
Fax:
Email: sarikaya@ieee.org
URI:
Dec, et al. Expires March 13, 2012 [Page 14]
