Network Working Group Q. Sun
Internet-Draft C. Xie
Intended status: Standards Track China Telecom
Expires: January 17, 2013 Y. Lee
Comcast
M. Chen
FreeBit
July 16, 2012
Deployment Considerations for Lightweight 4over6
draft-sun-softwire-lightweight-4over6-deployment-02
Abstract
Lightweight 4over6 is a mechanism which moves the translation
function from tunnel Concentrator (AFTR) to Initiators (B4s), and
hence reduces the mapping scale on the Concentrator to per-customer
level. This document discusses various deployment models of
Lightweight 4over6. It also describes the deployment considerations
and applicability of the Lightweight 4over6 architecture.
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 17, 2013.
Copyright Notice
Copyright (c) 2012 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
Sun, et al. Expires January 17, 2013 [Page 1]
Internet-Draft lightweigh-4over6-deployment July 2012
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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Model . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overall Deployment Considerations . . . . . . . . . . . . . . 7
4.1. Addressing and Routing . . . . . . . . . . . . . . . . . . 7
4.2. Port-set Management . . . . . . . . . . . . . . . . . . . 7
4.3. Concentrator Discovery . . . . . . . . . . . . . . . . . . 7
5. Concentrator Deployment Consideration . . . . . . . . . . . . 9
5.1. Logging at the Concentrator . . . . . . . . . . . . . . . 9
5.2. Reliability Considerations of Concentrator . . . . . . . . 9
5.3. Placement of AFTR . . . . . . . . . . . . . . . . . . . . 9
5.4. Port set algorithm consideration . . . . . . . . . . . . . 10
6. DS-Lite Compatibility . . . . . . . . . . . . . . . . . . . . 11
6.1. Case 1: Integrated Network Element with Lightweight
4over6 and DS-Lite AFTR Scenario . . . . . . . . . . . . . 11
6.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR . 12
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix 1. Appendix:Experimental Result . . . . . . . . . . . . 16
1.1. Experimental environment . . . . . . . . . . . . . . . . . 16
1.2. Experimental results . . . . . . . . . . . . . . . . . . . 17
1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Sun, et al. Expires January 17, 2013 [Page 2]
Internet-Draft lightweigh-4over6-deployment July 2012
1. Introduction
Lightweight 4over6 [I-D.cui-softwire-b4-translated-ds-lite] is an
extension to DS-Lite which simplifies the AFTR module [RFC6333] with
distributed NAT function among B4 elements. The Initiator in
Lightweight 4over6 is provisioned with an IPv6 address, an IPv4
address and a port-set. It performs NAPT on end user's packets with
the provisioned IPv4 address and port-set. IPv4 packets are
forwarded between the Initiator and the Concentrator over a Softwire
using IPv4-in-IPv6 encapsulation. The Concentrator maintains one
mapping entry per subscriber with the IPv6 address, IPv4 address and
port-set. Therefore, this extension removes the NAT44 module from
the AFTR and replaces the session-based NAT table to a per-subscriber
based mapping table. This should relax the requirement to create
dynamic session-based log entries. This mechanism preserves the
dynamic feature of IPv4/IPv6 address binding as in DS-Lite, so it has
no coupling between IPv6 address and IPv4 address/port-set as any
full stateless solution ([RFC6052] or [I-D.ietf-softwire-map])
requires. This document discusses deployment models of Lightweight
4over6. It also describes the deployment considerations and
applicability of the Lightweight 4over6 architecture.
Terminology of this document follows the definitions and
abbreviations of [I-D.cui-softwire-b4-translated-ds-lite].
Sun, et al. Expires January 17, 2013 [Page 3]
Internet-Draft lightweigh-4over6-deployment July 2012
2. 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 [RFC2119].
Sun, et al. Expires January 17, 2013 [Page 4]
Internet-Draft lightweigh-4over6-deployment July 2012
3. Deployment Model
Lightweight 4over6 is suitable for operators who would like to free
any correlation of the IPv6 address with IPv4 address and port-set
(or port-range). In comparison to full stateless solutions like MAP
[I-D.ietf-softwire-map] and 4rd [I-D.ietf-softwire-4rd], Lightweight
4over6 frees address planning of IPv6 delegation for CPE from mapping
rule administration and management in the network. Thus, IPv6
addressing is completely flexible to fit other deployment
requirements, e.g., auto-configuration, service classification, user
management, QoS support, etc. The philosophy here is that bits of
IPv6 address should be left for IPv6 usage first.
Lightweight 4over6 can be deployed in a residential network (depicted
in Figure1). In this scenario, an Initiator would acquire an IPv4
address and a port-set after a successful user authentication process
and IPv6 provisioning process. Then, it establishes an IPv4-in-IPv6
softwire using the IPv6 address to deliver IPv4 services to its
connected host via the Concentrator in the network. The Initiator
can act as a CPE, or software located in the host. The Concentrator
supports Lightweight 4over6 which keeps the mapping between
Initiator's IPv6 address and its allocated IPv4 address + port set.
The supporting server may keep the binding information as well for
logging and user management.
+---------------+
| Supporting |
| Server |
+-------+-------+
|
+---------------+--------------|
| | |
+---------+ +------+---+ +--+--+ |
| Host | | LW 4over6| | | |
| |--| Initiator| ======-| BNG | === +---------+ +-----------+
+---------+ +----------+ +--|--+ |LW 4over6| | IPv4 |
|Concen- |---| Internet |
+---------+ +------+---+ +--+--+ |trator | | |
| Host |--| LW 4over6| =======| | ====+---------+ +-----------+
| | | Initiator| | BNG | |
+---------+ +----------+ +--|--+ |
+ | |
+---------------+--------------+
Figure 1 Deployment Model
There are two deployment models in practice: one is called bottom-up
and the other is top-down. In bottom-up model, after port-restricted
Sun, et al. Expires January 17, 2013 [Page 5]
Internet-Draft lightweigh-4over6-deployment July 2012
IPv4 address is allocated to a given subscriber, the Concentrator
will report mapping records to the support server on creating a
binding for traffic logging if necessary. In this way, the
Concentrator can determine the binding by its own and there is little
impact on existing network architecture. In top-down model, the
Supporting system should firstly determine the binding information
for each subscriber and then synchronize it with the Concentrator.
With this method, one binding record can be easily synchronized with
multiple Concentrators and stateless failover can be achieved.
However, new mechanism (e.g. Netconf) needs to be introduced to
notify each individual binding record between the Supporting system
and the Concentrator.
Sun, et al. Expires January 17, 2013 [Page 6]
Internet-Draft lightweigh-4over6-deployment July 2012
4. Overall Deployment Considerations
4.1. Addressing and Routing
In Lightweight 4over6, there is no inter-dependency between IPv4 and
IPv6 addressing schemes. IPv4 address pools are configured
centralized in Concentrator for IPv6 subscribers. These IPv4 prefix
must advertise to IPv4 Internet accordingly.
For IPv6 addressing and routing, there are no additional addressing
and routing requirements. The existing IPv6 address assignment and
routing announcement should not be affected. For example, in PPPoE
scenario, a CPE could obtain a prefix via prefix delegation
procedure, and the hosts behind CPE would get its own IPv6 addresses
within the prefix through SLAAC or DHCPv6 statefully. This IPv6
address assignment procedure has nothing to do with restricted IPv4
address allocation.
4.2. Port-set Management
In Lightweight 4over6, each Initiator will get its restricted IPv4
address and a valid port-set after successful user authentication
process and IPv6 provisioning process. This port-set assignment
should be synchronized between port management server and the
Concentrator. The port management server is responsible for
allocating port restricted IPv4 address to the Initiator. It can be
new option to the DHCPv4 server [I-D.bajko-pripaddrassign]. The
DHCPv4 server can either be collocated in the Concentrator or a
dedicated server.
Different mechanisms including PCP- extended protocol
[I-D.tsou-pcp-natcoord], DHCP-extended protocol or IPCP-extended
protocol, etc., can also be used.
Compared with DHCP-based mechanism, PCP-based mechanism is more
flexible. An Initiator can send multiple PCP requests simultaneously
to acquire a number of ports or use [I-D.tsou-pcp-natcoord] for one-
time port-set allocation.
4.3. Concentrator Discovery
A Lightweight 4over6 Initiator must discover the Concentrator's IPv6
address before offering any IPv4 services. This IPv6 address can be
learned through an out-of-band channel, static configuration, or
dynamic configuration. In practice, Lightweight 4over6 Initiator can
use the same DHCPv6 option [RFC6334]to discover the FQDN of the
Concentrator. When Lightweight 4over6 is deployment in the same
place with DS-Lite, different FQDNs can be configured for Lightweight
Sun, et al. Expires January 17, 2013 [Page 7]
Internet-Draft lightweigh-4over6-deployment July 2012
4over6 and DS-Lite separately ( More detailed consideration on DS-
Lite compatibility will be discussed in Section...).
Sun, et al. Expires January 17, 2013 [Page 8]
Internet-Draft lightweigh-4over6-deployment July 2012
5. Concentrator Deployment Consideration
As Lightweight 4over6 is an extension to DS-Lite, both technologies
share similar deployment considerations. For example: Interface
consideration, MTU, Fragment, Lawful Intercept Considerations,
Blacklisting a shared IPv4 Address, AFTR's Policies, AFTR Impacts on
Accounting Process, etc., in [I-D.ietf-softwire-dslite-deployment]
can also be applied here. This document only discusses new
considerations specific to Lightweight 4over6.
5.1. Logging at the Concentrator
In Lightweight 4over6, operators only log one entry per subscriber.
The log should include subscriber's IPv6 address used for the
softwire, the public IPv4 address and the port-set. The port set
algorithm implemented in Lightweight 4over6 Concentrator should be
synchronized with the one implemented in logging system. For
example, if contiguous port set algorithm is adopted in the
Concentrator, the same algorithm should also been applied to the
logging system.
5.2. Reliability Considerations of Concentrator
In Lightweight 4over6, subscriber to IPv4 and port-set mapping must
be pre-provisioned in the Concentrator before providing IPv4 serives.
For redundancy, the backup Concentrator must either have the
subscriber mapping already provisioned or notify the Initiator to
create a new mapping in the backup Concentrator. The first option
can be consider as hot standby mode. The second option may require a
new notification mechanism which is outside the scope of this
document.
5.3. Placement of AFTR
The Concentrator can be deployed in a "centralized model" or a
"distributed model".
In the "centralized model", the Concentrator could be located at the
higher place, e.g. at the exit of MAN, etc. Since the Concentrator
has good scalability and can handle numerous concurrent sessions, we
recommend to adopt the "centralized model" for Lightweight 4over6 as
it is cost-effective and easy to manage.
In the "distributed model", Concentrator is usually integrated with
the BRAS/SR. Since newly emerging customers might be distributed in
the whole Metro area, we have to deploy Concentrator on all BRAS/SRs.
This will cost a lot in the initial phase of the IPv6 transition
period.
Sun, et al. Expires January 17, 2013 [Page 9]
Internet-Draft lightweigh-4over6-deployment July 2012
5.4. Port set algorithm consideration
If each Initiator is given a set of ports, port randomization
algorithm can only select port in the given port-set. This may
introduce security risk because hackers can make a more predictable
guess of what port a subscriber may use. Therefore, non-continuous
port set algorithms (e.g. as defined in [I-D.ietf-softwire-map]) can
be used to improve security.
Sun, et al. Expires January 17, 2013 [Page 10]
Internet-Draft lightweigh-4over6-deployment July 2012
6. DS-Lite Compatibility
Lightweight 4over6 can be either deployed all alone, or combined with
DS-Lite [RFC6333]. Since Lightweight 4over6 does not any have extra
requirement on IPv6 addressing, it can use use the same addressing
scheme with DS-Lite, together with routing policy, user management
policy, etc. Besides, the bottom-up model has quite similar
requirement and workflow on the support server with DS-Lite.
Therefore, it is suitable for operators to deploy incrementally in
existing DS-Lite network
6.1. Case 1: Integrated Network Element with Lightweight 4over6 and DS-
Lite AFTR Scenario
In this case, DS-Lite has been deployed in the network. Later in the
deployment schedule, the operator decided to implement Lightweight
4over6 Concentrator function in the same network element(depicted in
Figure2). Therefore, the same network element needs to support both
transition mechanisms.
There are two options to distinguish the traffic from two transition
mechanisms.
The first one is to distinguish using the client's source IPv4
address. The IPv4 address from Lightweight 4over6 is public address
as NAT has been done in the Initiator, and IPv4 address for DS-lite
is private address as NAT will be done on AFTR. When the network
element receives an encapsulated packet, it would de-capsulate packet
and apply the transition mechanism based on the IPv4 source address
in the packet. This requires the network element to examine every
packet and may introduce significant extra load to the network
element. However, both the B4 element and Lightweight 4over6
Initiator can use the same DHCPv6 option [RFC6334] with the same FQDN
of the AFTR and Concentrator.
The second one is to distinguish using the destination's tunnel IPv6
address. One network element can run separated instances for
Lightweight 4over6 and DS-Lite with different tunnel addresses. Then
B4 element and Lightweight 4over6 Initiator can use the same DHCPv6
option [RFC6334] with different FQDNs pointing to corresponding
tunnel addresses. This requires the support server should
distinguish different types of users when assigning the FQDNs in
DHCPv6 process.
+---------------+--------------|
+ | |
+---------+ +------+---+ +--+--+ |
| Host | | LW 4over6| | | |
Sun, et al. Expires January 17, 2013 [Page 11]
Internet-Draft lightweigh-4over6-deployment July 2012
| |--| Initiator| ======-| BNG | === +-------------+ +-----------+
+---------+ +----------+ +--|--+ |LW 4over6 | | IPv4 |
|Concentrator/|---| Internet |
+---------+ +------+---+ +--+--+ |DS-Lite AFTR | | |
| Host |--| DS-Lite | =======| | ====+-------------+ +-----------+
| | | B4 | | BNG | |
+---------+ +----------+ +--|--+ |
+ | |
+---------------+--------------+
Figure 2 DS-Lite Coexistence scenario with Integrated AFTR
6.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR
This is similar to Case 1. The difference is the Concentrator and
AFTR functions won't be co-located in the same network element
(depicted in Figure3). This use case decouples the functions to
allow more flexible deployment. For example, an operator may deploy
AFTR closer to the edge and Concentrator closer to the core.
Moreover, it does not require the network element to pre-configure
with the CPE's IPv6 addresses. An operator can deploy more AFTR and
Concentrator at needed. However, this requires the B4 and Initiator
to discover the corresponding network element. In this case, B4
element and Lightweight 4over6 Initiator can still use [RFC6334] with
different FQDNs pointing to corresponding tunnel end-point addresses,
and the support server should distinguish different types of
users.
+---+---------------+-----------------|
+ | |
+---------+ +------+---+ +------+-----+ |
| Host | | LW 4over6| | BNG | |
| |--| Initiator| ======-|DS-Lite AFTR| === +------------+ +-----------+
+---------+ +----------+ +------+-----+ |LW 4over6 | | IPv4 |
|Concentrator|---| Internet |
+---------+ +------+---+ +------+-----+ | | | |
| Host |--| DS-Lite | =======| BNG | ====+------------+ +-----------+
| | | B4 | |DS-Lite AFTR| |
+---------+ +----------+ +------+-----+ |
+ | |
+-------------------+-----------------+
Figure 3 DS-Lite Coexistence scenario with Seperated AFTR
Sun, et al. Expires January 17, 2013 [Page 12]
Internet-Draft lightweigh-4over6-deployment July 2012
7. Acknowledgement
TBD
Sun, et al. Expires January 17, 2013 [Page 13]
Internet-Draft lightweigh-4over6-deployment July 2012
8. References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-04 (work in progress),
April 2012.
[I-D.bsd-softwire-stateless-port-index-analysis]
Skoberne, N. and W. Dec, "Analysis of Port Indexing
Algorithms",
draft-bsd-softwire-stateless-port-index-analysis-00 (work
in progress), September 2011.
[I-D.cui-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
transport", draft-cui-dhc-dhcpv4-over-ipv6-00 (work in
progress), October 2011.
[I-D.cui-softwire-b4-translated-ds-lite]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the DS-Lite
Architecture", draft-cui-softwire-b4-translated-ds-lite-07
(work in progress), July 2012.
[I-D.cui-softwire-host-4over6]
Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
Lee, "Public IPv4 over Access IPv6 Network",
draft-cui-softwire-host-4over6-06 (work in progress),
July 2011.
[I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
Transport", draft-ietf-dhc-dhcpv4-over-ipv6-03 (work in
progress), May 2012.
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-26 (work in progress), June 2012.
[I-D.ietf-softwire-4rd]
Despres, R., Penno, R., Lee, Y., Chen, G., and S. Jiang,
"IPv4 Residual Deployment via IPv6 - a unified Stateless
Solution (4rd)", draft-ietf-softwire-4rd-02 (work in
progress), June 2012.
[I-D.ietf-softwire-dslite-deployment]
Sun, et al. Expires January 17, 2013 [Page 14]
Internet-Draft lightweigh-4over6-deployment July 2012
Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
Boucadair, "Deployment Considerations for Dual-Stack
Lite", draft-ietf-softwire-dslite-deployment-03 (work in
progress), March 2012.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima,
S., and T. Murakami, "Mapping of Address and Port (MAP)",
draft-ietf-softwire-map-01 (work in progress), June 2012.
[I-D.murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
[I-D.sun-v6ops-laft6]
Sun, Q. and C. Xie, "LAFT6: Lightweight address family
transition for IPv6", draft-sun-v6ops-laft6-01 (work in
progress), March 2011.
[I-D.tsou-pcp-natcoord]
Sun, Q., Boucadair, M., Deng, X., Zhou, C., and T. Tsou,
"Using PCP To Coordinate Between the CGN and Home Gateway
Via Port Allocation", draft-tsou-pcp-natcoord-05 (work in
progress), March 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011.
[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
T. Tsou, "Huawei Port Range Configuration Options for PPP
IP Control Protocol (IPCP)", RFC 6431, November 2011.
Sun, et al. Expires January 17, 2013 [Page 15]
Internet-Draft lightweigh-4over6-deployment July 2012
1. Appendix:Experimental Result
We have deployed Lightweight 4over6 in our operational network of
HuNan province, China. It is designed for broadband access network,
and different versions of Initiator have been implemented including a
linksys box, a software client for windows XP, vista and Windows 7.
It can be integrated with existing dial-up mechanisms such as PPPoE,
etc. The major objectives listed below aimed to verify the
functionality and performance of Lightweight 4over6:
o Verify how to deploy Lightweight 4over6 in a practical network.
o Verify the impact of applications with Lightweight 4over6.
o Verify the performance of Lightweight 4over6.
1.1. Experimental environment
The network topology for this experiment is depicted in Figure 2.
+--------+
+-----+ +---------+ | Syslog |
|Host1+--+Initiator|--+ | Server | --------
+-----+ +---------+ | +---+----+ /// \\\
| /------\ | // \\
| // \\ +---+----+ | |
+-----+ +---------+ +-+--+ | IPv6 | | | | IPv4 Internet |
|Host2+--|Initiator|--+BRAS+--| Network |---| Concen-+-+ |
+-----+ +---------+ +-+--+ \\ // | trator | \\ //
| \---+--/ +--------+ \\\ ///
| | ---------
+-----+ +---------+ | |
|Host3+--+Initiator+---+ |
+-----+ +---------+ | --------
| // \\
| / \
+---------------------+IPv6 Internet +
| |
\ /
\\ //
-------
Figure 2 Lightweight 4over6 experiment topology
In this deployment model, Concentrator is co-located with a extended
PCP server to assign restricted IPv4 address and port set for
Initiator. It also triggers subscriber-based logging event to a
centrilized syslog server. IPv6 address pools for subscribers have
Sun, et al. Expires January 17, 2013 [Page 16]
Internet-Draft lightweigh-4over6-deployment July 2012
been distributed to BRASs for configuration, while the public
available IPv4 address pools are configured by the centralized
Concentrator with a default address sharing ratio. It is rather
flexible for IPv6 addressing and routing, and there is little impact
on existing IPv6 architecture.
In our experiment, Initiator will firstly get its IPv6 address and
delegated prefix through PPPoE, and then initiate a PCP-extended
request to get public IPv4 address and its valid port set. The
Concentrator will thus create a subscriber-based state accordingly,
and notify syslog server with {IPv6 address, IPv4 address, port set,
timestamp}.
1.2. Experimental results
In our trial, we mainly focused on application test and performance
test. The applications have widely include web, email, Instant
Message, ftp, telnet, SSH, video, Video Camera, P2P, online game,
voip and so on. For performance test, we have measured the
parameters of concurrent session numbers and throughput performance.
The experimental results are listed as follows:
+--------------------+----------------------+-----------------------+
| Application Type | Test Result |Port Number Occupation |
+--------------------+----------------------+-----------------------+
| Web | ok | normal websites: 10~20|
| | IE, Firefox, Chrome | Ajex Flash webs: 30~40|
+--------------------+----------------------+-----------------------+
| Video | ok, web based or | 30~40 |
| | client based | |
+--------------------+----------------------+-----------------------+
| Instant Message | ok | |
| | QQ, MSN, gtalk, skype| 8~20 |
+--------------------+----------------------+-----------------------+
| P2P | ok | lower speed: 20~600 |
| |utorrent,emule,xunlei | (per seed) |
| | | higher speed: 150~300 |
+--------------------+----------------------+-----------------------+
| FTP | need ALG for active | 2 |
| | mode, flashxp | |
+--------------------+----------------------+-----------------------+
| SSH, TELNET | ok |1 for SSH, 3 for telnet|
+--------------------+----------------------+-----------------------+
| online game | ok for QQ, flash game| 20~40 |
+--------------------+----------------------+-----------------------+
Figure 3 Lightweight 4over6 experimental result
Sun, et al. Expires January 17, 2013 [Page 17]
Internet-Draft lightweigh-4over6-deployment July 2012
The performance test for Concentrator is taken on a normal PC. Due
to limitations of the PC hardware, the overall throughput is limited
to around 800 Mbps. However, it can still support more than one
hundred million concurrent sessions.
1.3. Conclusions
From the experiment, we can have the following conclusions:
o Lightweight 4over6 has good scalability. As it is a lightweight
solution which only maintains per-subscription state information,
it can easily support a large amount of concurrent subscribers.
o Lightweight 4over6 can be deployed rapidly. There is no
modification to existing addressing and routing system in our
operational network. And it is simple to achieve traffic logging.
o Lightweight 4over6 can support a majority of current IPv4
applications.
Sun, et al. Expires January 17, 2013 [Page 18]
Internet-Draft lightweigh-4over6-deployment July 2012
Authors' Addresses
Qiong Sun
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552936>
Email: sunqiong@ctbri.com.cn
Chongfeng Xie
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552116>
Email: xiechf@ctbri.com.cn
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
USA
Email: yiu_lee@cable.comcast.com
Maoke Chen
FreeBit Co., Ltd.
13F E-space Tower, Maruyama-cho 3-6
Shibuya-ku, Tokyo 150-0044
Japan
Email: fibrib@gmail.com
Sun, et al. Expires January 17, 2013 [Page 19]