< draft-ietf-mpls-entropy-label-00.txt   draft-ietf-mpls-entropy-label-01.txt >
Network Working Group K. Kompella Network Working Group K. Kompella
Internet-Draft J. Drake Internet-Draft J. Drake
Updates: 3031 (if approved) Juniper Networks Updates: 3031 (if approved) Juniper Networks
Intended status: Standards Track S. Amante Intended status: Standards Track S. Amante
Expires: November 6, 2011 Level 3 Communications, LLC Expires: May 3, 2012 Level 3 Communications, LLC
W. Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
L. Yong L. Yong
Huawei USA Huawei USA
May 5, 2011 October 31, 2011
The Use of Entropy Labels in MPLS Forwarding The Use of Entropy Labels in MPLS Forwarding
draft-ietf-mpls-entropy-label-00 draft-ietf-mpls-entropy-label-01
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. how they can be signaled and used for various applications.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 6, 2011. This Internet-Draft will expire on May 3, 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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. Conventions used . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 4
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Entropy Labels and Their Structure . . . . . . . . . . . . . . 7
4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 8 4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 8
4.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 9 5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 10
5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 10 5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 10
5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 11 5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 11
5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 12 5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 12
6. Operations, Administration, and Maintenance (OAM) and 6. Operations, Administration, and Maintenance (OAM) and
Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 13 Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 13
7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 14 7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 14
8. Point-to-Multipoint LSPs and Entropy Labels . . . . . . . . . 15 8. Point-to-Multipoint LSPs and Entropy Labels . . . . . . . . . 15
9. Entropy Labels and Applications . . . . . . . . . . . . . . . 15 9. Entropy Labels and Applications . . . . . . . . . . . . . . . 15
9.1. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. LDP Pseudowires . . . . . . . . . . . . . . . . . . . . . 17 9.2. LDP Pseudowires . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 7, line 16 skipping to change at page 7, line 16
The other approach encodes the load balancing information as an The other approach encodes the load balancing information as an
additional label in the label stack, thus increasing the depth of the additional label in the label stack, thus increasing the depth of the
label stack by one. With this approach, there is minimal change to label stack by one. With this approach, there is minimal change to
signaling state for a FEC; also, there is no change in forwarding signaling state for a FEC; also, there is no change in forwarding
operations in transit LSRs, and no increase of forwarding state in operations in transit LSRs, and no increase of forwarding state in
any LSR. The only purpose of the additional label is to increase the any LSR. The only purpose of the additional label is to increase the
entropy in the label stack, so this is called an "entropy label". entropy in the label stack, so this is called an "entropy label".
This memo focuses solely on this approach. This memo focuses solely on this approach.
3. Entropy Labels 3. Entropy Labels and Their Structure
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). Entropy labels MUST be at the the reserved label space (0-15). To ensure that they are not used
bottom of the label stack, and thus the 'Bottom of Stack' (S) bit inadvertently for forwarding, entropy labels SHOULD have a TTL of 0.
([RFC3032]) in the label should be set. To ensure that they are not The CoS field of an entropy label can be set to any value deemed
used inadvertently for forwarding, entropy labels SHOULD have a TTL appropriate.
of 0.
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 tell unambiguously that a given label is an entropy MUST be able to tell unambiguously that a given label is an entropy
label. If any ambiguity is possible, the label above the entropy label. If any ambiguity is possible, the label above the entropy
label MUST be an 'entropy label indicator' (ELI), which indicates label MUST be an 'entropy label indicator' (ELI), which indicates
that the following Label is an entropy label. An ELI is typically that the following Label is an entropy label. An ELI is typically
signaled by an egress LSR and is added to the MPLS label stack along signaled by an egress LSR and is added to the MPLS label stack along
with an entropy label by an ingress LSR. For many applications, the with an entropy label by an ingress LSR. For many applications, the
use of entropy labels is unambiguous, and an ELI is not needed. If use of entropy labels is unambiguous, and an ELI is not needed. An
used, an ELI MUST have S = 0 and SHOULD have a TTL of 0. ELI MUST have 'Bottom of Stack' (S) bit = 0 ([RFC3032]). The TTL
SHOULD be set to whatever value the label above it in the stack has.
The CoS field can be set to any value deemed appropriate; typically,
this will be the value in the label above it in the stack.
Applications for MPLS entropy labels include pseudowires ([RFC4447]), Applications for MPLS entropy labels include pseudowires ([RFC4447]),
Layer 3 VPNs ([RFC4364]), VPLS ([RFC4761], [RFC4762]) and Tunnel LSPs Layer 3 VPNs ([RFC4364]), VPLS ([RFC4761], [RFC4762]) and Tunnel LSPs
carrying, say, IP traffic. [I-D.ietf-pwe3-fat-pw] explains how carrying, say, IP traffic. [I-D.ietf-pwe3-fat-pw] explains how
entropy labels can be used for RFC 4447-style pseudowires, and thus entropy labels can be used for RFC 4447-style pseudowires, and thus
is complementary to this memo, which focuses on several other is complementary to this memo, which focuses on several other
applications of entropy labels. applications of entropy labels.
4. Data Plane Processing of Entropy Labels 4. Data Plane Processing of Entropy Labels
4.1. Ingress LSR 4.1. Ingress LSR
Suppose that for a particular application (or service or FEC), an Suppose that for a particular application (or service or FEC), an
ingress LSR X is to push label stack <TL, AL>, where TL is the ingress LSR X is to push label stack <TL, AL>, where TL is the
'tunnel label' and AL is the 'application label'. (Note the use of 'tunnel label' and AL is the 'application label'. (Note the use of
the convention for label stacks described in Section 1.1. The use of the convention for label stacks described in Section 1.1. The use of
a two-label stack is just for illustrative purposes.) Suppose a two-label stack is just for illustrative purposes.) Suppose
furthermore that the egress LSR Y has told X that it is capable of furthermore that the egress LSR Y has told X that it is capable of
processing entropy labels for this application. If X can insert processing entropy labels for this application. If X cannot insert
entropy labels, it may use a label stack of <TL, AL, EL> for this entropy labels, it simply uses a label stack of <TL, AL> for this
application, where EL is the entropy label. application. If X can insert entropy labels, it does the following
for an incoming packet:
When a packet for this application arrives at X, X does the
following:
1. X identifies the application to which the packet belongs, 1. X identifies the application to which the packet belongs,
identifies the egress LSR as Y, and thereby picks the outgoing identifies the egress LSR as Y, and thereby picks the outgoing
label stack <TL, AL> to push onto the packet to send to Y; label stack <TL, AL> to push onto the packet to send to Y.
2. X determines which keys that it will use for load balancing; 2. X determines which keys that it will use for load balancing.
3. X, having kept state that Y can process entropy labels for this 3. X, having kept state that Y can process entropy labels for this
application, generates an entropy label EL (based on the output application, generates an entropy label EL (based on the output
of the load balancing function), and of the load balancing function).
4. X pushes <TL, AL, EL> on to the packet before forwarding it to 4. If Y does not need an ELI, X pushes <TL, AL, EL> onto the packet
the next LSR on its way to Y. before forwarding it to the next hop to Y.
EL is a 'regular' 32-bit label whose S bit MUST be 1 and whose TTL 5. If Y requires an ELI, X pushes <TL, AL, E, EL> onto the packet
field SHOULD be 0. The load balancing information is encoded in the before forwarding it to the next hop to Y, where E is a label
20-bit label field. If X is told (via signaling) that it must use an whose 20-bit label field is the ELI that Y signaled, and whose
entropy label indicator with label value E, then X instead pushes other fields are set as per Section 3.
<TL, AL, ELI, EL> onto the packet, where ELI is a label whose S bit
MUST be 0, whose TTL SHOULD be 0, and whose 20-bit label field MUST
be E. The CoS fields for EL and ELI can be set to any values.
Note that ingress LSR X MUST NOT include an entropy label unless the Note that ingress LSR X MUST NOT include an entropy label unless the
egress LSR Y for this application has indicated that it is ready to egress LSR Y for this application has indicated that it is ready to
receive entropy labels. Furthermore, if Y has signaled that an ELI receive entropy labels. Furthermore, if Y has signaled that an ELI
is needed, then X MUST include the ELI before the entropy label. is needed, then X MUST include the ELI before the entropy label.
Note that the signaling and use of entropy labels in one direction Note that the signaling and use of entropy labels in one direction
(signaling from Y to X, and data path from X to Y) has no bearing on (signaling from Y to X, and data path from X to Y) has no bearing on
the behavior in the opposite direction (signaling from X to Y, and the behavior in the opposite direction (signaling from X to Y, and
data path from Y to X). data path from Y to X).
4.2. Transit LSR 4.2. Transit LSR
Transit LSRs have virtually no change in forwarding behavior. For Transit LSRs have virtually no change in forwarding behavior. For
load balancing, transit LSRs SHOULD use the whole label stack as keys load balancing, transit LSRs SHOULD use the whole label stack as keys
for the load balancing function. Transit LSRs MAY choose to look for the load balancing function. Transit LSRs MUST NOT include
beyond the label stack for further keys; however, if entropy labels reserved labels as input to its load balancing function. Transit
are being used, this may not be very useful. Looking beyond the LSRs MAY choose to look beyond the label stack for further keys;
label stack may be the simplest approach in an environment where some however, if entropy labels are being used, this may not be very
ingress LSRs use entropy labels and others don't, or for backward useful. Looking beyond the label stack may be the simplest approach
compatibility. Thus, other than using the full label stack as input in an environment where some ingress LSRs use entropy labels and
to the load balancing function, transit LSRs are almost unaffected by others don't, or for backward compatibility. Thus, other than using
the use of entropy labels. the full label stack as input to the load balancing function, transit
LSRs are almost unaffected by the use of entropy labels.
4.3. Egress LSR 4.3. Egress LSR
If egresss LSR Y signals that it is capable of processing entropy Suppose egress LSR Y signals that it is capable of processing entropy
labels without an ELI for an application, then when Y receives a labels for a tunnel or an application with label L. There are three
packet with the application label, then Y looks to see if the S bit cases of interest: (a) L is the implicit NULL label, in which case an
is set. If so, Y applies its usual processing rules to the packet, ELI is mandatory; (b) L is not the implicit NULL label and an ELI is
including popping the application label. If the S bit is not set, Y not required (L's S bit will be used to determine whether or not
assumes that the label below the application label is an entropy there is an EL); and (c) L is not the implicit NULL label but an ELI
label and pops both the application label and the entropy label. Y is required.
SHOULD ensure that the entropy label has its S bit set. Y then
processes the packet as usual. Implementations may choose the order
in which they apply these operations, but the net result should be as
specified.
If Y signals that it is capable of processing entropy labels but that a1) Y receives an unlabeled packet. There is obviously no EL; Y
an ELI is necessary for a given application, then when Y receives a processes the packet as usual.
packet with the application label, Y processes the application label
as usual, then pops it. Y then checks whether the S bit on the a2) Y receives a packet whose top label is the ELI. Y processes the
application label is set. If not, Y looks to see if the label below TTL and CoS fields of the ELI label, ensures that the S bit is 0,
the application label is the ELI. If so, Y further pops both the ELI then pops it, and pops the next label as well (which must be the
and the label below (which should be the entropy label). Y SHOULD EL), then pops it. Y processes the remaining payload as usual.
ensure that the ELI has its S bit unset, and that the entropy label
has its S bit set. If the S bit of the application label is set, or b) Y receives a packet with top label L, and an ELI is not required.
the label below is not the ELI, Y processes the packet as usual Y processes L as usual; if L's S bit is 1, the label stack is
(there is no entropy label). done. If L's S bit is 0, the following label is the EL. Y pops
the EL. Y processes the payload as usual.
c) Y receives a packet with top label L. Y processes L as usual; if
L's S bit is 1, the label stack is done. If L's S bit is 0, Y
checks the following label. If it is the ELI label, Y processes
the TTL and CoS fields of the ELI, ensures that the S bit is 0,
pops the ELI label and the following label (which is the EL), and
processes the remaining payload as usual.
If there is an ELI with S bit = 1, there is an error in the label
stack. Note that the TTL field of the EL (if present) will be 0; Y
MUST NOT react to this.
5. Signaling for Entropy Labels 5. Signaling for Entropy Labels
An egress LSR Y may signal to ingress LSR(s) its ability to process An egress LSR Y may signal to ingress LSR(s) its ability to process
entropy labels on a per-application (or per-FEC) basis. As part of entropy labels on a per-application (or per-FEC) basis. As part of
this signaling, Y also signals the ELI to use, if any. this signaling, Y also signals the ELI to use, if any.
In cases where an application label is used and must be the In cases where an application label is used and must be the
bottommost label in the label stack, Y MAY signal that no ELI is bottommost label in the label stack, Y MAY signal that no ELI is
needed for that application. needed for that application.
skipping to change at page 23, line 38 skipping to change at page 23, line 38
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, February 2009.
13.2. Informative References 13.2. Informative References
[I-D.ietf-pwe3-fat-pw] [I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS PSN", draft-ietf-pwe3-fat-pw-05 (work in over an MPLS Packet Switched Network",
progress), October 2010. draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
 End of changes. 19 change blocks. 
64 lines changed or deleted 70 lines changed or added

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