Internet Engineering Task Force G. Chen
Internet-Draft T. Yang
Intended status: Informational L. Li
Expires: January 5, 2012 H. Deng
China Mobile
July 4, 2011
IPv6 Practices on China Mobile IP Bearer Network
draft-chen-v6ops-ipv6-bearer-network-trials-00
Abstract
This memo has introduced IPv6 practices on China Mobile IP bearer
network, in which IP backbone network and broadband access routers
have been covered. In the practice, IPv6 protocol conformance and
data packages forwarding capabiliteis have been tested in multi-
vendors environments. Several IPv6 transition schemes have been
deployed to validate interoperabilities. Based on concrete testing
data, IPv6-enable deployment experiencies have been learned to share
with community.
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 January 5, 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
publication of this document. Please review these documents
Chen, et al. Expires January 5, 2012 [Page 1]
Internet-Draft IPv6-bearer-network-trials July 2011
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Chen, et al. Expires January 5, 2012 [Page 2]
Internet-Draft IPv6-bearer-network-trials July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv6 trial on IP backbone network . . . . . . . . . . . . . . 4
2.1. IP Backbone Topology for Trials . . . . . . . . . . . . . 4
2.2. IPv6-only Routing Protocol Testing . . . . . . . . . . . . 6
2.3. Dual-stack Routing Protocol Testing . . . . . . . . . . . 7
2.4. 6PE/6vPE Protocol Testing . . . . . . . . . . . . . . . . 7
2.5. Tunnel Protocol Interoperabilities . . . . . . . . . . . . 7
2.6. IPv6 ACL and Policy Routing Configuration . . . . . . . . 8
2.7. Summary for IPv6 Trial on IP Backbone Network . . . . . . 8
3. IPv6 Testing on BRAS . . . . . . . . . . . . . . . . . . . . . 9
3.1. Test Topology . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Test Cases- Basic IPv6 protocols . . . . . . . . . . . . . 12
3.3. Test Cases- DUT in Network Test . . . . . . . . . . . . . 12
3.4. Test Cases- Performance in IPv6 environment . . . . . . . 13
3.5. Summary for BRAS Testing . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Chen, et al. Expires January 5, 2012 [Page 3]
Internet-Draft IPv6-bearer-network-trials July 2011
1. Introduction
With fast development of global Internet, the demands for IP address
are rapidly increasing at present. This year, IANA announced that
the global free pool of IPv4 depleted on 3 February. IPv6 is only
way to satisfy demands of Internet development. Operators have to
accelerate the process of deploying IPv6 networks in order to address
IP address strains.
With significant demands of service development, China Mobile has
officially kicked off first IPv6 pre-commercial trials on IP bearer
network on June 2011 after several standalone tests of IP equipment
in labs. The trials have taken place on major IP backbone network
and broadband access equipments. In order to verify IPv6 feasibility
and applicability,IPv6 protocol conformance and data packages
forwarding capabiliteis have been tested in multi-vendors
environments. Several IPv6 transition schemes, i.e. dual-stack,
6PE[RFC4789], 6vPE[RFC4659], have been deployed to validate
interoperabilities. Based on the IPv6 trials, concrete testing data
have been generated and analysed to provide informative assessment to
facilitate IPv6 deployment in next steps.
This memo has described detailed testing topology, cases and process
both on IP backbone network and BRAS. The testing results have been
summarized and analyzed to provide explicit conclusions for further
deployment.
2. IPv6 trial on IP backbone network
This section will describe IPv6 trial on IP backbone network in
details. It includes testing topoloy, testing cases. Based on
collected testing data, we have summarized testing results.
2.1. IP Backbone Topology for Trials
Figure 1 depicts the overall topology for IP backbone trials, which
is constituted by hierarchical IPv6 enable routers. The same level
would deploy double-routers due to redundancy considerations. The
top-level is national IP backbone network to connect provincial level
networks. The middle level is provincial IP backbone to connect
metropolitan area networks. The bottom level stands for core IP
routers to connect local area networks. The trials have been taken
place on these three levels. In order to simulate user-generated
data, two router testers have been positioned to access metropolitan
core routers. They have resposibilities to propagate routing
information into the network under testing.
Chen, et al. Expires January 5, 2012 [Page 4]
Internet-Draft IPv6-bearer-network-trials July 2011
/ /
/ /
O------|--------------|---------O
| +-------+ +-------+ |
| |Router | |Router | | top-level
| +-------+ +-------+ |
O------|--------------|---------O
________/\___ ______/\__________
_________/ _________\__/________ \____
/ / \ \
O-----|--------------|-------O O------|--------------|------O
| +-------+ +-------+ | | +-------+ +-------+ |
| |Router |----- |Router | | | |Router |------|Router | |
| +-------+ +-------+ | | +-------+ +-------+ |
O------|--------------|------O O------|--------------|------O
\___ _____/ middle-level \___ _____/
\ / \ /
\/ \/
+-------+ +-------+
|Router | bottom-level |Router |
+-------+ +-------+
| |
+-------+ +-------+
|Tester | |Tester |
+-------+ +-------+
Figure 1: IP Backbone Topology for Trials
The test cases mainly are composed by several parts:
o IPv6-only routing protocol interoperabilities: the test case would
shutdown IPv4 stack on tested routers. Only IPv6 stack is running
to process IPv6 EGP(i.e. BGP4+[RFC2545]) and IGP routing
protocol(i.e. OSPFv3[RFC2740] and ISIS[RFC5308]). It will
validate IPv6 routing protocol conformance in multi-vendor
environments.
o Dual-stack routing protocol interoperabilities: the tested router
would run both IPv4 and IPv6 IGP and EGP protocol simutanously.
It will verify if remote peers could totally learn spreaded IPv4/
IPv6 routing information.
o 6PE/6vPE protocol interoperabilities: the test case would require
PE routers to be upgraded to support 6PE/6vPE functionalities and
remain MPLS core network staying IPv4-enable. It will testify MP-
BGP routing learning and package forwarding capabilities.
Chen, et al. Expires January 5, 2012 [Page 5]
Internet-Draft IPv6-bearer-network-trials July 2011
o Tunnel protocol interoperabilities: the test case would configure
PE routers as 6over4 tunnel end-point. After configured 6over4
tunnel is established, the encapsulated package would be forwarded
throught MPLS network.
o IPv6 ACL and policy routing capabilities: the target of this test
case aiming at IPv6 traffic restrainability. A pair PE would be
configured with a paticular policy to constrain data forwarding
for specific IPv6 traffic. The verification will help to enhance
network security.
The following sub-sections would state testing results and related
observations.
2.2. IPv6-only Routing Protocol Testing
The testing is going to validate IPv6 routing protocol
interconnection between multi-vendor routers. OSPFv3 and ISIS have
been deployed as Interior Gateway Protocol. Based on IGP, BGP4+ has
been configured as EGP to commnunicate routing informaiton.
In the case of OSPFv3 deployment, routers on the top-level and
middle-level have been schemed as area 0, which takes responsibility
of backbone area. And, routers on the bottom-level has been
configured as area 100 and area 200 accessing to backbone area. The
testers inject IPv6 routing information to see whether propagated
IPv6 routing information can be learned by remote routers located on
the other side of bottom-level. The teting is finalized that routers
on bottom-level still remain Exstar/Exchange states. OSPFv3 can't
creates adjacencies between neighboring routers for the purpose of
exchanging routing information. After troubleshooting, IPv6 MTU
between neighboring routers is inconsistent, which causes it failed
to establish adjacencies. It is fixed by adjusting IPv6 MTU as
identical. It's recommedded that IPv6 MTU should be configured as
unified benchmark.
In the case of ISIS deployment, routers on the top-level and middle-
level have been schemed as level 2, which takes responsibility of
backbone area. And, routers on the bottom-level has been configured
as level 1. The testers inject IPv6 routing information to see
whether propagated IPv6 routing information can be learned by routers
located on level 1. The teting has found out that Multi Topology
(MT) Routing[RFC5120] in IS-IS would easily cause disorders in ISIS
routing area. It's recommedded that MT Routing in IS-IS should be
enable or disable simultaneously.
In the case of BGP4+ deployment, one of routers on top-level has been
selected as reflectors. The router on others level will establish
Chen, et al. Expires January 5, 2012 [Page 6]
Internet-Draft IPv6-bearer-network-trials July 2011
neighboring relationship with the router based on running ISIS route
protocol. The testing has shown BGP4+ is running well on IPv6-enable
network.
2.3. Dual-stack Routing Protocol Testing
Dual-stack routing testing runs IPv4 and IPv6 protocols simutanously.
The routing area planning is similiar with IPv6-only routing protocol
testing. for IPv4 routing protocol, OSPF and ISIS have been taken as
IGP and BGP has been taken as EGP. Testing has shown that routing
path have been computed by IPv4 and IPv6 routing algorithm
independently. The IPv4/IPv6 routing information learning and data
forwarding are conformed with testing expectation.
2.4. 6PE/6vPE Protocol Testing
6PE and 6vPE could shift network to provide IPv6 access depending on
existing Multiprotocol Label Switching (MPLS) [RFC3032]core network.
Operators could deploy IPv6 network without modifying IPv4 enable
MPLS cloud. In the testing, the routers on bottom-level take
responsibility of PE and routers tester simulate CE to inject IPv6
routing information and package flows. The routers on the top-level
and middle-level would still remain IPv4 enable situation. MPLS
protocol has been configured on these routers. During the testing,
tester would serve for CE to inject routing information. In the case
of 6PE, the tester will propagate normal IPv6 IGP routing information
to the PE. In the case of 6vPE, the tester would generate IPv6 VPN
routing information to communicate with remote peer through MP-BGP.
The testing shown remote peers could learn total IPv6 routing
information through MPLS enable cloud. The basic funcationalities of
6PE/6vPE are going well in the testing network. The caution has been
raised by forwarding big data packages. The intermedia routers would
like to drop big packages surpassing network MTU since they can't
fragment big package in the middle of the forwording path. The data
fragmentation functionalities are taken by initiated router.
Therefore, it's recommedded that the package size do not exceed
network MTU by configuring maximum MTU on initiated router or
enabling Path MTU Discovery on initiated router.
2.5. Tunnel Protocol Interoperabilities
Tunnel protocol requires dedicated board to support. The testing is
focusing on configured 6over4 tunnel. In order to coordinate with
existing deployed MPLS cloud. The tunnel end-point has been located
on PE routers. In this case, IPv6 package is expected encapsulated
in IPv4 package going through MPLS network, in which additional MPLS
header with lable would route 6over4 packages into remote peer.
Therefore, the transmitted IPv6 data packages are not only
Chen, et al. Expires January 5, 2012 [Page 7]
Internet-Draft IPv6-bearer-network-trials July 2011
encapulated in native IPv4 package, but headed into MPLS tunnel.
Double tunneling is requested in this situation. According to the
testing results, router are failed to support such encapsulation
manner. The tunnel board can't forward data packages carrying both
tunnel id and MPLS lable. However, MPLS encapsulation supporting is
essential for IP bearer network since MPLS is widely deployed.
2.6. IPv6 ACL and Policy Routing Configuration
IPv6 ACL(Access Control List) will help to reduce potential risks of
harmful invasion by preventing IPv6 traffic from a specific source
address or network to a specified destination network. In the test
scenario, the routers have been configured as IPv6-enable. Routers
on bottle-level have configured with ACL deny policies which have
applied for both outbound and inbound IPv6 traffics. Testers would
inject IPv6 traffic to the routers to validate if the ACL takes
effect. The results shown that only outbound ACL deny policies is
valid. And inbound policies are failed to constrain IPv6 traffic due
to the lacking of supports from the router board.
Another testing is taken place at policy routing redistribution
through BGP4+. An restricted routing policy would be added into
BGP4+ UPDATE message to propagate into the remote peer. After the
testing, the remote peer could suceessfully learn the redistributed
routing policies and take effect to limite paticular IPv6 traffic .
2.7. Summary for IPv6 Trial on IP Backbone Network
In general, the tests on several aspects indicate that IPv6-enable
backbone network has already qualified for carrying IPv6 data
packages in IPv6-only or dual-stack conditions. The IPv6 routing
protocol has mature supporting in current routers. It also shows
high-interoperabilities in multi-vendor environments. According to
testing results, two points needed to be highlighted for next step in
IPv6 deployment:
o MTU configuration needs to be carefully configured and checked up.
The inappropriate MTU configuration will cause failures of IGP
neighboring establishement and packages dropping. The unified
maxmum MTU configuration is recommended.
o Multi Topology (MT) Routing in IS-IS should be configured in
unified manner to avoid routing disorders in ISIS area.
o Compared to other tunneling technologies, 6PE and 6vPE are
recommended to be deployed on IP bearer network, in which MPLS is
widely enable.
Chen, et al. Expires January 5, 2012 [Page 8]
Internet-Draft IPv6-bearer-network-trials July 2011
3. IPv6 Testing on BRAS
BRAS is the key equipment in MAN, it distributes IP addressess to the
subscribers through DHCP protocols, authorize the subscribers to log
on, and calculate their online time for billing. It is the "central
control node" in MAN.
In the past several years, BRAS helped ISPs to control and record the
subscribers' bahaviors in IPv4 networks. Along with IPv6 approaching
day by day, several BRAS manufacturers announce their equipments
could support IPv6 functions. In order to checkout that, we carried
on testing five types of BRAS produced by four manufacturers.
Test results show that BRAS's IPv6 functions and capabilities are not
optimistic. The following subsections describe the specific results
of the tests.
3.1. Test Topology
We tested BRAS in four network scenarios in our labotory. The first
scenario checks out the basic IPv6 protocols in stand-alone
environment, the following two mostly test the DUTs' communicating
ability in networks, and the last simplest configuration verifies the
BRAS performance in IPv6 environment.
+------+
| IPv4 +--+
| host | | +-----+
+------+ +--+ CPE +--+ -----
+------+ | +-----+ | / \
| IPv4/+--+ | | IPv4 |
| IPv6 | | + Network +
| host | | / \ / \
+------+ | +-------+ +---+ ----- +-----+
Meter Simulation------>| Test +---+DUT| |Test |
| | Meter | | | |Meter|
| |(v4/v6)| | | | |
+-------+ +-----+ | +-------+ +---+ ----- +-----+
|Client +----+DSLAM+--+ \ / \ /
| node | | | | + IPv6 +
+-------+ +-----+ | | Network |
| \ /
+-------+ +-----+ | -----
|Client +----+ AP +--+
| node | | |
+-------+ +-----+
Figure 2: Test Topology 1 (stand-lone test)
Chen, et al. Expires January 5, 2012 [Page 9]
Internet-Draft IPv6-bearer-network-trials July 2011
+-------+
| Test |
| Meter |
|(v4/v6)+---+
+-------+ |
+------+ |
| IPv4 +--+ | +--------+
| host | | | ---- | Riadus |
+------+ | +---+ +---------+ / \ | Server |
+---+CPE+---+ BRAS +---+ +--+--------+
+------+ | +---+ | (IPv4) | | | +--------+
| IPv4/+--+ +---|--|--+ | | | |
| IPv6 | | | | | +--+ DHCP |
| host | | | | | | | Server |
+------+ | | | | | +--------+
| | | | |
+------+ +-----+ | | | | +--+--------+
+Client+---+DSLAM+---+ | | | | | Portal |
+------+ +-----+ | | | | | |
| | | IPv4/ | +--------+ ----
L2TP Tunnel-->| | | IPv6 | / \
| | |Network | | IPv4 |
+-------+ | | | | +Internet|
| Test | | | | | | |
| Meter | | | | | / \ /
|(v4/v6)+---+ | | | | +--------+ ----
+-------+ | | | | | | Test |
+------+ | | | |6PE/6VPE| | Meter |
| IPv4 +--+ | | | | | | +---+----+ ----
| host | | | | | | | | | \ / \
+------+ | +---+ +---|--|--+ | V | +---+--+ + IPv6 |
+---+CPE+---+ DUT ----------------- M320 | |Internet|
+------+ | +---+ |(IPv4/v6)----------------- | \ /
| IPv4/+--+ +---------+---+ | +------+ ----
| IPv6 | | + +
| host | | | |
+------+ | \ /
| ----
+------+ +-----+ |
|Client+---+DSLAM+---+
+------+ +-----+
Figure 3: Test Topology 2 (DUT in networks)
Chen, et al. Expires January 5, 2012 [Page 10]
Internet-Draft IPv6-bearer-network-trials July 2011
-----
/ \
+ IPv4 +
| Network |
+ +---+
/ \ / |
+-------+ +-----------+ +-----+ ----- +----+---------+
| Test | |Aggregation| | | | Test |
| Meter +---+ Switch +----+ DUT | | Meter |
|(v4/v6)| | | | | | (v4/v6) |
+-------+ +-----------+ +-----+ ----- +----+---------+
\ / \ |
+ IPv6 +---+
| Network |
+ +
\ /
-----
Figure 4: Test Topology 3 (DUT in networks)
----------
/ \
+ IPv4 +
| Network |
+ +-----+
/ \ / |
+-------+ +--------+ ---------- +-----+-----------+
| Test | | | | Test |
| Meter +-------+ DUT | | Meter |
|(v4/v6)| | | | (v4/v6) |
+-------+ +--------+ ---------- +-----+-----------+
\ / \ |
+ IPv6 +-----+
| Network |
+ +
\ /
----------
Figure 5: Test Topology 4 (performance Test)
Chen, et al. Expires January 5, 2012 [Page 11]
Internet-Draft IPv6-bearer-network-trials July 2011
3.2. Test Cases- Basic IPv6 protocols
Along with devices transiting from IPv4 to IPv6, BRAS's IP-based
protocol stack will undergo a major change. Some new protocols will
come into being, and some existenced protocols' features will be
changed, such as NDP, MLD,ICMPv6, DHCPv6, etc. We tested the BRAS
equipments' new features particularly. At the same time, we also did
some experiments on L2 or L4 protocols, such as TCP, UDP, PPP, to
verify whether they can work well in IPv6 environment.
Testing conclusions show that all the equipments made by four
manufacturers can support the basic IPv6, ICMPv6, TCP, UDP, PPP, and
IPv6 routing protocols, but just two devices can pass most of the
access functions test cases.
The most serious problem is that two DUTs do not support DHCP server
functions in IPv6, which causes a negative impact when the BRAS
distributes IPv6 addresses to the subscrtibers or even does DHCP-PD,
because there are not local IPv6 address pool in the devices. ISPs
must purchase IPv6 DHCP servers additionally.
The second trouble is about multicast. One DUT does not only support
MLD protocols but PIM-SM which has noting to do with IPv6 or IPv4.
Another two cannot duplicate multicast stream for each subscrtiber
neither in PPPoE nor IPoE. considering this problem, ISPs can hardly
carry out trible-play, such as IPTV, by deploying these devices.
At last, only one DUT does not support local PPPoEv6 authentication.
3.3. Test Cases- DUT in Network Test
In order to achieve the gradual transition from IPv4 to IPv6, and to
protect the investment of the deployed devices in the current
networks, IPv6 BRAS must have the ability to set L2TP tunnel with
IPv4 BRAS, and should support IPv6 over IPv4 tunnel with IPv6 router.
We did the experiment in topology 2 and 3 in our lab.
One of the problems is about L2TP tunnel. In scenario 2, IPv6 client
initiates a PPPoE access request to the IPv4 BRAS, which sets up an
L2TP tunnel with the DUT (IPv6 BRAS) after it get the client's IPv6
attribute form the Radius server. But unfortunately, the IPv6 client
can not get an IPv6 address or prefix. This situation has taken
placed on three manufacturers' DUTs because of their IPv6CP function.
BRAS must record subscribers' online time and traffic information,
which is a basic function in IPv4. We test that in topology 2, all
the DUTs can make a record, but three of them cannot distinguish IPv6
and IPv4 for a dual-stack client. That means ISPs could not charge
Chen, et al. Expires January 5, 2012 [Page 12]
Internet-Draft IPv6-bearer-network-trials July 2011
separately according to the tradffic is IPv4 or IPv6, which is very
important for developing IPv6 if ISPs want to charge IPv6 traffic
cheaper than IPv4 in the early of the IPv4-IPv6 transition years.
3.4. Test Cases- Performance in IPv6 environment
We also tested the BRAS capability in IPv6 environment in topology 4.
The test cases inclued FIB capacity, ACL quantity, QoS queue
quantity, and line card IPv6 throughput.
Performance test conclusions demonstrate that the DUTs' capability do
not drop so much in IPv6 networks than in IPv4. The main problems
are listed below.
One DUT's IPv6 FIB capacity is only 10% of its IPv4 FIB capacity
because the related resouces, such as Memory, are designed separately
but not shared. But we do not consider that is a serious problem,
because the design will certainly be changed if IPv6 traffic
increasing over IPv4 traffic in current networks.
One DUT's line card throughput is much less than the nominal value
when the packet length shorter than 128B no matter it is IPv4 or
IPv6.
3.5. Summary for BRAS Testing
The specific testing results show that only one DUT's IPv6 functions
can basicly meet the requirement of current networks experiment or
commercial trial. The IPv6 device industy need to be pay more
attention by all the ISPs and manufacturers.
4. IANA Considerations
This document has no IANA actions.
5. Security Considerations
TBD
6. Normative References
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
March 1999.
Chen, et al. Expires January 5, 2012 [Page 13]
Internet-Draft IPv6-bearer-network-trials July 2011
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
[RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network
Management Protocol (SNMP) over IEEE 802 Networks",
RFC 4789, November 2006.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
October 2008.
Authors' Addresses
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: chengang@chinamobile.com
Tianle Yang
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: yangtianle@chinamobile.com
Chen, et al. Expires January 5, 2012 [Page 14]
Internet-Draft IPv6-bearer-network-trials July 2011
Lianyuan Li
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13910750201
Email: lilianyuan@chinamobile.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13910750201
Email: denghui02@gmail.com
Chen, et al. Expires January 5, 2012 [Page 15]