draft-ietf-6man-flow-ecmp-00.txt   draft-ietf-6man-flow-ecmp-01.txt 
Network Working Group B. Carpenter Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: BCP S. Amante Intended status: BCP S. Amante
Expires: June 5, 2011 Level 3 Expires: August 14, 2011 Level 3
December 2, 2010 February 10, 2011
Using the IPv6 flow label for equal cost multipath routing and link Using the IPv6 flow label for equal cost multipath routing and link
aggregation in tunnels aggregation in tunnels
draft-ietf-6man-flow-ecmp-00 draft-ietf-6man-flow-ecmp-01
Abstract Abstract
The IPv6 flow label has certain restrictions on its use. This The IPv6 flow label has certain restrictions on its use. This
document describes how those restrictions apply when using the flow document describes how those restrictions apply when using the flow
label for load balancing by equal cost multipath routing, and for label for load balancing by equal cost multipath routing, and for
link aggregation, particularly for tunneled traffic. link aggregation, particularly for IP-in-IPv6 tunneled traffic.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2011. This Internet-Draft will expire on August 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Choice of IP Header Fields for Hash Input . . . . . . . . . 3
1.2. Flow label rules . . . . . . . . . . . . . . . . . . . . . 5
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6 2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
When several network paths between the same two nodes are known by When several network paths between the same two nodes are known by
the routing system to be equally good (in terms of capacity and the routing system to be equally good (in terms of capacity and
latency), it may be desirable to share traffic among them. Two such latency), it may be desirable to share traffic among them. Two such
techniques are known as equal cost multipath routing (ECMP) and link techniques are known as equal cost multipath routing (ECMP) and link
aggregation (LAG) [IEEE802.1AX]. There are of course numerous aggregation (LAG) [IEEE802.1AX]. There are of course numerous
possible approaches to this, but certain goals need to be met: possible approaches to this, but certain goals need to be met:
o Roughly equal share of traffic on each path. o Roughly equal share of traffic on each path.
o Work-conserving method (no idle time when queue is non-empty). (In some cases, the multiple paths might not all have the same
capacity and the goal might be appropriately weighted traffic
shares rather than equal shares. This would affect the load
sharing algorithm, but would not otherwise change the argument.)
o Minimize or avoid out-of-order delivery for individual traffic o Minimize or avoid out-of-order delivery for individual traffic
flows. flows.
o Minimize idle time on any path when queue is non-empty.
There is some conflict between these goals: for example, strictly There is some conflict between these goals: for example, strictly
avoiding idle time could cause a small packet sent on an idle path to avoiding idle time could cause a small packet sent on an idle path to
overtake a bigger packet from the same flow, causing out-of-order overtake a bigger packet from the same flow, causing out-of-order
delivery. delivery.
One lightweight approach to ECMP or LAG is this: if there are N One lightweight approach to ECMP or LAG is this: if there are N
equally good paths to choose from, then form a modulo(N) hash equally good paths to choose from, then form a modulo(N) hash
[RFC2991] from a consistent set of fields in each packet header, and [RFC2991] from a consistent set of fields in each packet header that
use the resulting value to select a particular path. If the hash are certain to have the same values throughout the duration of a
function is chosen so that the hash values have a uniform statistical flow, and use the resulting output hash value to select a particular
distribution, this method will share traffic roughly equally between path. If the hash function is chosen so that the output values have
the N paths. If the header fields included in the hash are a uniform statistical distribution, this method will share traffic
consistent, all packets from a given flow will generate the same roughly equally between the N paths. If the header fields included
hash, so out-of-order delivery will not occur. Assuming a large in the hash input are consistent, all packets from a given flow will
number of unique flows are involved, it is also probable that the generate the same hash output value, so out-of-order delivery will
method will be work-conserving, since the queue for each link will not occur. Assuming a large number of unique flows are involved, it
remain non-empty. is also probable that the method will avoid idle time, since the
queue for each link will remain non-empty.
The question with such a method is which IP header fields are chosen 1.1. Choice of IP Header Fields for Hash Input
to identify a flow and, consequently, are used as input keys to a
modulo(N) hash algorithm.
In the remainder of this document, we will use the term "flow" to In the remainder of this document, we will use the term "flow" to
represent a sequence of packets that may be identified by either the represent a sequence of packets that may be identified by either the
source and destination IP addresses alone {2-tuple} or the source and source and destination IP addresses alone {2-tuple} or the source and
destination IP addresses, protocol and source and destination port destination IP addresses, protocol and source and destination port
numbers {5-tuple}. It should be noted that the latter is more numbers {5-tuple}. It should be noted that the latter is more
specifically referred to as a "microflow" in [RFC2474], but this term specifically referred to as a "microflow" in [RFC2474], but this term
is not used in connection with the flow label in [RFC3697]. is not used in connection with the flow label in [RFC3697].
The question with such a method, then, is which IP header fields to The question is, then, which header fields are used to identify a
include to identify a flow. A minimal choice in the routing system flow and to serve as input keys to a modulo(N) hash algorithm. A
is simply to use a hash of the source and destination IP addresses, common choice when routing general traffic is simply to use a hash of
i.e., the 2-tuple. This is necessary and sufficient to avoid out-of- the source and destination IP addresses, i.e., the 2-tuple. This is
order delivery, and with a wide variety of sources and destinations, necessary and sufficient to avoid out-of-order delivery, and with a
as one finds in the core of the network, sometimes sufficient to wide variety of sources and destinations, as one finds in the core of
achieve work-conserving load sharing. In practice, implementations the network, often statistically sufficient to distribute load
often use the 5-tuple {dest addr, source addr, protocol, dest port, evenly. In practice, many implementations use the 5-tuple {dest
source port} as input keys to the hash function, to maximize the addr, source addr, protocol, dest port, source port} as input keys to
probability of evenly sharing traffic over the equal cost paths. the hash function, to maximize the probability of evenly sharing
However, including transport layer information as input keys to a traffic over the equal cost paths. However, including transport
hash may be a problem for IPv4 fragments [RFC2991]. In addition, layer information as input keys to a hash may be a problem for IP
protocol and destination port numbers in the hash will not only make fragments [RFC2991] or for encrypted traffic. Including the protocol
the hash slightly more expensive to compute, but will not and port numbers, totalling 40 bits, in the hash input makes the hash
particularly improve the hash distribution, due to the prevalence of slightly more expensive to compute but does improve the hash
well known port numbers and popular protocol numbers. Ephemeral distribution, due to the pseudo-random nature of ephemeral ports.
ports, on the other hand, are quite well distributed [Lee10]. In the Ephemeral port numbers are quite well distributed [Lee10] and will
case of IPv6, protocol numbers are particularly inconvenient due to typically contribute 16 variable bits. However, in the case of IPv6,
the variable placement of and variable length of next-headers. In transport layer information is inconvenient to extract, due to the
addition, [RFC2460] recommends that all next-headers, except hop-by- variable placement of and variable length of next-headers; all
hop options, should not be inspected by intermediate nodes in the implementations must be capable of skipping over next-headers, even
network, presumably to make introduction of new next-headers more if they are rarely present in actual traffic. In fact, [RFC2460]
straightforward. implies that next-headers, except hop-by-hop options, are not
normally inspected by intermediate nodes in the network. This
situation may be challenging for some hardware implementations,
raising the potential that network equipment vendors might sacrifice
the length of the fields extracted from an IPv6 header.
The situation is different in tunneled scenarios. Identifying a flow It is worth noting that the possible presence of a GRE header
inside the tunnel is more complicated, particularly because nearly [RFC2784] and the possible presence of a GRE key within that header
all hardware can only identify flows based on information contained creates a similar challenge to the possible presence of IPv6
in the outermost IP header. Assume that traffic from many sources to extension headers; anything that complicates header analysis is
many destinations is aggregated in a single IP-in-IP tunnel from undesirable.
tunnel end point (TEP) A to TEP B (see figure). Then all the packets
forming the tunnel have outer source address A and outer destination The situation is different in IP-in-IP tunneled scenarios.
address B. In all probability they also have the same port and Identifying a flow inside the tunnel is more complicated,
protocol numbers. If there are multiple paths between routers R1 and particularly because nearly all hardware can only identify flows
R2, and ECMP or LAG is applied to choose a particular path, the based on information contained in the outermost IP header. Assume
5-tuple and its hash will be constant and no load sharing will be that traffic from many sources to many destinations is aggregated in
achieved. If there is much tunnel traffic, this will result in a a single IP-in-IP tunnel from tunnel end point (TEP) A to TEP B (see
high probability of congestion on one of the paths between R1 and R2. figure). Then all the packets forming the tunnel have outer source
address A and outer destination address B. In all probability they
also have the same port and protocol numbers. If there are multiple
paths between routers R1 and R2, and ECMP or LAG is applied to choose
a particular path, the 2-tuple or 5-tuple, and its hash, will be
constant and no load sharing will be achieved. If there is a high
proportion of tunnel traffic, traffic will not be distributed as
intended across the paths between R1 and R2.
_____ _____ _____ _____ _____ _____ _____ _____
| TEP |_________| R1 |-------------| R2 |_________| TEP | | TEP |_________| R1 |-------------| R2 |_________| TEP |
|__A__| |_____|-------------|_____| |__B__| |__A__| |_____|-------------|_____| |__B__|
tunnel ECMP or LAG tunnel tunnel ECMP or LAG tunnel
here here
Also, for IPv6, the total number of bits in the 5-tuple is quite As noted above, for IPv6, the 5-tuple is in any case quite
large (296), as well as inconvenient to extract due to the next- inconvenient to extract due to the next-header placement. The
header placement. This may be challenging for some hardware question therefore arises whether the 20-bit flow label in IPv6
implementations, raising the potential that network equipment vendors packets would be suitable for use as input to an ECMP or LAG hash
might sacrifice the length of the fields extracted from an IPv6 algorithm, especially in the case of tunnels where the inner packet
header. The question therefore arises whether the 20-bit flow label header is inaccessible. If the flow label could be used in place of
in IPv6 packets would be suitable for use as input to an ECMP or LAG the port numbers and protocol number in the 5-tuple, the
hash algorithm. If it could be used in place of the port numbers and implementation would be simplified.
protocol number in the 5-tuple, the hash calculation would be
simplified.
The flow label is left experimental by [RFC2460] but is better 1.2. Flow label rules
The flow label was left experimental by [RFC2460] but was better
defined by [RFC3697]. We quote three rules from that RFC: defined by [RFC3697]. We quote three rules from that RFC:
1. "The Flow Label value set by the source MUST be delivered 1. "The Flow Label value set by the source MUST be delivered
unchanged to the destination node(s)." unchanged to the destination node(s)."
2. "IPv6 nodes MUST NOT assume any mathematical or other properties 2. "IPv6 nodes MUST NOT assume any mathematical or other properties
of the Flow Label values assigned by source nodes." of the Flow Label values assigned by source nodes."
3. "Router performance SHOULD NOT be dependent on the distribution 3. "Router performance SHOULD NOT be dependent on the distribution
of the Flow Label values. Especially, the Flow Label bits alone of the Flow Label values. Especially, the Flow Label bits alone
make poor material for a hash key." make poor material for a hash key."
These rules, especially the last one, have caused designers to These rules, especially the last one, have caused designers to
hesitate about using the flow label in support of ECMP or LAG. The hesitate about using the flow label in support of ECMP or LAG. The
fact is today that most nodes set a zero value in the flow label, and fact is today that most nodes set a zero value in the flow label, and
the first rule definitely forbids the routing system from changing the first rule definitely forbids the routing system from changing
the flow label once a packet has left the source node. Considering the flow label once a packet has left the source node. Considering
normal IPv6 traffic, the fact that the flow label is typically zero normal IPv6 traffic, the fact that the flow label is typically zero
means that it would add no value to an ECMP or LAG hash. But neither means that it would add no value to an ECMP or LAG hash. But neither
would it do any harm to the distribution of the hash values. If the would it do any harm to the distribution of the hash values.
community at some stage agrees to set pseudo-random flow labels in
the majority of traffic flows, this would add to the value of the
hash.
However, in the case of an IP-in-IPv6 tunnel, the TEP is itself the However, in the case of an IP-in-IPv6 tunnel, the TEP is itself the
source node of the outer packets. Therefore, a TEP may freely set a source node of the outer packets. Therefore, a TEP may freely set a
flow label in the outer IPv6 header of the packets it sends into the flow label in the outer IPv6 header of the packets it sends into the
tunnel. In particular, it may follow the [RFC3697] suggestion to set tunnel.
a pseudo-random value.
The second two rules quoted above need to be seen in the context of The second two rules quoted above need to be seen in the context of
[RFC3697], which assumes that routers using the flow label in some [RFC3697], which assumes that routers using the flow label in some
way will be involved in some sort of method of establishing flow way will be involved in some sort of method of establishing flow
state: "To enable flow-specific treatment, flow state needs to be state: "To enable flow-specific treatment, flow state needs to be
established on all or a subset of the IPv6 nodes on the path from the established on all or a subset of the IPv6 nodes on the path from the
source to the destination(s)." The RFC should perhaps have made source to the destination(s)." The RFC should perhaps have made
clear that a router that has participated in flow state establishment clear that a router that has participated in flow state establishment
can rely on properties of the resulting flow label values without can rely on properties of the resulting flow label values without
further signaling. If a router knows these properties, rule 2 is further signaling. If a router knows these properties, rule 2 is
irrelevant, and it can choose to deviate from rule 3. irrelevant, and it can choose to deviate from rule 3.
In the tunneling situation sketched above, routers R1 and R2 can rely In the tunneling situation sketched above, routers R1 and R2 can rely
on the flow labels set by TEP A and TEP B being assigned by a known on the flow labels set by TEP A and TEP B being assigned by a known
method. This allows a safe ECMP or LAG method to be based on the method. This allows an ECMP or LAG method to be based on the flow
flow label without breaching [RFC3697]. label consistently with [RFC3697], regardless of whether the non-
tunnel traffic carries non-zero flow label values.
At the time of this writing, the IETF is discussing a possible At the time of this writing, the IETF is discussing a revision of RFC
revision of the rules of RFC 3697 [I-D.ietf-6man-flow-update]. If 3697 [I-D.ietf-6man-flow-3697bis]. If adopted, that revision would
adopted, that revision would be fully compatible with the present be fully compatible with the present document and would obviate the
document and would obviate much of the above discussion. concerns resulting from the above three rules. Therefore, the
present specification applies both to RFC 3697 and to its expected
successor.
2. Normative Notation 2. Normative Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Guidelines 3. Guidelines
We assume that the routers supporting ECMP or LAG (R1 and R2 in the We assume that the routers supporting ECMP or LAG (R1 and R2 in the
above figure) are unaware that they are handling tunneled traffic. above figure) are unaware that they are handling tunneled traffic.
If it is desired to include the IPv6 flow label in an ECMP or LAG If it is desired to include the IPv6 flow label in an ECMP or LAG
hash in the tunneled scenario shown above, the following guidelines hash in the tunneled scenario shown above, the following guidelines
apply: apply:
o Inner packets MUST be encapsulated in an outer IPv6 packet whose o Inner packets MUST be encapsulated in an outer IPv6 packet whose
source and destination addresses are those of the tunnel end source and destination addresses are those of the tunnel end
points (TEPs). points (TEPs).
o The flow label in the outer packet SHOULD be set by the sending o The flow label in the outer packet SHOULD be set by the sending
TEP to a pseudo-random 20-bit value in accordance with [RFC3697]. TEP to a pseudo-random 20-bit value in accordance with [RFC3697]
The same flow label value MUST be used for all packets in a single or its replacement. The same flow label value MUST be used for
user flow, as determined by the IP header fields of the inner all packets in a single user flow, as determined by the IP header
packet. fields of the inner packet.
* Note that this rule is a SHOULD rather than a MUST, to permit * A pseudo-random value is recommended on the basis that it will
individual implementers to take an alternative approach if they provide uniformly distributed input values for whatever hash
wish to do so. Such an alternative MUST conform to [RFC3697]. function is used for load balancing.
* Note that this rule is a recommendation, to permit individual
implementers to take an alternative approach if they wish to do
so. For example, a simpler solution than a pseudo-random value
might be adopted if it was known that the load balancer would
continue to provide uniform distribution of flows with it.
Such an alternative MUST conform to [RFC3697] or its
replacement.
o The sending TEP MUST classify all packets into flows, once it has o The sending TEP MUST classify all packets into flows, once it has
determined that they should enter a given tunnel, and then write determined that they should enter a given tunnel, and then write
the relevant flow label into the outer IPv6 header. A user flow the relevant flow label into the outer IPv6 header. A user flow
could be identified by the ingress TEP most simply by its could be identified by the ingress TEP most simply by its
{destination, source} address pair (coarse) or by its 5-tuple {destination, source} address 2-tuple (coarse) or by its 5-tuple
{dest addr, source addr, protocol, dest port, source port} (fine). {dest addr, source addr, protocol, dest port, source port} (fine).
This is an implementation detail in the sending TEP. At present, ironically, there would be little advantage for IPv6
packets in using the {dest addr, source addr, flow label} 3-tuple.
The choice of n-tuple is an implementation detail in the sending
TEP.
* It might be possible to make this classifier stateless, by * It might be possible to make this classifier stateless, by
using a suitable 20 bit hash of the inner IP header's 2-tuple using a suitable 20 bit hash of the inner IP header's 2-tuple
or 5-tuple as the pseudo-random flow label value. or 5-tuple as the pseudo-random flow label value.
o At intermediate router(s) that perform load distribution of * If the inner packet is an IPv6 packet, its flow label value
tunneled packets whose source address is a TEP, the hash algorithm could also be included in this hash.
used to determine the outgoing component-link in an ECMP and/or * This stateless method creates a small probability of two
LAG toward the next-hop MUST minimally include the triple {dest different user flows hashing to the same flow label. Since RFC
addr, source addr, flow label} to meet the [RFC3697] rules. 3697 allows a source (the TEP in this case) to define any set
* Intermediate router(s) MAY also include {protocol, dest port, of packets that it wishes as a single flow, occasionally
source port} as input keys to the ECMP and/or LAG hash labeling two user flows as a single flow through the tunnel is
algorithms, to provide sufficient entropy in cases where the acceptable.
flow-label is currently set to zero. o At intermediate router(s) that perform load distribution, the hash
algorithm used to determine the outgoing component-link in an ECMP
and/or LAG toward the next-hop MUST minimally include the 3-tuple
{dest addr, source addr, flow label}. This applies whether the
traffic is tunneled traffic only, or a mixture of normal traffic
and tunneled traffic.
* Intermediate IPv6 router(s) will presumably encounter a mixture
of tunneled traffic and normal IPv6 traffic. Because of this,
the design should also include {protocol, dest port, source
port} as input keys to the ECMP and/or LAG hash algorithms, to
provide additional entropy for flows whose flow label is set to
zero, including non-tunneled traffic flows. Whether this is
appropriate depends on the expected traffic mix.
4. Security Considerations 4. Security Considerations
The flow label is not protected in any way and can be forged by an The flow label is not protected in any way and can be forged by an
on-path attacker. Off-path attackers are unlikely to guess a valid on-path attacker. However, it is expected that tunnel end-points and
flow label if a pseudo-random value is used. In either case, the the ECMP or LAG paths will be part of managed infrastructure that is
worst an attacker could do against ECMP or LAG is to attempt to well protected against on-path attacks. Off-path attackers are
selectively overload a particular path. For further discussion, see unlikely to guess a valid flow label if a pseudo-random value is
[RFC3697]. used. In either case, the worst an attacker could do against ECMP or
LAG is to attempt to selectively overload a particular path. For
further discussion, see [RFC3697] or its replacement
5. IANA Considerations 5. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
6. Acknowledgements 6. Acknowledgements
This document was suggest by corridor discussions at IETF76. Joel This document was suggested by corridor discussions at IETF76. Joel
Halpern made crucial comments on an early version. We are grateful Halpern made crucial comments on an early version. We are grateful
to Qinwen Hu for general discussion about the flow label. Valuable to Qinwen Hu for general discussion about the flow label. Valuable
comments and contributions were made by Jarno Rajahalme, Brian comments and contributions were made by Jarno Rajahalme, Brian
Haberman, Sheng Jiang, and others. Haberman, Sheng Jiang, Thomas Narten, and others.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
7. Change log 7. Change log
draft-ietf-6man-flow-ecmp-01: updated after WG Last Call, 2011-02-10
draft-ietf-6man-flow-ecmp-00: after WG adoption at IETF 79, draft-ietf-6man-flow-ecmp-00: after WG adoption at IETF 79,
2010-12-02 2010-12-02
draft-carpenter-flow-ecmp-03: clarifications after further comments, draft-carpenter-flow-ecmp-03: clarifications after further comments,
2010-10-07 2010-10-07
draft-carpenter-flow-ecmp-02: updated after IETF77 discussion, draft-carpenter-flow-ecmp-02: updated after IETF77 discussion,
especially adding LAG, changed to BCP language, added second author, especially adding LAG, changed to BCP language, added second author,
2010-04-14 2010-04-14
skipping to change at page 8, line 17 skipping to change at page 9, line 10
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004. "IPv6 Flow Label Specification", RFC 3697, March 2004.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6man-flow-update] [I-D.ietf-6man-flow-3697bis]
Amante, S., Carpenter, B., and S. Jiang, "Update to the Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
IPv6 flow label specification", Internet-Draft ietf-6man- "IPv6 Flow Label Specification",
flow-update-00, December 2010. draft-ietf-6man-flow-3697bis-00 (work in progress),
January 2011.
[IEEE802.1AX] [IEEE802.1AX]
Institute of Electrical and Electronics Engineers, "Link Institute of Electrical and Electronics Engineers, "Link
Aggregation", IEEE Standard 802.1AX-2008, 2008. Aggregation", IEEE Standard 802.1AX-2008, 2008.
[Lee10] Lee, D., Carpenter, B., and N. Brownlee, "Observations of [Lee10] Lee, D., Carpenter, B., and N. Brownlee, "Observations of
UDP to TCP Ratio and Port Numbers", Fifth International UDP to TCP Ratio and Port Numbers", Fifth International
Conference on Internet Monitoring and Protection ICIMP Conference on Internet Monitoring and Protection ICIMP
2010, May 2010, <http://www.cs.auckland.ac.nz/~brian/ 2010, May 2010, <http://www.cs.auckland.ac.nz/~brian/
udptcp-paper-cam-submit.pdf>. udptcp-paper-cam-submit.pdf>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000. Multicast Next-Hop Selection", RFC 2991, November 2000.
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland, 1142 Auckland, 1142
 End of changes. 30 change blocks. 
113 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/