Network Working Group G. Chen
Internet-Draft H. Deng
Intended status: Experimental China Mobile
Expires: April 29, 2010 October 26, 2009
A Optimal Load-balance mechanism for NAT64 (OL-NAT)
draft-chen-behave-olnat-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Chen & Deng Expires April 29, 2010 [Page 1]
Internet-Draft OL-NAT October 2009
Abstract
In NAT64 scenaires,sigle-point failure is a critical issue to
restrict large-scale deployment. In order to overcome this hurdle,
this memo proposed a optimal load-balance mechanism for NAT64.
Through the new-defined evaluation metrics, several extended ICMP
messages combining with anycast are performed to achieve optimal
NAT64 selection. Meanwihle, the synchroniztion process of IP address
mapping information is also designed to guarantee the service
continuity.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Optimum Load-balance Mechanism Overview . . . . . . . . . . . 4
3. Anycast Load-balance Mechanisms . . . . . . . . . . . . . . . 5
4. Mapping Information Synchronization . . . . . . . . . . . . . 7
5. Optimal Load-balance Data Flow Description . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Chen & Deng Expires April 29, 2010 [Page 2]
Internet-Draft OL-NAT October 2009
1. Introduction
In NAT64[I-D.bagnulo-behave-nat64] scenaries, NAT64 gateway is a
equipment to handle data translation functionalities between
different IP families. With the development of network scale, the
data transmission volume will be increased rapidly. Meanwhile, a
more productive processing capabilities are required to implement IP
address translation and application layer gateway processing. Due to
the unstable volume of data traffic, a single-point failure is easy
to occur in the case of deploying a single gateway on IPv6 network
border.
In order to provide a reliable NAT handling, some redundancy
mechanisms have been designed, such as cold standy and hot standy
mechanism. In addition, new routing mechanisms are also proposed to
achieve load-balance between different NAT equipments. Those methods
could decrease the risks of single-point failures by separating data
traffic into different NAT. However,unbalanced traffic distributions
could be happened when a specific destination has been trageted
frequently. For example, some popular websites always get high visit
rating.
In order to achieve the results of optimal load-balance, a dynamic
load-balance mechanism is required based on NAT process load states.
The optimum load-balance mechanism could dynamicaly direct data
traffic into the NAT with light data traffic. Therefore, the network
resource could be allocated maximally.
In the document, an optimal load-balance mechanism of NAT64 is
proposed to realize optimized data traffic distribution based on
anycast approach. Depending on that, hosts located on IPv6 network
could simply configure a specific anycast address to discover a
proper NAT64.
Chen & Deng Expires April 29, 2010 [Page 3]
Internet-Draft OL-NAT October 2009
2. Optimum Load-balance Mechanism Overview
Depending on the characteristics of anycast routing, the anycast
mechanism was applied in many load-balance cases, such as DNS load-
balance. Anycast approach provides hosts with a specific anycast
address, which represents a bundle of server with similar
functionalities. Based on the anycast routing rules, only a router
with minimum hop to the source response the initiator.In another
words, the load-balace mechanism based on anycast only treat the hop
as a metrics. Following this rules, unbalaced load distribution
might be happend in local area, since data only routed to a specific
router.
The objectives of optimal load-balance mechanism are to discover
apropriate NAT to translate IP address information. Therefore, the
selection of optimum NAT is an key issue for the load-balance
mechanism. Therein, two kinds of basic indicators are considerated
to evaluate which NAT could be chosen to process data translation.
Under the analysis of influence factors,load status of NAT and hop
from hosts to NAT are defined. The load status represents the
utilization of NAT processor. And hop could be counted from hosts to
NAT by interim routers. The combination of two indicators is used to
determine data paths, throgh which data traffic si routed to a
destination.
Under effect of above defined metrics, the data traffic will be route
to optimum NAT dynamically. It could cause the uncertainty of NAT
selection, since network environment will be changed over time. When
the traffic is directed to different NAT compared to previous one,
the IP address mapping information is needed to guarantee transmited
data could be tanslated. Therefore, the IP address mapping should be
synchronized betweent the different NAT so as to ensure the service
continuities. Otherwise, the data traffic will be lost due to the
absence of mapping table.
Chen & Deng Expires April 29, 2010 [Page 4]
Internet-Draft OL-NAT October 2009
3. Anycast Load-balance Mechanisms
In order to performe the optimal load-balance using anycast
mechanism, following extended ICMP messages are proposed to carry
defined indicators.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Anycast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NAT anycast request message
NAT anycast request message is shown in figure 1. The message is
transmitted from a host to NAT64. The flag A indicates this message
is dedicated to anycast propagation. Anycast address represents
identifier of a bundle of NAT64 equipments. Hop is used to measure
the distance from soruce to destination NAT. The field will be added
by one through each interim router.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................ |
Figure 2: NAT anycast response message
NAT anycast response message is shown in figure 2. The message is
transmitted from NAT64 to a host. The flag A indicates this message
Chen & Deng Expires April 29, 2010 [Page 5]
Internet-Draft OL-NAT October 2009
is dedicated to anycast propagation. A unicast address is listed in
order to show respective unicast address of NAT64. Acoording to
given rules, the top Unicast address has high priority. It will be
recommend as optimal NAT64 address.
Chen & Deng Expires April 29, 2010 [Page 6]
Internet-Draft OL-NAT October 2009
4. Mapping Information Synchronization
In order to synchronize the IP address mapping infromation between
different NAT64, a extend ICMP message is proposed to carry the
mapping information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Anycast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................ |
Figure 3: NAT anycast synchronization message
NAT anycast synchronization message is shown in figure 3. The
message is transmitted between different NAT64. The flag A indicates
this message is dedicated to anycast propagation. Anycast address
represents identifier of a bundle of NAT64 equipments. Unicast
Address indicate itself network interface address. The IPv6 address
and IPv4 address fields are used to carry IP address mapping
information.
Chen & Deng Expires April 29, 2010 [Page 7]
Internet-Draft OL-NAT October 2009
5. Optimal Load-balance Data Flow Description
The optimal Load-balance mechanism will adopt new-defiend ICMP
message to achieve the mapping information synchronization and
optimal NAT64 selection. The figure 4 is to describe the overall
optimal load-balance data flow.
Host Router NAT64(A) NAT64(B) NAT64(C)
| | | | |
synchronization message|
(1) | | |----------->--------->|
|request message | | |
(2) |------->| | | |
(3) | Hop plus 1 | | |
| |request message | |
(4) | |----------->| | |
| | | | |
| response message | | |
(5) |<--------------------| | |
Figure 4: Optimal Load-balance Data Flow
(1)IP address mapping infromation will be synchronized based on
interaction of NAT anycast synchronization message. Each NAT64 will
send synchronization message to a NAT64 multicast address, which
could guarantee each of them can receive the message and construct
global NAT64 mapping table. The synchronization actions will be
performed by constant interval in order to update respective changes.
(2)Host send a NAT anycast request message to a specific anycast
address, which will identify a bundle of NAT64.
(3)When a normal router receive the request message, they will update
Hop field by plusing one and routed to next hop.
(4)When the request message arrive the NAT64 with anycast address, it
will extract hop field and combine with load status to determine
whether it is optimal NAT64.
(5)NAT64 sends NAT anycast response message with recommend NAT64 list
to hosts. And, the host will pick the optimal NAT64 unicast address
to initiate application data flow.
Chen & Deng Expires April 29, 2010 [Page 8]
Internet-Draft OL-NAT October 2009
6. Security Considerations
It needs to be further identified.
Chen & Deng Expires April 29, 2010 [Page 9]
Internet-Draft OL-NAT October 2009
7. IANA Considerations
This memo request IANA to assign specific ICMP type number to
identify the NAT anycast message.
Chen & Deng Expires April 29, 2010 [Page 10]
Internet-Draft OL-NAT October 2009
8. Informative References
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-bagnulo-behave-nat64-03 (work in
progress), March 2009.
Chen & Deng Expires April 29, 2010 [Page 11]
Internet-Draft OL-NAT October 2009
Authors' Addresses
Gang Chen
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13910710674
Email: phdgang@gmail.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13910750201
Email: denghui02@gmail.com
Chen & Deng Expires April 29, 2010 [Page 12]