Network Working Group Y. Cui
Internet-Draft J. Wu
Intended status: Standards Track D. Wu
Expires: April 21, 2011 Tsinghua University
October 18, 2010
B4 translated DS-lite enable AFTR to serve more B4s
draft-cui-softwire-b4-translated-ds-lite-00
Abstract
The well known Dual Stack lite (DS-lite) technology does great
contribution to the deployment of IPv6 and alleviate the shortage of
IPv4 address by making it possible to share a single IPv4 address
between many hosts. However, the original DS-lite model make AFTR
the bottleneck of whole system, thus AFTR's efficiency limits the
capability of whole DS-lite model. This draft proposes a B4-
translated Ds-lite to alleviate the burden of AFTR so that AFTR is
able to serve more B4s.
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 April 21, 2011.
Copyright Notice
Copyright (c) 2010 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
Cui, et al. Expires April 21, 2011 [Page 1]
Internet-Draft B4-translated DS-lite October 2010
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.
Cui, et al. Expires April 21, 2011 [Page 2]
Internet-Draft B4-translated DS-lite October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements language . . . . . . . . . . . . . . . . . . . . 5
3. B4-translated DS-lite deployment . . . . . . . . . . . . . . . 6
3.1. Handle outbound packets . . . . . . . . . . . . . . . . . 6
3.2. Handle inbound packets . . . . . . . . . . . . . . . . . . 7
4. Port request . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Port request mechanism . . . . . . . . . . . . . . . . . . 8
4.2. Port request policy . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Cui, et al. Expires April 21, 2011 [Page 3]
Internet-Draft B4-translated DS-lite October 2010
1. Introduction
B4-translated DS-lite is a variant of original DS-
lite[I-D.ietf-softwire-dual-stack-lite], it alleviates the burden of
AFTR, thus to increase the throughput of AFTR.
In DS-lite deployment, a single AFTR might serves thousands of B4s.
In this condition, the efficiency of AFTR becomes the bottleneck of
whole system. It is desirable to increase the AFTR's efficiency. If
the AFTR can be more efficient, a single AFTR is able to serve more
B4s.
AFTR takes charge of packet encapsulation/decapsulation, packet
forwarding and address translation. In the three operations, address
translation is a heavy job, because address translation involves
searching mapping table, which might consist of tens of thousands of
entries. When the search algorithm is implemented by hardware, a
large mapping table will cost a great amount of hardware resources on
AFTR.In the meantime, the address translation is the only operation
that can be moved to B4 side.
On the contrary, B4 is only responsible for encapsulation/
decapsulation and there are many B4s served by a single AFTR, thus
moving the address translation to B4 side will not add much burden to
a single B4.
In conclusion, it is desirable to move address translation from AFTR
to B4 side, it is feasible, and enables a single AFTR to serve more
B4s.this draft proposed the B4-translated DS-lite to enable AFTR to
serve more B4s by moving address translation to B4 side.
Cui, et al. Expires April 21, 2011 [Page 4]
Internet-Draft B4-translated DS-lite October 2010
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.
Cui, et al. Expires April 21, 2011 [Page 5]
Internet-Draft B4-translated DS-lite October 2010
3. B4-translated DS-lite deployment
This section describle the steps when a host behind B4 communicates
with another host resides in Internet.
3.1. Handle outbound packets
The B4 must know the external address and port in order to do address
translation, thus the B4 must first establish mapping before
traslation.
In B4-translated DS-lite mechanism, it is suggested that the hosts
are not aware of mapping establishment in B4. Figure 1 shows an
example of mapping establishment in B4. In this example, the mapping
establishment is conducted automatically when a packet, which
contains an unknown source address-port combination, arrives.
host B4 AFTR
|----(1)-------------->| |
| |---------(2)--------->|
| |<--------(3)----------|
| |---------(4)--------->|
Figure 1 Mapping establishment
1. A host connected to a server on Internet, so it sends a packet to
its default gateway, which is B4. If the B4 knows the
corresponding external address of the source address, jump to
step 4.
2. Gateway which functions as B4, obtains the source address-port of
the outbound packet and requests to AFTR for a corresponding
external address-port.
3. AFTR allocates an external address-port and responds to B4.When
B4 receives this response, it records the internal address,
internal port, external address and external port in a mapping
table. This mapping table will be used to support the address
translation of each received packet.
4. B4 does the address translation to the packet according to the
mapping table and encapsulate this packet before sending it to
AFTR. When AFTR receives this packet, it first records the
source ipv4 address, source port number and ipv6 address of
corresponding tunnel end point and then decapsulates the packet
and forwards it to Internet.The source ipv4 address, source port
Cui, et al. Expires April 21, 2011 [Page 6]
Internet-Draft B4-translated DS-lite October 2010
number and ipv6 address comprise an entry of encapsulation table.
This table will be used when inbound packets arrive.
3.2. Handle inbound packets
When an inbound packet arrives at AFTR, AFTR checks the destination
address-port and search the encapsulation table. Then AFTR
encapsulate the packet and send it to its corresponding B4.
When B4 receive the inbound packet, it simply decapsulate the packet,
replace its destination address and port number and send it to the
host.
Cui, et al. Expires April 21, 2011 [Page 7]
Internet-Draft B4-translated DS-lite October 2010
4. Port request
4.1. Port request mechanism
In 3.1., B4 has the demand to learn the external address and port for
the sake of successful address translation. Pinhole Control
Protocol(PCP)[I-D.wing-softwire-port-control-protocol]can be
leveraged to make needs meet.
PCP is primarily used to enalbe PCP client to control how inbound
packets are forwarded by upstream NAT devices so as to behave as a
serve. Thus it enables PCP client to learn the external address and
port. So the B4-translated DS-lite can leveraged Pinhole Control
Protocol (PCP) mechanism to request ports.
4.2. Port request policy
There are two strategy for B4 to request ports.
One is to request on demand, which means that B4 only request for a
new port when a packet, which can not be translated, arrives. This
strategy has a main drawback that port request is called when each
traffic flow begins. Every flow is subjected to a request and
responce, which will increase the latency of packet sending.
The other one is to request several ports at a time, thus the B4 can
handle more outbound packets without another request.With this
strategy, B4 is responsible for port management and original PCP
request MUST be extended to support requesting a series of port
number. This strategy also have drawbacks because it might due to
the inefficient use of port sources.
The request policy can be adjusted according to the demand of service
provider.
Cui, et al. Expires April 21, 2011 [Page 8]
Internet-Draft B4-translated DS-lite October 2010
5. Acknowledgements
Cui, et al. Expires April 21, 2011 [Page 9]
Internet-Draft B4-translated DS-lite October 2010
6. References
6.1. Normative References
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.wing-softwire-port-control-protocol]
Wing, D., Penno, R., and M. Boucadair, "Pinhole Control
Protocol (PCP)",
draft-wing-softwire-port-control-protocol-02 (work in
progress), July 2010.
Cui, et al. Expires April 21, 2011 [Page 10]
Internet-Draft B4-translated DS-lite October 2010
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn
Dan Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6277-7347
Email: wudanzy@csnet1.cs.tsinghua.edu.cn
Cui, et al. Expires April 21, 2011 [Page 11]
