Deployment Considerations for Lightweight 4over6
draft-sun-softwire-lightweigh-4over6-deployment-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Qiong Sun , Chongfeng Xie , Yiu Lee | ||
| Last updated | 2012-03-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sun-softwire-lightweigh-4over6-deployment-00
Network Working Group Q. Sun
Internet-Draft C. Xie
Intended status: Standards Track China Telecom
Expires: September 6, 2012 Y. Lee
Comcast
March 5, 2012
Deployment Considerations for Lightweight 4over6
draft-sun-softwire-lightweigh-4over6-deployment-00
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 September 6, 2012.
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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Sun, et al. Expires September 6, 2012 [Page 1]
Internet-Draft lightweigh-4over6-deployment March 2012
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. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. case 1: Standalone Deployment Scenario . . . . . . . . . . 5
3.2. case 2: DS-Lite Coexistent scenario with Integrated
AFTR . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. case 3: DS-Lite Coexistent scenario with Seperated AFTR . 6
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. Common considerations with DS-Lite deployment . . . . . . 9
5.2. Logging at the Concentrator . . . . . . . . . . . . . . . 9
5.3. Reliability Considerations of Concentrator . . . . . . . . 9
5.4. Placement of AFTR . . . . . . . . . . . . . . . . . . . . 9
5.5. Port set algorithm consideration . . . . . . . . . . . . . 10
6. Initiator Deployment Consideration . . . . . . . . . . . . . . 11
6.1. Bridging mode and routing mode . . . . . . . . . . . . . . 11
6.2. ALG consideration . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix 1. Appendix:Experimental Result . . . . . . . . . . . . 15
1.1. Experimental environment . . . . . . . . . . . . . . . . . 15
1.2. Experimental results . . . . . . . . . . . . . . . . . . . 16
1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Sun, et al. Expires September 6, 2012 [Page 2]
Internet-Draft lightweigh-4over6-deployment March 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
won't require to couple IPv4 and IPv6 address schemas as MAP
[I-D.mdt-softwire-mapping-address-and-port] requires. This document
discusses various 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 September 6, 2012 [Page 3]
Internet-Draft lightweigh-4over6-deployment March 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 September 6, 2012 [Page 4]
Internet-Draft lightweigh-4over6-deployment March 2012
3. Case Studies
Lightweight 4over6 can be either deployed in a standalone way, or
incrementally coexistent with DS-Lite[RFC6333]. It is suitable for
operators who would like to keep IPv6 and IPv4 addressing separated.
The dynamic feature of IPv4 address and port-sets provision makes
more efficient usage of IPv4 resource. For operator who only have
many small and discontinuous IPv4 blocks available to provide IPv4
over IPv6, this mechanism won't require to administrate and manage
many IPv4 and IPv6 mapping rules planning in CPE or MAP domains in
the network.
3.1. case 1: Standalone Deployment Scenario
Lightweight 4over6 can be deployed in a new residential network
(depicted in Figure1). In this scenario, an Initiator would acquire
port-restricted IPv4 address after user authentication process and
IPv6 provisioning process. It then uses IPv4-in-IPv6 tunnel to build
a softwire to deliver IPv4 services to the Concentrator in the
network. The Concentrator supports only Lightweight 4over6 which
keeps the mapping between Initiator's IPv6 address and its allocated
IPv4 address + port set. There is no need to interact with other
transition techniques. More detailed considerations would be
discussed in section 4.
+---+-----------+--------------|
+ | |
+---------+ +------+---+ +--+--+ |
| Host | | LW 4over6| | | |
| |--| Initiator| ======-| BNG | === +---------+ +-----------+
+---------+ +----------+ +--|--+ |LW 4over6| | IPv4 |
|Concen- |---| Internet |
+---------+ +------+---+ +--+--+ |trator | | |
| Host |--| LW 4over6| =======| | ====+---------+ +-----------+
| | | Initiator| | BNG | |
+---------+ +----------+ +--|--+ |
+ | |
+---------------+--------------+
Figure 1 Standalone Deployment Scenario
3.2. case 2: DS-Lite Coexistent scenario with Integrated AFTR
Lightweight 4over6 can be deployed incrementally in existing DS-Lite
network architecture(depicted in Figure2). In this case, DS-Lite has
been deployed in the network. Later in the deployment schedule, the
operator decided to introduce Lightweight 4over6 Concentrator in the
same AFTR. Therefore, the same concentrator needs to identify the
Sun, et al. Expires September 6, 2012 [Page 5]
Internet-Draft lightweigh-4over6-deployment March 2012
two distinct mechanisms based on encapsulated subscriber's IPv4
address. Lightweight 4over6 and DS-Lite would use the same
addressing scheme, routing policy, user management policy, etc., and
they can use the same DHCPv6 option [RFC6334] to inform the FQDN of
concentrator.
+---+-----------+--------------|
+ | |
+---------+ +------+---+ +--+--+ |
| Host | | LW 4over6| | | |
| |--| Initiator| ======-| BNG | === +-------------+ +-----------+
+---------+ +----------+ +--|--+ |LW 4over6 | | IPv4 |
|Concentrator/|---| Internet |
+---------+ +------+---+ +--+--+ |DS-Lite AFTR | | |
| Host |--| DS-Lite | =======| | ====+-------------+ +-----------+
| | | B4 | | BNG | |
+---------+ +----------+ +--|--+ |
+ | |
+-------------------+----------+
Figure 2 DS-Lite Coexistence scenario with Integrated AFTR
3.3. case 3: DS-Lite Coexistent scenario with Seperated AFTR
Lightweight 4over6 can be also deployed incrementally in existing DS-
Lite architecture, but not coupled tightly with DS-Lite AFTR
(depicted in Figure3). For example, DS-Lite AFTR might be deployed
distributed in access routers, while lightweight 4over6 concentrator
might be deployed centralized in a MAN. This deployment model has
the advantage of high flexibility. However, since there are distinct
addresses for DS-Lite AFTR and lightweight 4over6 concentrator,
seperated tunnel end-point discovery mechanisms should be introduced.
+---+---------------+-----------------|
+ | |
+---------+ +------+---+ +------+-----+ |
| 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 Integrated AFTR
Sun, et al. Expires September 6, 2012 [Page 6]
Internet-Draft lightweigh-4over6-deployment March 2012
4. Overall Deployment Considerations
4.1. Addressing and Routing
In lightweight 4over6, it is suggested to adopt separated IPv4/IPv6
addressing schemes. IPv4 address pools are configured centralized in
concentrator for IPv6 subscribers. These IPv4 address routing
entries also should be imported into IPv4 Internet accordingly.
For IPv6 addressing and routing, there are no additional addressing
and routing requirements. The process of IPv6 address assignment and
routing announcement can be integrated with existing IPv6 address
allocation process, e.g. using PPPoE or IPoE, etc. IPv6 address
pools are configured in DHCPv6 server. No extra routing requirement
is needed to taken into consideration.
4.2. Port-set Management
In lightweight 4over6, each initiator will get its restricted IPv4
address and a valid port-set. This port-set assignment should be
synchronized between port management server and the concentrator.
Normally, port management server is responsible for allocating port
restricted IPv4 address to initiator. It can be located in the
concentrator itself or relayed by the concentrator to pass through
port restricted parameters. Different mechanisms including PCP-
extended protocol [I-D.tsou-pcp-natcoord], DHCP-extended protocol or
IPCP-extended protocol, etc., can be applied.
o DHCP-based mechanism is usually designed for stable port
management, which means only static port set can be allocated at
one time. In this case, the DHCPv4 protocol should be extended to
support port-set allocation process [I-D.bajko-pripaddrassign].
Besides, with the concentrator acting as the DHCP server or relay,
DHCPv4 should be performed over IPv6
[I-D.ietf-dhc-dhcpv4-over-ipv6].
o PCP-based mechanism is usually more flexible. An initiator can
launch multiple PCP requests simultaneously to acquire a number
ports within the same IPv4 address, or use [I-D.tsou-pcp-natcoord]
for one-time port-set allocation.
o IPCP-based mechanism[RFC6431] is more suitable for concentrators
deployed in BNG.
4.3. Concentrator Discovery
A lightweight 4over6 initiator should discover the concentrator's
IPv6 address during startup. This IPv6 address can be learned
Sun, et al. Expires September 6, 2012 [Page 7]
Internet-Draft lightweigh-4over6-deployment March 2012
through a variety of methods, ranging from an out-of-band mechanism,
manual configuration, to a DHCPv6 option. For case 1 and case 2 in
the above section, lightweight 4over6 can make use of existing DS-
Lite discovery mechanism as defined in [RFC6334]. For case 3, we
suggest that a new DHCPv6 option should be defined to carry the
concentrator's IPv6 address.
Sun, et al. Expires September 6, 2012 [Page 8]
Internet-Draft lightweigh-4over6-deployment March 2012
5. Concentrator Deployment Consideration
5.1. Common considerations with DS-Lite deployment
As lightweight 4over6 is an extension to DS-Lite, some considerations
in terms of 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. In
this document, we only discuss some considerations specific to
lightweight 4over6.
5.2. Logging at the Concentrator
In lightweight 4over6, only subscriber-based logging records
including IPv4 address, IPv6 address and port set should be sent to a
centrilized syslog server. Since this mechanism reduces the number
of simultaneous address mappings of each customer on concentrator to
one, it makes concentrator logging much more feasible. The port set
algorithm implemented in lightweight 4over6 concentrator should be
syncronized with the one implemented in logging system.
5.3. Reliability Considerations of Concentrator
In lightweight 4over6, port set allocation should be conducted before
packet processing. As a result, when one concentrator encountered a
failure, a backup concentrator should either have the binding record
beforehand, or trigger a port management echo to the initiator. The
first choice is a hot standby mode, while the second can be achieved
by sending an ICMPv6 error request on getting an un-established
binding record from the initiator.
5.4. Placement of AFTR
Normally, the concentrator can be deployed in either 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 September 6, 2012 [Page 9]
Internet-Draft lightweigh-4over6-deployment March 2012
5.5. Port set algorithm consideration
Since port randomization algorithm must use ports within the port
set, it may cause the port randomization algorithm more predictable.
Therefore, non-continuous port set algorithms (e.g. as defined in
[I-D.mdt-softwire-mapping-address-and-port]) can be introduced to
further improve the security.
Sun, et al. Expires September 6, 2012 [Page 10]
Internet-Draft lightweigh-4over6-deployment March 2012
6. Initiator Deployment Consideration
6.1. Bridging mode and routing mode
In routing mode, the initiator runs a standard NAT44 [RFC3022] using
the allocated public address as external IP and ports via DHCPv6
option. When receiving an IPv4 packet with private source address
from its end hosts, it performs NAT44 function by translating the
source address into public and selecting a port from the allocated
port-set. Then it encapsulates the packet with the concentrator's
IPv6 address as destination IPv6 address, and forwards it to the
concentrator.
For the bridging mode, end host should run a software performing
initiators' functionalities. In this case, end host gets public
address directly. It is also suggested that the host run a local NAT
to map randomly generated ports into the restricted, valid port-set.
Another solution is to have the IP stack to only assign ports within
the restricted, valid range to applications. Either way the host
guarantees that every source port number in the outgoing packets
falls into the allocated port-set.
6.2. ALG consideration
In lightweight 4over6, the initiator is responsible for performing
ALG functions (e.g., SIP, FTP), as well as supporting NAT Traversal
mechanisms (e.g., UPnP, NAT-PMP, manual mapping configuration). This
is no different from the standard IPv4 NAT today.
Since there is no address and port mapping in the concentrator, the
ALG is no longer needed in the carrier-side network.
Sun, et al. Expires September 6, 2012 [Page 11]
Internet-Draft lightweigh-4over6-deployment March 2012
7. Acknowledgement
TBD
Sun, et al. Expires September 6, 2012 [Page 12]
Internet-Draft lightweigh-4over6-deployment March 2012
8. References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-03 (work in progress),
September 2010.
[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]
Boucadair, M., Sun, Q., Tsou, T., Lee, Y., and Y. Cui,
"Lightweight 4over6: An Extension to DS-Lite
Architecture", draft-cui-softwire-b4-translated-ds-lite-05
(work in progress), February 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]
Lemon, T., Cui, Y., Wu, P., and J. Wu, "DHCPv4 over IPv6
Transport", draft-ietf-dhc-dhcpv4-over-ipv6-00 (work in
progress), November 2011.
[I-D.ietf-pcp-base]
Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R.
Penno, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-23 (work in progress), February 2012.
[I-D.ietf-softwire-dslite-deployment]
Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
Boucadair, "Deployment Considerations for Dual-Stack
Lite", draft-ietf-softwire-dslite-deployment-02 (work in
progress), March 2012.
[I-D.mdt-softwire-mapping-address-and-port]
Sun, et al. Expires September 6, 2012 [Page 13]
Internet-Draft lightweigh-4over6-deployment March 2012
Bao, C., Troan, O., Matsushima, S., Murakami, T., and X.
Li, "Mapping of Address and Port (MAP)",
draft-mdt-softwire-mapping-address-and-port-03 (work in
progress), January 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]
Zhou, C., Tsou, T., Deng, X., Boucadair, M., and Q. Sun,
"Using PCP To Coordinate Between the CGN and Home Gateway
Via Port Allocation", draft-tsou-pcp-natcoord-04 (work in
progress), January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 September 6, 2012 [Page 14]
Internet-Draft lightweigh-4over6-deployment March 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 September 6, 2012 [Page 15]
Internet-Draft lightweigh-4over6-deployment March 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 September 6, 2012 [Page 16]
Internet-Draft lightweigh-4over6-deployment March 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-subscriber 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 September 6, 2012 [Page 17]
Internet-Draft lightweigh-4over6-deployment March 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
Sun, et al. Expires September 6, 2012 [Page 18]