One document matched: draft-carpenter-v6ops-label-balance-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
(which supports the latest, sometimes undocumented and under-tested, features.) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- You need one entry like the following for each RFC referenced -->
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY RFC2460 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!-- You need one entry like the following for each I-D referenced -->
<!ENTITY DRAFT-3697bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-flow-3697bis.xml">
<!ENTITY DRAFT-ecmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-flow-ecmp.xml">
]>
<?rfc toc="yes"?> <!-- You want a table of contents -->
<?rfc symrefs="yes"?> <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?> <!-- This sorts the references -->
<?rfc iprnotified="no" ?> <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-carpenter-v6ops-label-balance-00" category="info" >
<front>
<title abbrev="Flow Label Load Balancers">Using the IPv6 Flow Label for Server Load Balancing</title>
<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
<organization abbrev="Univ. of Auckland"></organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region></region>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<author fullname="Sheng Jiang" initials="S." surname="Jiang">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14, Huawei Campus</street>
<street>No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal>
<email>jiangsheng@huawei.com</email>
</address>
</author>
<date day="13" month="October" year="2011" />
<area>Operations and Management</area>
<workgroup>V6OPS</workgroup>
<abstract>
<t>This document describes how the IPv6 flow label can be used in support of layer 3/4 load balancing for large server farms.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The IPv6 flow label has been redefined <xref target="I-D.ietf-6man-flow-3697bis"/>
and its use for load balancing in multipath routing has been
specified <xref target="I-D.ietf-6man-flow-ecmp"/>.
Another scenario in which the flow label could be used is in load balancing for large
server farms. This document starts with a brief introduction to load balancing techniques and then describes
how the flow label can be used to enhance layer 3/4 flow balancers in particular. </t>
<t>Load balancing for server farms is achieved by a variety of methods, often used in combination
<xref target="Tarreau"/>. The flow
label is not relevant to all of them. Also, the actual load balancing algorithm (the choice of server for a
new client session) is irrelevant to this discussion. </t>
<t><list style="symbols">
<t>The simplest method is simply using the DNS to return different server
addresses for a single name such as www.example.com to different users. Typically this is done by rotating
the order in which different addresses are listed by the relevant authoritative DNS server, assuming that
the client will pick the first one. The flow label can have no impact on this method and it is not
discussed further. </t>
<t>Another method, for HTTP servers, is to operate a layer 7 reverse proxy in front of the server farm. The reverse
proxy will present a single IP address to the world, communicated to clients by a single AAAA record. For each
new client session (an incoming TCP connection and HTTP request), it will pick a particular server and proxy
the session to it. Hopefully the act of proxying will be cheap compared to the act of serving the required
content. The proxy must retain TCP state and proxy state for the duration of the session. This TCP state
could, potentially, include the incoming flow label value. </t>
<t>A component of some load balancing systems is an SSL reverse proxy farm. The individual SSL proxies
handle all cryptographic aspects and exchange raw HTTP with the actual servers. Thus, from the load
balancing point of view, this really looks just like a server farm, except that it's specialised for HTTPS.
Each proxy will retain SSL and TCP and maybe HTTP state for the duration of the session, and the TCP
state could potentially include the flow label. </t>
<t>Finally the "front end" of many load balancing systems is a layer 3/4 load balancer. In this case,
it is the layer 3/4 load balancer whose IP address is published
as the primary AAAA record for the service. All client sessions
will pass through this device. According to the precise scenario, it will spread new sessions
across the actual application servers, across an SSL proxy farm, or across a set of layer 7
proxies. In all cases, the layer 3/4 load balancer has to recognize incoming packets as belonging
to new or existing client sessions, and choose the target server or proxy so as to ensure persistence.
'Persistence' is defined as guaranteeing that a given session will run to completion on a single server.
The layer 3/4 load balancer, whatever method it uses for forwarding the session, is certain to inspect
the source address and the protocol and port numbers in each incoming packet. At the same time, it
could inspect and make use of the flow label.
<vspace blankLines="1"/>
Layer 3/4 load balancers use various techniques to actually reach their target server.
<vspace/>
- All servers are configured with the same IP address, they are all on the same LAN, and the load balancer
sends directly to their individual MAC addresses.
<vspace/>
- Each server has its own IP address, and the balancer uses an IP-in-IP tunnel to reach it.
<vspace/>
- Each server has its own IP address, and the balancer performs NAPT (address and port translation).
</t>
</list></t>
<t>The following diagram, inspired by <xref target="Tarreau"/>, shows a maximum layout. </t>
<figure><artwork>
___________________________________________
( )
( Clients in the Internet )
(___________________________________________)
|
------------
| Ingress |
| router |
------------
____________|_____________
| |
|DNS-based load splitting|
| |
------------ ------------
|L3/L4 ASIC| |L3/L4 ASIC|
| balancer | | balancer |
------------ ------------
| load |
| spreading |
__________|________________________|___________
| | | |
------------ ------------ -------- --------
|HTTP proxy|...|HTTP proxy| | SSL |...| SSL |
| balancer | | balancer | | proxy| | proxy|
------------ ------------ -------- --------
____|_____________|_____________|_________|_____
| | | | |
-------- -------- -------- -------- --------
|HTTP | |HTTP | |HTTP | |HTTP | |HTTP |
|server| |server| |server| |server| |server|
-------- -------- -------- -------- --------
</artwork> </figure>
<t>From the previous paragraphs, we can identify several points
in this diagram where the flow label may be relevant:</t>
<t><list style="numbers">
<t>L3/L4 load balancers.</t>
<t>SSL proxies.</t>
<t>HTTP proxies.</t>
</list></t>
</section> <!-- intro -->
<section anchor="role" title="Role of the Flow Label">
<t>The IPv6 flow label is included in every IPv6 header <xref target="RFC2460"/>
and it is defined in <xref target="I-D.ietf-6man-flow-3697bis"/>. According to
this definition, it should be set to a constant value for a given traffic flow
(such as an HTTP connection), but until the standard is widely implemented
it will often be set to the default value of zero. Any device that has access
to the IPv6 header has access to the flow label, and it is at a fixed position
in every IPv6 packet. In contrast, transport layer information, such as
the port numbers, is not always in a fixed position, since it follows
any IPv6 extension headers that may be present. Therefore, within the
lifetime of a given transport layer connection, the flow label can be
a more convenient "handle" than the port number for identifying that
particular connection. </t>
<t>According to <xref target="I-D.ietf-6man-flow-3697bis"/>, source hosts
should set the flow label, but if they do not (i.e. its value is zero),
forwarding nodes may do so instead. In both cases, the flow label value
must be constant for a given transport session, normally identified
by the IPv6 and Transport header 5-tuple. The flow label should be calculated
by a stateless algorithm. The value should form part of a statistically
uniform distribution, making it suitable as part of a hash function used
for load distribution. Because of using a stateless algorithm to calculate
the label, there is a very low (but non-zero) probability that two
simultaneous flows from the same source to the same destination have the
same flow label value despite having different transport protocol port numbers. </t>
<t>The suggested model for using the flow label in a load balancing mechanism
is as follows. </t>
<t><list style="symbols">
<t>It is clearly better if the original source, e.g. an HTTP client, sets the flow label.
However, if the flow label of an incoming packet is zero, the ingress router at the
server site should implement the stateless mechanism in Section 3 of
<xref target="I-D.ietf-6man-flow-3697bis"/> to set the flow label value
to an appropriate value. This relieves the subsequent load balancers
of the need to fully analyse the IPv6 and Transport header 5-tuple. </t>
<t>The L3/L4 load balancers use the 2-tuple {source address, flow label}
as the session key for whatever load distribution algorithm they support,
instead of searching for the transport port number later in the header. This
means they can ignore all IPv6 extension headers, which should simplify
their design and lead to a performance benefit. </t>
<t>The SSL proxies may do the same. However, since they have to process
the transport layer in any case, this might not lead to any performance benefit. </t>
<t>The HTTP proxies may do the same. However, since they have to process
the transport and application layers in any case, this might not lead to any performance benefit. </t>
</list></t>
<t>Note that in the unlikely event of two simultaneous flows from the same
source having the same flow label value, the two flows would end up assigned
to the same server, where they would be distinguished as normal by their
port numbers. Since this would be a statistically rare event, it would
not damage the overall load balancing effect. </t>
</section> <!-- role -->
<section anchor="security" title="Security Considerations">
<t>Security aspects of the flow label are discussed in <xref target="I-D.ietf-6man-flow-3697bis"/>.
As noted there, a malicious source or man-in-the-middle could disturb load balancing
by manipulating flow labels. </t>
<t>Specifically, <xref target="I-D.ietf-6man-flow-3697bis"/> states that "stateless classifiers
should not use the flow label alone to control load distribution, and stateful classifiers should include
explicit methods to detect and ignore suspect flow label values." The former point is answered
by also using the source address. The latter point is more complex. If the risk is considered
serious, the ingress router mentioned above should verify incoming flows with non-zero flow
label values. If a flow from a given source address and port number does not have a constant
flow label value, it is suspect and should be dropped. </t>
</section> <!-- security -->
<section anchor="iana" title="IANA Considerations">
<t>This document requests no action by IANA. </t>
</section> <!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>
Valuable comments and contributions were made by
</t>
<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>
</section> <!-- ack -->
<section anchor ="changes" title="Change log [RFC Editor: Please remove]">
<t>draft-carpenter-v6ops-label-balance-00: original version, 2011-10-13.</t>
</section> <!-- changes -->
</middle>
<back>
<references title="Normative References">
&RFC2460;
&DRAFT-3697bis;
</references>
<references title="Informative References">
&RFC2629;
&DRAFT-ecmp;
<reference anchor="Tarreau" target="http://1wt.eu/articles/2006_lb/">
<front>
<title>Making applications scalable with load balancing</title>
<author initials="W. " surname="Tarreau" fullname="Willy Tarreau"/>
<date year="2006"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:17 |