draft-ietf-mpls-entropy-label-05.txt   draft-ietf-mpls-entropy-label-06.txt 
Network Working Group K. Kompella Network Working Group K. Kompella
Internet-Draft J. Drake Internet-Draft J. Drake
Updates: 3031, 3107, 3209, 5036 Juniper Networks Updates: 3031, 3107, 3209, 5036 Juniper Networks
(if approved) S. Amante (if approved) S. Amante
Intended status: Standards Track Level 3 Communications, LLC Intended status: Standards Track Level 3 Communications, LLC
Expires: February 18, 2013 W. Henderickx Expires: March 10, 2013 W. Henderickx
Alcatel-Lucent Alcatel-Lucent
L. Yong L. Yong
Huawei USA Huawei USA
August 17, 2012 September 6, 2012
The Use of Entropy Labels in MPLS Forwarding The Use of Entropy Labels in MPLS Forwarding
draft-ietf-mpls-entropy-label-05 draft-ietf-mpls-entropy-label-06
Abstract Abstract
Load balancing is a powerful tool for engineering traffic across a Load balancing is a powerful tool for engineering traffic across a
network. This memo suggests ways of improving load balancing across network. This memo suggests ways of improving load balancing across
MPLS networks using the concept of "entropy labels". It defines the MPLS networks using the concept of "entropy labels". It defines the
concept, describes why entropy labels are useful, enumerates concept, describes why entropy labels are useful, enumerates
properties of entropy labels that allow maximal benefit, and shows properties of entropy labels that allow maximal benefit, and shows
how they can be signaled and used for various applications. This how they can be signaled and used for various applications. This
document updates RFCs 3031, 3107, 3209 and 5036. document updates RFCs 3031, 3107, 3209 and 5036.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 February 18, 2013. This Internet-Draft will expire on March 10, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 9, line 9 skipping to change at page 9, line 9
An entropy label (as used here) is a label: An entropy label (as used here) is a label:
1. that is not used for forwarding; 1. that is not used for forwarding;
2. that is not signaled; and 2. that is not signaled; and
3. whose only purpose in the label stack is to provide 'entropy' to 3. whose only purpose in the label stack is to provide 'entropy' to
improve load balancing. improve load balancing.
Entropy labels are generated by an ingress LSR, based entirely on Entropy labels are generated by an ingress LSR, based entirely on
load balancing information. However, they MUST NOT have values in load balancing information. However, they MUST NOT have values in
the reserved label space (0-15) [IANA MPLS Label Values]. To ensure the reserved label space (0-15) [IANA MPLS Label Values].
that they are not used inadvertently for forwarding, entropy labels
SHOULD have a TTL of 0. The TC field of an entropy label can be set
to any value deemed appropriate.
Since entropy labels are generated by an ingress LSR, an egress LSR Since entropy labels are generated by an ingress LSR, an egress LSR
MUST be able to distinguish unambiguously between entropy labels and MUST be able to distinguish unambiguously between entropy labels and
application labels. To accomplish this, it is REQUIRED that the application labels. To accomplish this, it is REQUIRED that the
label immediately preceding an entropy label (EL) in the MPLS label label immediately preceding an entropy label (EL) in the MPLS label
stack be an 'entropy label indicator' (ELI), where preceding means stack be an 'entropy label indicator' (ELI), where preceding means
closer to the top of the label stack (farther from bottom of stack closer to the top of the label stack (farther from bottom of stack
indication). The ELI is a reserved label with value (TBD by IANA). indication). The ELI is a reserved label with value (TBD by IANA).
An ELI MUST have 'Bottom of Stack' (BoS) bit = 0 ([RFC3032]). The How to set values of the TTL, TC and 'Bottom of Stack' (BoS) fields
TTL SHOULD be set to whatever value the label above it in the stack ([RFC3032]) for the ELI and for ELs is discussed in Section 4.2.
has. The TC field can be set to any value deemed appropriate;
typically, this will be the value in the label above the ELI in the
label stack.
Entropy labels are useful for pseudowires ([RFC4447]). [RFC6391] Entropy labels are useful for pseudowires ([RFC4447]). [RFC6391]
explains how entropy labels can be used for RFC 4447-style explains how entropy labels can be used for RFC 4447-style
pseudowires, and thus is complementary to this memo, which focuses on pseudowires, and thus is complementary to this memo, which focuses on
how entropy labels can be used for tunnels, and thus for all other how entropy labels can be used for tunnels, and thus for all other
MPLS applications. MPLS applications.
4. Data Plane Processing of Entropy Labels 4. Data Plane Processing of Entropy Labels
4.1. Egress LSR 4.1. Egress LSR
skipping to change at page 10, line 41 skipping to change at page 10, line 35
3. Based on the application, the load balancing output LB and other 3. Based on the application, the load balancing output LB and other
factors, determine the egress LSR Y, the tunnel to Y, the factors, determine the egress LSR Y, the tunnel to Y, the
specific interface to the next hop, and thus the tunnel label TL. specific interface to the next hop, and thus the tunnel label TL.
Use LB to generate the entropy label EL. Use LB to generate the entropy label EL.
4. If, for the chosen tunnel, Y has not indicated that it can 4. If, for the chosen tunnel, Y has not indicated that it can
process ELs, push <TL> onto the packet. If Y has indicated that process ELs, push <TL> onto the packet. If Y has indicated that
it can process ELs for the tunnel, push <TL, ELI, EL> onto the it can process ELs for the tunnel, push <TL, ELI, EL> onto the
packet. X SHOULD put the same TTL and TC fields for the ELI as packet. X SHOULD put the same TTL and TC fields for the ELI as
it does for TL. This protects LSP behavior in cases where PHP is it does for TL. X MAY choose different values for the TTL and TC
used and the ELI and EL are not stripped at the penultimate hop fields if it is known that the ELI will not be exposed as the top
(see Section 4.4). The TTL for the EL MUST be zero. The TC for label at any point along the LSP (as may happen in cases where
the EL may be any value. PHP is used and the ELI and EL are not stripped at the
penultimate hop (see Section 4.4). The BoS bit for the ELI MUST
be zero. The TTL for the EL MUST be zero to ensure that it is
not used inadvertently for forwarding. The TC for the EL may be
any value. The BoS bit for the EL depends on whether or not
there are more labels in the label stack.
5. X then determines whether further tunnel hierarchy is needed; if 5. X then determines whether further tunnel hierarchy is needed; if
so, X goes back to step 3, possibly with a new egress Y for the so, X goes back to step 3, possibly with a new egress Y for the
new tunnel. Otherwise, X is done, and sends out the packet. new tunnel. Otherwise, X is done, and sends out the packet.
Notes: Notes:
a. X computes load balancing information and generates the EL based a. X computes load balancing information and generates the EL based
on the incoming application packet, even though the signaling of on the incoming application packet, even though the signaling of
EL capability is associated with tunnels. EL capability is associated with tunnels.
skipping to change at page 11, line 34 skipping to change at page 11, line 31
4.3. Transit LSR 4.3. Transit LSR
Transit LSRs MAY operate with no change in forwarding behavior. The Transit LSRs MAY operate with no change in forwarding behavior. The
following are suggestions for optimizations that improve load following are suggestions for optimizations that improve load
balancing, reduce the amount of packet data processed, and/or enhance balancing, reduce the amount of packet data processed, and/or enhance
backward compatibility. backward compatibility.
If a transit LSR recognizes the ELI, it MAY choose to load balance If a transit LSR recognizes the ELI, it MAY choose to load balance
solely on the following label (the EL); otherwise, it SHOULD use as solely on the following label (the EL); otherwise, it SHOULD use as
much of the whole label stack as feasible as keys for the load much of the whole label stack as feasible as keys for the load
balancing function, with the exception that reserved labels MUST NOT balancing function. In any case, reserved labels MUST NOT be used as
be used. keys for the load balancing function.
Some transit LSRs look beyond the label stack for better load Some transit LSRs look beyond the label stack for better load
balancing information. This is a simple, backward compatible balancing information. This is a simple, backward compatible
approach in networks where some ingress LSRs impose ELs and others approach in networks where some ingress LSRs impose ELs and others
don't. However, this is of limited incremental value if an EL is don't. However, this is of limited incremental value if an EL is
indeed present, and requires more packet processing from the LSR. A indeed present, and requires more packet processing from the LSR. A
transit LSR MAY choose to parse the label stack for the presence of transit LSR MAY choose to parse the label stack for the presence of
the ELI, and look beyond the label stack only if it does not find it, the ELI, and look beyond the label stack only if it does not find it,
thus retaining the old behavior when needed, yet avoiding unnecessary thus retaining the old behavior when needed, yet avoiding unnecessary
work if not needed. work if not needed.
skipping to change at page 20, line 19 skipping to change at page 20, line 19
10.1. Reserved Label for ELI 10.1. Reserved Label for ELI
IANA is requested to allocate a reserved label for the Entropy Label IANA is requested to allocate a reserved label for the Entropy Label
Indicator (ELI) from the "Multiprotocol Label Switching Architecture Indicator (ELI) from the "Multiprotocol Label Switching Architecture
(MPLS) Label Values" Registry. (MPLS) Label Values" Registry.
10.2. LDP Entropy Label Capability TLV 10.2. LDP Entropy Label Capability TLV
IANA is requested to allocate the next available value from the IETF IANA is requested to allocate the next available value from the IETF
Consensus range in the LDP TLV Type Name Space Registry as the Consensus range (0x0001-0x07FF) in the LDP TLV Type Name Space
"Entropy Label Capability TLV". Registry as the "Entropy Label Capability TLV".
10.3. BGP Entropy Label Capability Attribute 10.3. BGP Entropy Label Capability Attribute
IANA is requested to allocate the next available Path Attribute Type IANA is requested to allocate the next available Path Attribute Type
Code from the "BGP Path Attributes" registry as the "BGP Entropy Code from the "BGP Path Attributes" registry as the "BGP Entropy
Label Capability Attribute". Label Capability Attribute".
10.4. RSVP-TE Entropy Label Capability flag 10.4. RSVP-TE Entropy Label Capability flag
IANA is requested to allocate a new bit from the "Attribute Flags" IANA is requested to allocate a new bit from the "Attribute Flags"
skipping to change at page 22, line 44 skipping to change at page 22, line 44
announce an entropy label capability for the eBGP learned route. announce an entropy label capability for the eBGP learned route.
Authors' Addresses Authors' Addresses
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: kireeti@juniper.net Email: kireeti.kompella@gmail.com
John Drake John Drake
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: jdrake@juniper.net Email: jdrake@juniper.net
Shane Amante Shane Amante
Level 3 Communications, LLC Level 3 Communications, LLC
 End of changes. 10 change blocks. 
22 lines changed or deleted 21 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/