draft-ietf-6man-flow-ecmp-04.txt   draft-ietf-6man-flow-ecmp-05.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: Standards Track S. Amante
Expires: January 6, 2012 Level 3 Expires: January 20, 2012 Level 3
July 5, 2011 July 19, 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-04 draft-ietf-6man-flow-ecmp-05
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 IP-in-IPv6 tunneled traffic. link aggregation, particularly for IP-in-IPv6 tunneled traffic.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 6, 2012. This Internet-Draft will expire on January 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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.1. Choice of IP Header Fields for Hash Input . . . . . . . . 3
1.2. Flow label rules . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. Change log [RFC Editor: please remove] . . . . . . . . . . . . 8 7. Change log [RFC Editor: please remove] . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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.
skipping to change at page 4, line 47 skipping to change at page 4, line 47
Identifying a flow inside the tunnel is more complicated, Identifying a flow inside the tunnel is more complicated,
particularly because nearly all hardware can only identify flows particularly because nearly all hardware can only identify flows
based on information contained in the outermost IP header. Assume based on information contained in the outermost IP header. Assume
that traffic from many sources to many destinations is aggregated in that traffic from many sources to many destinations is aggregated in
a single IP-in-IP tunnel from tunnel end point (TEP) A to TEP B (see a single IP-in-IP tunnel from tunnel end point (TEP) A to TEP B (see
figure). Then all the packets forming the tunnel have outer source figure). Then all the packets forming the tunnel have outer source
address A and outer destination address B. In all probability they address A and outer destination address B. In all probability they
also have the same port and protocol numbers. If there are multiple 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 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 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 constant and no load sharing will be achieved, i.e., polarization
proportion of traffic from one or small number of tunnels, traffic will occur. If there is a high proportion of traffic from one or
will not be distributed as intended across the paths between R1 and small number of tunnels, traffic will not be distributed as intended
R2. across the paths between R1 and R2, due to partial polarization.
(Related issues arise with MPLS [I-D.ietf-mpls-entropy-label].)
_____ _____ _____ _____ _____ _____ _____ _____
| TEP |_________| R1 |-------------| R2 |_________| TEP | | TEP |_________| R1 |-------------| R2 |_________| TEP |
|__A__| |_____|-------------|_____| |__B__| |__A__| |_____|-------------|_____| |__B__|
tunnel ECMP or LAG tunnel tunnel ECMP or LAG tunnel
here here
As noted above, for IPv6, the 5-tuple is in any case quite As noted above, for IPv6, the 5-tuple is in any case quite
inconvenient to extract due to the next-header placement. The inconvenient to extract due to the next-header placement. The
question therefore arises whether the 20-bit flow label in IPv6 question therefore arises whether the 20-bit flow label in IPv6
packets would be suitable for use as input to an ECMP or LAG hash packets would be suitable for use as input to an ECMP or LAG hash
skipping to change at page 7, line 35 skipping to change at page 7, line 35
{dest addr, source addr, flow label} and MAY also include the {dest addr, source addr, flow label} and MAY also include the
remaining components of the 5-tuple. This applies whether the remaining components of the 5-tuple. This applies whether the
traffic is tunneled traffic only, or a mixture of normal traffic traffic is tunneled traffic only, or a mixture of normal traffic
and tunneled traffic. and tunneled traffic.
* Intermediate IPv6 router(s) will presumably encounter a mixture * Intermediate IPv6 router(s) will presumably encounter a mixture
of tunneled traffic and normal IPv6 traffic. Because of this, of tunneled traffic and normal IPv6 traffic. Because of this,
the design should also include {protocol, dest port, source the design should also include {protocol, dest port, source
port} as input keys to the ECMP and/or LAG hash algorithms, to port} as input keys to the ECMP and/or LAG hash algorithms, to
provide additional entropy for flows whose flow label is set to provide additional entropy for flows whose flow label is set to
zero, including non-tunneled traffic flows. zero, including non-tunneled traffic flows.
o Individual nodes in a network are free to implement different
algorithms that conform to this specification, without impacting
the interoperability or function of the network.
o OAM techniques will need to be adapted to manage ECMP and LAG
based on the flow label. The issues will be similar to those that
arise for MPLS [RFC4379] and pseudowires [I-D.ietf-pwe3-fat-pw].
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. However, it is expected that tunnel end-points and on-path attacker. However, it is expected that tunnel end-points and
the ECMP or LAG paths will be part of managed infrastructure that is the ECMP or LAG paths will be part of managed infrastructure that is
well protected against on-path attacks. Off-path attackers are well protected against on-path attacks (e.g., by using IPsec between
unlikely to guess a valid flow label if an apparently pseudo-random the two tunnel end-points). Off-path attackers are unlikely to guess
and unpredictable value is used. In either case, the worst an a valid flow label if an apparently pseudo-random and unpredictable
attacker could do against ECMP or LAG is to attempt to selectively value is used. In either case, the worst an attacker could do
overload a particular path. For further discussion, see against ECMP or LAG is to attempt to selectively overload a
particular path. For further discussion, see
[I-D.ietf-6man-flow-3697bis]. [I-D.ietf-6man-flow-3697bis].
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 suggested 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 Miguel Garcia, Brian comments and contributions were made by Miguel Garcia, Brian
Haberman, Sheng Jiang, Thomas Narten, Jarno Rajahalme, Brian Weis, Haberman, Sheng Jiang, Thomas Narten, Jarno Rajahalme, Brian Weis,
and others. and others.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
7. Change log [RFC Editor: please remove] 7. Change log [RFC Editor: please remove]
draft-ietf-6man-flow-ecmp-04: IETF Last Call comments, 2011-06-20. draft-ietf-6man-flow-ecmp-05: IESG comments, 2011-07-19.
draft-ietf-6man-flow-ecmp-04: IETF Last Call comments, 2011-07-05.
draft-ietf-6man-flow-ecmp-03: minor editorial fixes, AD comments, draft-ietf-6man-flow-ecmp-03: minor editorial fixes, AD comments,
2011-06-20. 2011-06-20.
draft-ietf-6man-flow-ecmp-02: updated after further comments, 2011- draft-ietf-6man-flow-ecmp-02: updated after further comments, 2011-
05-02. Note that RFC3697bis becomes a normative reference. 05-02. Note that RFC3697bis becomes a normative reference.
draft-ietf-6man-flow-ecmp-01: updated after WG Last Call, 2011-02-10 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,
skipping to change at page 8, line 43 skipping to change at page 9, line 4
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
draft-carpenter-flow-ecmp-01: updated after comments, 2010-02-18 draft-carpenter-flow-ecmp-01: updated after comments, 2010-02-18
draft-carpenter-flow-ecmp-00: original version, 2010-01-19 draft-carpenter-flow-ecmp-00: original version, 2010-01-19
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-6man-flow-3697bis] [I-D.ietf-6man-flow-3697bis]
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", "IPv6 Flow Label Specification",
draft-ietf-6man-flow-3697bis-05 (work in progress), draft-ietf-6man-flow-3697bis-06 (work in progress),
June 2011. July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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-mpls-entropy-label]
Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
draft-ietf-mpls-entropy-label-00 (work in progress),
May 2011.
[I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS Packet Switched Network",
draft-ietf-pwe3-fat-pw-07 (work in progress), July 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>.
skipping to change at page 10, line 5 skipping to change at page 10, line 17
[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. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. 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.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
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
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
 End of changes. 13 change blocks. 
32 lines changed or deleted 57 lines changed or added

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