draft-ietf-mpls-entropy-label-04.txt   draft-ietf-mpls-entropy-label-05.txt 
Network Working Group K. Kompella Network Working Group K. Kompella
Internet-Draft J. Drake Internet-Draft J. Drake
Updates: 3031, 5036 (if approved) Juniper Networks Updates: 3031, 3107, 3209, 5036 Juniper Networks
Intended status: Standards Track S. Amante (if approved) S. Amante
Expires: January 11, 2013 Level 3 Communications, LLC Intended status: Standards Track Level 3 Communications, LLC
W. Henderickx Expires: February 18, 2013 W. Henderickx
Alcatel-Lucent Alcatel-Lucent
L. Yong L. Yong
Huawei USA Huawei USA
July 10, 2012 August 17, 2012
The Use of Entropy Labels in MPLS Forwarding The Use of Entropy Labels in MPLS Forwarding
draft-ietf-mpls-entropy-label-04 draft-ietf-mpls-entropy-label-05
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. This
document updates RFCs 3031, 3107, 3209 and 5036.
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 January 11, 2013. This Internet-Draft will expire on February 18, 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 2, line 23 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 4
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Entropy Labels and Their Structure . . . . . . . . . . . . . . 8 3. Entropy Labels and Their Structure . . . . . . . . . . . . . . 8
4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 9 4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 9
4.1. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 11 4.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 12
5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 11 5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 12
5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 12 5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Processing the ELC TLV . . . . . . . . . . . . . . . . 12 5.1.1. Processing the ELC TLV . . . . . . . . . . . . . . . . 13
5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 13 5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 13
5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 14 5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 14
5.4. Multicast LSPs and Entropy Labels . . . . . . . . . . . . 14 5.4. Multicast LSPs and Entropy Labels . . . . . . . . . . . . 14
6. Operations, Administration, and Maintenance (OAM) and 6. Operations, Administration, and Maintenance (OAM) and
Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 14 Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 15
7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 15 7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 16
8. Entropy Labels in Various Scenarios . . . . . . . . . . . . . 15 8. Entropy Labels in Various Scenarios . . . . . . . . . . . . . 16
8.1. LDP Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. LDP Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. LDP Over RSVP-TE . . . . . . . . . . . . . . . . . . . . . 18 8.2. LDP Over RSVP-TE . . . . . . . . . . . . . . . . . . . . . 18
8.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 18 8.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Reserved Label for ELI . . . . . . . . . . . . . . . . . . 19 10.1. Reserved Label for ELI . . . . . . . . . . . . . . . . . . 20
10.2. LDP Entropy Label Capability TLV . . . . . . . . . . . . . 19 10.2. LDP Entropy Label Capability TLV . . . . . . . . . . . . . 20
10.3. BGP Entropy Label Capability Attribute . . . . . . . . . . 20 10.3. BGP Entropy Label Capability Attribute . . . . . . . . . . 20
10.4. RSVP-TE Entropy Label Capability flag . . . . . . . . . . 20 10.4. RSVP-TE Entropy Label Capability flag . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Applicability of LDP Entropy Label Capability TLV . . 22 Appendix A. Applicability of LDP Entropy Label Capability TLV . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Load balancing, or multi-pathing, is an attempt to balance traffic Load balancing, or multi-pathing, is an attempt to balance traffic
across a network by allowing the traffic to use multiple paths. Load across a network by allowing the traffic to use multiple paths. Load
balancing has several benefits: it eases capacity planning; it can balancing has several benefits: it eases capacity planning; it can
help absorb traffic surges by spreading them across multiple paths; help absorb traffic surges by spreading them across multiple paths;
skipping to change at page 3, line 51 skipping to change at page 3, line 51
traffic) the source and destination port numbers. An overly traffic) the source and destination port numbers. An overly
conservative choice of fields may lead to many flows mapping to the conservative choice of fields may lead to many flows mapping to the
same hash value (and consequently poorer load balancing); an overly same hash value (and consequently poorer load balancing); an overly
aggressive choice may map a flow to multiple values, potentially aggressive choice may map a flow to multiple values, potentially
violating the above requirement. violating the above requirement.
For MPLS networks, most of the same principles (and benefits) apply. For MPLS networks, most of the same principles (and benefits) apply.
However, finding useful keys in a packet for the purpose of load However, finding useful keys in a packet for the purpose of load
balancing can be more of a challenge. In many cases, MPLS balancing can be more of a challenge. In many cases, MPLS
encapsulation may require fairly deep inspection of packets to find encapsulation may require fairly deep inspection of packets to find
these keys at transit LSRs. these keys at transit Label Switching Routers (LSRs).
One way to eliminate the need for this deep inspection is to have the One way to eliminate the need for this deep inspection is to have the
ingress LSR of an MPLS Label Switched Path extract the appropriate ingress LSR of an MPLS Label Switched Path extract the appropriate
keys from a given packet, input them to its load balancing function, keys from a given packet, input them to its load balancing function,
and place the result in an additional label, termed the 'entropy and place the result in an additional label, termed the 'entropy
label', as part of the MPLS label stack it pushes onto that packet. label', as part of the MPLS label stack it pushes onto that packet.
The packet's MPLS entire label stack can then be used by transit LSRs The packet's MPLS entire label stack can then be used by transit LSRs
to perform load balancing, as the entropy label introduces the right to perform load balancing, as the entropy label introduces the right
level of "entropy" into the label stack. level of "entropy" into the label stack.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
ELC: Entropy Label Capability ELC: Entropy Label Capability
ELI: Entropy Label Indicator ELI: Entropy Label Indicator
FEC: Forwarding Equivalence Class FEC: Forwarding Equivalence Class
LAG: Link Aggregation Group LAG: Link Aggregation Group
LER: Label Edge Router LER: Label Edge Router
LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
PE: Provider Edge Router PE: Provider Edge Router
PW: Pseudowire
PHP: Penultimate Hop Popping PHP: Penultimate Hop Popping
TC: Traffic Class TC: Traffic Class
TTL: Time-to-Live TTL: Time-to-Live
UHP: Ultimate Hop Popping UHP: Ultimate Hop Popping
VPLS: Virtual Private LAN (Local Area Network) Service VPLS: Virtual Private LAN (Local Area Network) Service
skipping to change at page 6, line 7 skipping to change at page 6, line 9
L1 is the "outermost" label and L3 the innermost (closest to the L1 is the "outermost" label and L3 the innermost (closest to the
payload). Packet flows are depicted left to right, and signaling is payload). Packet flows are depicted left to right, and signaling is
shown right to left (unless otherwise indicated). shown right to left (unless otherwise indicated).
The term 'label' is used both for the entire 32-bit label stack entry The term 'label' is used both for the entire 32-bit label stack entry
and the 20-bit label field within a label stack entry. It should be and the 20-bit label field within a label stack entry. It should be
clear from the context which is meant. clear from the context which is meant.
1.2. Motivation 1.2. Motivation
MPLS is very successful generic forwarding substrate that transports MPLS is a very successful generic forwarding substrate that
several dozen types of protocols, most notably: IP, PWE3, VPLS and IP transports several dozen types of protocols, most notably: IP, PWs,
VPNs. Within each type of protocol, there typically exist several VPLS and IP VPNs. Within each type of protocol, there typically
variants, each with a different set of load balancing keys, e.g., for exist several variants, each with a different set of load balancing
IP: IPv4, IPv6, IPv6 in IPv4, etc.; for PWE3: Ethernet, ATM, Frame- keys, e.g., for IP: IPv4, IPv6, IPv6 in IPv4, etc.; for PWs:
Relay, etc. There are also several different types of Ethernet over Ethernet, ATM, Frame-Relay, etc. There are also several different
PW encapsulation, ATM over PW encapsulation, etc. as well. Finally, types of Ethernet over PW encapsulation, ATM over PW encapsulation,
given the popularity of MPLS, it is likely that it will continue to etc. as well. Finally, given the popularity of MPLS, it is likely
be extended to transport new protocols. that it will continue to be extended to transport new protocols.
Currently, each transit LSR along the path of a given LSP has to try Currently, each transit LSR along the path of a given LSP has to try
to infer the underlying protocol within an MPLS packet in order to to infer the underlying protocol within an MPLS packet in order to
extract appropriate keys for load balancing. Unfortunately, if the extract appropriate keys for load balancing. Unfortunately, if the
transit LSR is unable to infer the MPLS packet's protocol (as is transit LSR is unable to infer the MPLS packet's protocol (as is
often the case), it will typically use the topmost (or all) MPLS often the case), it will typically use the topmost (or all) MPLS
labels in the label stack as keys for the load balancing function. labels in the label stack as keys for the load balancing function.
The result may be an extremely inequitable distribution of traffic The result may be an extremely inequitable distribution of traffic
across equal-cost paths exiting that LSR. This is because MPLS across equal-cost paths exiting that LSR. This is because MPLS
labels are generally fairly coarse-grained forwarding labels that labels are generally fairly coarse-grained forwarding labels that
skipping to change at page 8, line 46 skipping to change at page 9, line 4
increase in the label stack to use entropy labels is two: one increase in the label stack to use entropy labels is two: one
reserved label for the ELI, and the entropy label itself. reserved label for the ELI, and the entropy label itself.
3. Entropy Labels and Their Structure 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) [IANA MPLS Label Values]. To ensure the reserved label space (0-15) [IANA MPLS Label Values]. To ensure
that they are not used inadvertently for forwarding, entropy labels that they are not used inadvertently for forwarding, entropy labels
SHOULD have a TTL of 0. The CoS field of an entropy label can be set SHOULD have a TTL of 0. The TC field of an entropy label can be set
to any value deemed appropriate. 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. This is accomplished by REQUIRING that the label application labels. To accomplish this, it is REQUIRED that the
immediately preceding an entropy label (EL) in the MPLS label stack label immediately preceding an entropy label (EL) in the MPLS label
be an 'entropy label indicator' (ELI), where preceding means closer stack be an 'entropy label indicator' (ELI), where preceding means
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 An ELI MUST have 'Bottom of Stack' (BoS) bit = 0 ([RFC3032]). The
TTL SHOULD be set to whatever value the label above it in the stack 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; 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 typically, this will be the value in the label above the ELI in the
label stack. 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
skipping to change at page 10, line 21 skipping to change at page 10, line 25
4.2. Ingress LSR 4.2. Ingress LSR
If an egress LSR Y indicates via signaling that it can process ELs on If an egress LSR Y indicates via signaling that it can process ELs on
a particular tunnel, an ingress LSR X can choose whether or not to a particular tunnel, an ingress LSR X can choose whether or not to
insert ELs for packets going into that tunnel. Y MUST handle both insert ELs for packets going into that tunnel. Y MUST handle both
cases. cases.
The steps that X performs to insert ELs are as follows: The steps that X performs to insert ELs are as follows:
1. On an incoming packet, identify the application to which the 1. On an incoming packet, identify the application to which the
packet belongs, and thereby pick the fields to input to the load packet belongs; based on this, pick appropriate fields as input
balancing function; call the output LB. to the load balancing function; apply the load balancing function
to these input fields, and let LB be the output.
2. Determine the application label AL (if any). Push <AL> onto the 2. Determine the application label AL (if any). Push <AL> onto the
packet. packet.
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. The TTL for the EL MUST be zero. The TC for the it does for TL. This protects LSP behavior in cases where PHP is
EL may be any value. used and the ELI and EL are not stripped at the penultimate hop
(see Section 4.4). The TTL for the EL MUST be zero. The TC for
the EL may be any value.
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 36 skipping to change at page 11, line 44
balancing function, with the exception that reserved labels MUST NOT balancing function, with the exception that reserved labels MUST NOT
be used. be used.
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 avoided unnecessary thus retaining the old behavior when needed, yet avoiding unnecessary
work if not. work if not needed.
As stated in Section 4.1 and Section 5, an egress LSR that signals
both ELC and implicit null MUST pop the ELI and the next label if it
encounters a packet with the ELI as the topmost label. Any other LSR
(including PHP LSRs) MUST drop such packets, as per section 3.18 of
[RFC3031].
4.4. Penultimate Hop LSR 4.4. Penultimate Hop LSR
No change is needed at penultimate hop LSRs. No change is needed at penultimate hop LSRs. However, a PHP LSR that
recognizes the ELI MAY choose to pop the ELI and following label
(which should be an entropy label) in addition to popping the tunnel
label, provided that doing so doesn't diminish its ability to load
balance on the next hop.
5. Signaling for Entropy Labels 5. Signaling for Entropy Labels
An egress LSR Y can signal to ingress LSR(s) its ability to process An egress LSR Y can signal to ingress LSR(s) its ability to process
entropy labels (henceforth called "Entropy Label Capability" or ELC) entropy labels (henceforth called "Entropy Label Capability" or ELC)
on a given tunnel. Note that Entropy Label Capability may be on a given tunnel. In particular, even if Y signals an implicit null
asymmetric: if LSRs X and Y are at opposite ends of a tunnel, X may label, indicating that PHP is to be performed, Y MUST be prepared to
be able to process entropy labels, whereas Y may not. The signaling pop the ELI and EL.
extensions below allow for this asymmetry.
Note that Entropy Label Capability may be asymmetric: if LSRs X and Y
are at opposite ends of a tunnel, X may be able to process entropy
labels, whereas Y may not. The signaling extensions below allow for
this asymmetry.
For an illustration of signaling and forwarding with entropy labels, For an illustration of signaling and forwarding with entropy labels,
see Section 8. see Section 8.
5.1. LDP Signaling 5.1. LDP Signaling
A new LDP TLV ([RFC5036]) is defined to signal an egress's ability to A new LDP TLV ([RFC5036]) is defined to signal an egress's ability to
process entropy labels. This is called the ELC TLV, and may appear process entropy labels. This is called the ELC TLV, and may appear
as an Optional Parameter of the Label Mapping Message TLV. as an Optional Parameter of the Label Mapping Message TLV.
skipping to change at page 20, line 31 skipping to change at page 21, line 4
11. Acknowledgments 11. Acknowledgments
We wish to thank Ulrich Drafz for his contributions, as well as the We wish to thank Ulrich Drafz for his contributions, as well as the
entire 'hash label' team for their valuable comments and discussion. entire 'hash label' team for their valuable comments and discussion.
Sincere thanks to Nischal Sheth for his many suggestions and Sincere thanks to Nischal Sheth for his many suggestions and
comments, and his careful reading of the document, especially with comments, and his careful reading of the document, especially with
regard to data plane processing of entropy labels. regard to data plane processing of entropy labels.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangar, "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.
12.2. Informative References 12.2. Informative References
[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
Networks (VPNs)", RFC 4364, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006. Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
 End of changes. 29 change blocks. 
61 lines changed or deleted 73 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/