summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6790.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6790.txt')
-rw-r--r--doc/rfc/rfc6790.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc6790.txt b/doc/rfc/rfc6790.txt
new file mode 100644
index 0000000..5b333bd
--- /dev/null
+++ b/doc/rfc/rfc6790.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Kompella
+Request for Comments: 6790 J. Drake
+Updates: 3031, 3107, 3209, 5036 Juniper Networks
+Category: Standards Track S. Amante
+ISSN: 2070-1721 Level 3 Communications, Inc.
+ W. Henderickx
+ Alcatel-Lucent
+ L. Yong
+ Huawei USA
+ November 2012
+
+
+ The Use of Entropy Labels in MPLS Forwarding
+
+Abstract
+
+ Load balancing is a powerful tool for engineering traffic across a
+ network. This memo suggests ways of improving load balancing across
+ MPLS networks using the concept of "entropy labels". It defines the
+ concept, describes why entropy labels are useful, enumerates
+ properties of entropy labels that allow maximal benefit, and shows
+ how they can be signaled and used for various applications. This
+ document updates RFCs 3031, 3107, 3209, and 5036.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6790.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+
+
+
+Kompella, et al. Standards Track [Page 1]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Conventions Used ...........................................4
+ 1.2. Motivation .................................................6
+ 2. Approaches ......................................................7
+ 3. Entropy Labels and Their Structure ..............................8
+ 4. Data Plane Processing of Entropy Labels .........................9
+ 4.1. Egress LSR .................................................9
+ 4.2. Ingress LSR ...............................................10
+ 4.3. Transit LSR ...............................................11
+ 4.4. Penultimate Hop LSR .......................................12
+ 5. Signaling for Entropy Labels ...................................12
+ 5.1. LDP Signaling .............................................12
+ 5.1.1. Processing the ELC TLV .............................13
+ 5.2. BGP Signaling .............................................13
+ 5.3. RSVP-TE Signaling .........................................14
+ 5.4. Multicast LSPs and Entropy Labels .........................15
+ 6. Operations, Administration, and Maintenance (OAM) and
+ Entropy Labels .................................................15
+ 7. MPLS-TP and Entropy Labels .....................................16
+ 8. Entropy Labels in Various Scenarios ............................16
+ 8.1. LDP Tunnel ................................................17
+ 8.2. LDP over RSVP-TE ..........................................20
+ 8.3. MPLS Applications .........................................20
+ 9. Security Considerations ........................................20
+ 10. IANA Considerations ...........................................21
+ 10.1. Reserved Label for ELI ...................................21
+ 10.2. LDP Entropy Label Capability TLV .........................21
+ 10.3. BGP Entropy Label Capability Attribute ...................21
+ 10.4. RSVP-TE Entropy Label Capability Flag ....................22
+ 11. Acknowledgments ...............................................22
+ 12. References ....................................................22
+ 12.1. Normative References .....................................22
+ 12.2. Informative References ...................................23
+ Appendix A. Applicability of LDP Entropy Label Capability TLV .....24
+
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 2]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+1. Introduction
+
+ Load balancing, or multi-pathing, is an attempt to balance traffic
+ across a network by allowing the traffic to use multiple paths. Load
+ balancing has several benefits: it eases capacity planning, it can
+ help absorb traffic surges by spreading them across multiple paths,
+ and it allows better resilience by offering alternate paths in the
+ event of a link or node failure.
+
+ As providers scale their networks, they use several techniques to
+ achieve greater bandwidth between nodes. Two widely used techniques
+ are: Link Aggregation Group (LAG) and Equal Cost Multi-Path (ECMP).
+ LAG is used to bond together several physical circuits between two
+ adjacent nodes so they appear to higher-layer protocols as a single,
+ higher-bandwidth "virtual" pipe. ECMP is used between two nodes
+ separated by one or more hops, to allow load balancing over several
+ shortest paths in the network. This is typically obtained by
+ arranging IGP metrics such that there are several equal cost paths
+ between source-destination pairs. Both of these techniques may, and
+ often do, coexist in differing parts of a given provider's network,
+ depending on various choices made by the provider.
+
+ A very important requirement when load balancing is that packets
+ belonging to a given "flow" must be mapped to the same path, i.e.,
+ the same exact sequence of links across the network. This is to
+ avoid jitter, latency, and reordering issues for the flow. What
+ constitutes a flow varies considerably. A common example of a flow
+ is a TCP session. Other examples are a Layer 2 Tunneling Protocol
+ (L2TP) session corresponding to a given broadband user or traffic
+ within an ATM virtual circuit.
+
+ To meet this requirement, a node uses certain fields, termed "keys",
+ within a packet's header as input to a load-balancing function
+ (typically a hash function) that selects the path for all packets in
+ a given flow. The keys chosen for the load-balancing function depend
+ on the packet type; a typical set (for IP packets) is the IP source
+ and destination addresses, the protocol type, and (for TCP and UDP
+ traffic) the source and destination port numbers. An overly
+ conservative choice of fields may lead to many flows mapping to the
+ same hash value (and consequently poorer load balancing); an overly
+ aggressive choice may map a flow to multiple values, potentially
+ violating the above requirement.
+
+ For MPLS networks, most of the same principles (and benefits) apply.
+ However, finding useful keys in a packet for the purpose of load
+ balancing can be more of a challenge. In many cases, MPLS
+ encapsulation may require fairly deep inspection of packets to find
+ these keys at transit Label Switching Routers (LSRs).
+
+
+
+Kompella, et al. Standards Track [Page 3]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ 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
+ keys from a given packet, input them to its load-balancing function,
+ and place the result in an additional label, termed the "entropy
+ label", as part of the MPLS label stack it pushes onto that packet.
+
+ The entire label stack of the MPLS packet can then be used by transit
+ LSRs to perform load balancing, as the entropy label introduces the
+ right level of "entropy" into the label stack.
+
+ There are five key reasons why this is beneficial:
+
+ 1. At the ingress LSR, MPLS encapsulation hasn't yet occurred, so
+ deep inspection is not necessary.
+
+ 2. The ingress LSR has more context and information about incoming
+ packets than transit LSRs.
+
+ 3. Ingress LSRs usually operate at lower bandwidths than transit
+ LSRs, allowing them to do more work per packet.
+
+ 4. Transit LSRs do not need to perform deep packet inspection and
+ can load balance effectively using only a packet's MPLS label
+ stack.
+
+ 5. Transit LSRs, not having the full context that an ingress LSR
+ does, have the hard choice between potentially misinterpreting
+ fields in a packet as valid keys for load balancing (causing
+ packet-ordering problems) or adopting a conservative approach
+ (giving rise to sub-optimal load balancing). Entropy labels
+ relieve them of making this choice.
+
+ This memo describes why entropy labels are needed and defines the
+ properties of entropy labels, in particular, how they are generated
+ and received and the expected behavior of transit LSRs. Finally, it
+ describes in general how signaling works and what needs to be
+ signaled as well as specifics for the signaling of entropy labels for
+ LDP [RFC5036], BGP [RFC4271], and RSVP - Traffic Engineering
+ (RSVP-TE) [RFC3209].
+
+1.1. Conventions Used
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 4]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ The following acronyms/initialisms are used:
+
+ BoS: Bottom of Stack
+
+ CE: Customer Edge
+
+ ECMP: Equal Cost Multi-Path
+
+ EL: Entropy Label
+
+ ELC: Entropy Label Capability
+
+ ELI: Entropy Label Indicator
+
+ FEC: Forwarding Equivalence Class
+
+ LAG: Link Aggregation Group
+
+ LER: Label Edge Router
+
+ LSP: Label Switched Path
+
+ LSR: Label Switching Router
+
+ PE: Provider Edge
+
+ PW: Pseudowire
+
+ PHP: Penultimate Hop Popping
+
+ TC: Traffic Class
+
+ TTL: Time to Live
+
+ UHP: Ultimate Hop Popping
+
+ VPLS: Virtual Private LAN (Local Area Network) Service
+
+ VPN: Virtual Private Network
+
+ The term "ingress LSR" (or "egress LSR") is used interchangeably with
+ "ingress LER" (or "egress LER"). The term "application" throughout
+ the text refers to an MPLS application (such as a VPN or VPLS).
+
+ A label stack (say of three labels) is denoted by <L1, L2, L3>, where
+ L1 is the "outermost" label and L3 the "innermost" (closest to the
+ payload). Packet flows are depicted left to right, and signaling is
+ shown right to left (unless otherwise indicated).
+
+
+
+Kompella, et al. Standards Track [Page 5]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ 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
+ clear from the context which is meant.
+
+1.2. Motivation
+
+ MPLS is a very successful generic forwarding substrate that
+ transports several dozen types of protocols, most notably: IP, PWs,
+ VPLS, and IP VPNs. Within each type of protocol, there typically
+ exist several variants, each with a different set of load-balancing
+ keys, e.g., IPv4, IPv6, IPv6 in IPv4, etc. for IP and Ethernet; ATM,
+ Frame-Relay, etc. for PWs. There are also several different types of
+ Ethernet over PW encapsulation, ATM over PW encapsulation, etc.
+ Finally, given the popularity of MPLS, it is likely 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
+ to infer the underlying protocol within an MPLS packet in order to
+ extract appropriate keys for load balancing. Unfortunately, if the
+ 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
+ labels in the label stack as keys for the load-balancing function.
+ The result may be an extremely inequitable distribution of traffic
+ across equal cost paths exiting that LSR. This is because MPLS
+ labels are generally fairly coarse-grained forwarding labels that
+ typically describe a next hop, or provide some demultiplexing and/or
+ forwarding function, and do not describe the packet's underlying
+ protocol.
+
+ On the other hand, an ingress LSR (e.g., a PE router) has detailed
+ knowledge of a packet's contents, typically through a priori
+ configuration of the encapsulations that are expected at a given
+ PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.). They may also have
+ more flexible forwarding hardware, depending on implementation
+ details. PE routers need this information and these capabilities to:
+
+ a. apply the required services for the CE;
+
+ b. discern the packet's Class of Service (CoS) forwarding treatment;
+
+ c. apply filters to forward or block traffic to/from the CE;
+
+ d. forward routing/control traffic to an onboard management
+ processor; and,
+
+ e. load balance the traffic on its uplinks to transit LSRs (e.g., P
+ routers).
+
+
+
+
+Kompella, et al. Standards Track [Page 6]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ By knowing the expected encapsulation types, an ingress LSR router
+ can apply a more specific set of payload parsing routines to extract
+ the keys appropriate for a given protocol. This allows for
+ significantly improved accuracy in determining the appropriate load-
+ balancing behavior for each protocol.
+
+ If the ingress LSR were to capture the flow information so gathered
+ in a convenient form for downstream transit LSRs, transit LSRs could
+ remain completely oblivious to the contents of each MPLS packet and
+ use only the captured flow information to perform load balancing. In
+ particular, there will be no reason to duplicate an ingress LSR's
+ complex packet/payload parsing functionality in a transit LSR. This
+ will result in less complex transit LSRs, enabling them to more
+ easily scale to higher forwarding rates, larger port density, lower
+ power consumption, etc. The idea in this memo is to capture this
+ flow information as a label, the so-called "entropy label".
+
+ Ingress LSRs can also adapt more readily to new protocols and extract
+ the appropriate keys to use for load-balancing packets of those
+ protocols. This means that deploying new protocols or services in
+ edge devices requires fewer concomitant changes in the core,
+ resulting in higher edge-service velocity and, at the same time, more
+ stable core networks.
+
+2. Approaches
+
+ There are two main approaches to encoding load-balancing information
+ in the label stack. The first allocates multiple labels for a
+ particular Forwarding Equivalence Class (FEC). These labels are
+ equivalent in terms of forwarding semantics, but having multiple
+ labels allows flexibility in assigning labels to flows belonging to
+ the same FEC. This approach has the advantage that the label stack
+ has the same depth whether or not one uses label-based load
+ balancing; consequently, there is no change to forwarding operations
+ on transit and egress LSRs. However, it has a major drawback in that
+ there is a significant increase in both signaling and forwarding
+ state.
+
+ The other approach encodes the load-balancing information as an
+ additional label in the label stack, thus increasing the depth of the
+ label stack by one. With this approach, there is minimal change to
+ signaling state for a FEC; also, there is no change in forwarding
+ operations in transit LSRs and no increase of forwarding state in 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".
+ This memo focuses solely on this approach.
+
+
+
+
+
+Kompella, et al. Standards Track [Page 7]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ This latter approach uses upstream-generated entropy labels, which
+ may conflict with downstream-allocated application labels. There are
+ a few approaches to deal with this: 1) allocate a pair of labels for
+ each FEC, one that must have an entropy label below it and one that
+ must not; 2) use a label (the "Entropy Label Indicator") to indicate
+ that the next label is an entropy label; and 3) allow entropy labels
+ only where there is no possible confusion. The first doubles control
+ and data plane state in the network; the last is too restrictive.
+ The approach taken here is the second. In making both the above
+ choices, the trade-off is to increase label stack depth rather than
+ control and data plane state in the network.
+
+ Finally, one may choose to associate ELs with MPLS tunnels (LSPs) or
+ with MPLS applications (e.g., VPNs). (What this entails is described
+ in later sections.) We take the former approach, for the following
+ reasons:
+
+ 1. There are a small number of tunneling protocols for MPLS, but a
+ large and growing number of applications. Defining ELs on a
+ tunnel basis means simpler standards, lower development,
+ interoperability, and testing efforts.
+
+ 2. As a consequence, there will be much less churn in the network as
+ new applications (services) are defined and deployed.
+
+ 3. Processing application labels in the data plane is more complex
+ than processing tunnel labels. Thus, it is preferable to burden
+ the latter rather than the former with EL processing.
+
+ 4. Associating ELs with tunnels makes it simpler to deal with
+ hierarchy, be it LDP-over-RSVP-TE or Carrier's Carrier VPNs.
+ Each layer in the hierarchy can choose independently whether or
+ not they want ELs.
+
+ The cost of this approach is that ELIs will be mandatory; again, the
+ trade-off is the size of the label stack. To summarize, the net
+ increase in the label stack to use entropy labels is two: one
+ reserved label for the ELI and the entropy label itself.
+
+3. Entropy Labels and Their Structure
+
+ An entropy label (as used here) is a label:
+
+ 1. that is not used for forwarding;
+
+ 2. that is not signaled; and
+
+
+
+
+
+Kompella, et al. Standards Track [Page 8]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ 3. whose only purpose in the label stack is to provide "entropy" to
+ improve load balancing.
+
+ Entropy labels are generated by an ingress LSR, based entirely on
+ load-balancing information. However, they MUST NOT have values in
+ the reserved label space (0-15) [RFC3032].
+
+ Since entropy labels are generated by an ingress LSR, an egress LSR
+ MUST be able to distinguish unambiguously between entropy labels and
+ application labels. To accomplish this, it is REQUIRED that the
+ label immediately preceding an Entropy Label (EL) in the MPLS label
+ stack be an Entropy Label Indicator (ELI), where preceding means
+ closer to the top of the label stack (farther from bottom of stack
+ indication). The ELI is a reserved label with value 7. How to set
+ values of the TTL, TC, and "Bottom of Stack" (BoS) fields [RFC3032]
+ for the ELI and for ELs is discussed in Section 4.2.
+
+ Entropy labels are useful for pseudowires [RFC4447]. [RFC6391]
+ explains how entropy labels can be used for pseudowires that are of
+ the RFC 4447 style and is therefore complementary to this memo, which
+ focuses on how entropy labels can be used for tunnels and thus for
+ all other MPLS applications.
+
+4. Data Plane Processing of Entropy Labels
+
+4.1. Egress LSR
+
+ Suppose egress LSR Y is capable of processing entropy labels for a
+ tunnel. Y indicates this to all ingresses via signaling (see
+ Section 5). Y MUST be prepared to deal both with packets with an
+ imposed EL and those without; the ELI will distinguish these cases.
+ If a particular ingress chooses not to impose an EL, Y's processing
+ of the received label stack (which might be empty) is as if Y chose
+ not to accept ELs.
+
+ If an ingress LSR X chooses to impose an EL, then Y will receive a
+ tunnel termination packet with label stack <TL, ELI, EL> <remaining
+ packet header>. Y recognizes TL as the label it distributed to its
+ upstreams for the tunnel and pops it. (Note that TL may be the
+ implicit null label, in which case it doesn't appear in the label
+ stack.) Y then recognizes the ELI and pops two labels: the ELI and
+ the EL. Y then processes the remaining packet header as normal; this
+ may require further processing of tunnel termination, perhaps with
+ further ELI+EL pairs. When processing the final tunnel termination,
+ Y MAY enqueue the packet based on that tunnel TL's or ELI's TC value
+ and MAY use the tunnel TL's or ELI's TTL to compute the TTL of the
+ remaining packet header. The EL's TTL MUST be ignored.
+
+
+
+
+Kompella, et al. Standards Track [Page 9]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ If any ELI processed by Y has the BoS bit set, Y MUST discard the
+ packet and MAY log an error. The EL's BoS bit will indicate whether
+ or not there are more labels in the stack.
+
+4.2. Ingress LSR
+
+ 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
+ insert ELs for packets going into that tunnel. Y MUST handle both
+ cases.
+
+ The steps that X performs to insert ELs are as follows:
+
+ 1. On an incoming packet, identify the application to which the
+ packet belongs; based on this, pick appropriate fields as input
+ 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
+ packet.
+
+ 3. Based on the application, the load-balancing output LB and other
+ factors, determine the egress LSR Y, the tunnel to Y, the
+ specific interface to the next hop, and thus the tunnel label TL.
+ Use LB to generate the entropy label EL.
+
+ 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
+ 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
+ it does for TL. X MAY choose different values for the TTL and TC
+ fields if it is known that the ELI will not be exposed as the top
+ label at any point along the LSP (as may happen in cases where
+ 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 (i.e., BoS is not set). 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
+ 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.
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 10]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ Notes:
+
+ a. X computes load-balancing information and generates the EL based
+ on the incoming application packet, even though the signaling of
+ EL capability is associated with tunnels.
+
+ b. X MAY insert several entropy labels in the stack (each, of
+ course, preceded by an ELI), potentially one for each
+ hierarchical tunnel, provided that the egress for that tunnel has
+ indicated that it can process ELs for that tunnel.
+
+ c. X MUST NOT include an entropy label for a given tunnel unless the
+ egress LSR Y has indicated that it can process entropy labels for
+ that tunnel.
+
+ d. The signaling and use of entropy labels in one direction
+ (signaling from Y to X and data path from X to Y) is completely
+ independent of the signaling and use of entropy labels in the
+ reverse direction (signaling from X to Y and data path from Y to
+ X).
+
+4.3. Transit LSR
+
+ Transit LSRs MAY operate with no change in forwarding behavior. The
+ following are suggestions for optimizations that improve load
+ balancing, reduce the amount of packet data processed, and/or enhance
+ backward compatibility.
+
+ 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
+ much of the whole label stack as feasible as keys for the load-
+ balancing function. In any case, reserved labels MUST NOT be used as
+ keys for the load-balancing function.
+
+ Some transit LSRs look beyond the label stack for better load-
+ balancing information. This is a simple, backward-compatible
+ approach in networks where some ingress LSRs impose ELs and others
+ don't. However, this is of limited incremental value if an EL is
+ indeed present and requires more packet processing from the LSR. A
+ 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,
+ thus retaining the old behavior when needed, yet avoiding unnecessary
+ work if not needed.
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 11]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ As stated in Sections 4.1 and 5, an egress LSR that signals both ELC
+ and implicit null MUST pop the ELI and the next label (which should
+ be the EL), 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
+
+ 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
+
+ An egress LSR Y can signal to ingress LSR(s) its ability to process
+ entropy labels (henceforth called "Entropy Label Capability" or ELC)
+ on a given tunnel. In particular, even if Y signals an implicit null
+ label, indicating that PHP is to be performed, Y MUST be prepared to
+ pop the ELI and EL.
+
+ 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,
+ see Section 8.
+
+5.1. LDP Signaling
+
+ 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 as
+ an Optional Parameter of the Label Mapping Message TLV.
+
+ The presence of the ELC TLV in a Label Mapping Message indicates to
+ ingress LSRs that the egress LSR can process entropy labels for the
+ associated LDP tunnel. The ELC TLV has Type 0x0206 and Length 0.
+
+ The structure of the ELC TLV is shown below.
+
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 12]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |U|F| Type 0x0206 | Length (0) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: Entropy Label Capability TLV
+
+ where:
+
+ U: Unknown bit. This bit MUST be set to 1. If the ELC TLV is not
+ understood by the receiver, then it MUST be ignored.
+
+ F: Forward bit. This bit MUST be set be set to 1. Since the ELC
+ TLV is going to be propagated hop-by-hop, it should be forwarded
+ even by nodes that may not understand it.
+
+ Type: Type field (0x0206)
+
+ Length: Length field. This field specifies the total length in
+ octets of the ELC TLV and is currently defined to be 0.
+
+5.1.1. Processing the ELC TLV
+
+ An LSR that receives a Label Mapping with the ELC TLV but does not
+ understand it MUST propagate it intact to its neighbors and MUST NOT
+ send a notification to the sender (following the meaning of the U-
+ and F-bits).
+
+ An LSR X may receive multiple Label Mappings for a given FEC F from
+ its neighbors. In its turn, X may advertise a Label Mapping for F to
+ its neighbors. If X understands the ELC TLV, and if any of the
+ advertisements it received for FEC F does not include the ELC TLV, X
+ MUST NOT include the ELC TLV in its own advertisements of F. If all
+ the advertised Mappings for F include the ELC TLV, then X MUST
+ advertise its Mapping for F with the ELC TLV. If any of X's
+ neighbors resends its Mapping, sends a new Mapping or sends a Label
+ Withdraw for a previously advertised Mapping for F, X MUST re-
+ evaluate the status of ELC for FEC F, and, if there is a change, X
+ MUST re-advertise its Mapping for F with the updated status of ELC.
+
+5.2. BGP Signaling
+
+ When BGP [RFC4271] is used for distributing Network Layer
+ Reachability Information (NLRI) as described in, for example,
+ [RFC3107], the BGP UPDATE message may include the ELC attribute as
+ part of the Path Attributes. This is an optional, transitive BGP
+
+
+
+
+Kompella, et al. Standards Track [Page 13]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ attribute of value 28. The inclusion of this attribute with an NLRI
+ indicates that the advertising BGP router can process entropy labels
+ as an egress LSR for all routes in that NLRI.
+
+ A BGP speaker S that originates an UPDATE should include the ELC
+ attribute only if both of the following are true:
+
+ A1: S sets the BGP NEXT_HOP attribute to itself AND
+
+ A2: S can process entropy labels.
+
+ Suppose a BGP speaker T receives an UPDATE U with the ELC attribute.
+ T has two choices. T can simply re-advertise U with the ELC
+ attribute if either of the following is true:
+
+ B1: T does not change the NEXT_HOP attribute OR
+
+ B2: T simply swaps labels without popping the entire label stack and
+ processing the payload below.
+
+ An example of the use of B1 is Route Reflectors.
+
+ However, if T changes the NEXT_HOP attribute for U and in the data
+ plane pops the entire label stack to process the payload, T MAY
+ include an ELC attribute for UPDATE U' if both of the following are
+ true:
+
+ C1: T sets the NEXT_HOP attribute of U' to itself AND
+
+ C2: T can process entropy labels.
+
+ Otherwise, T MUST remove the ELC attribute.
+
+5.3. RSVP-TE Signaling
+
+ Entropy label support is signaled in RSVP-TE [RFC3209] using the
+ Entropy Label Capability (ELC) flag in the Attribute Flags TLV of the
+ LSP_ATTRIBUTES object [RFC5420]. The presence of the ELC flag in a
+ Path message indicates that the ingress can process entropy labels in
+ the upstream direction; this only makes sense for a bidirectional LSP
+ and MUST be ignored otherwise. The presence of the ELC flag in a
+ Resv message indicates that the egress can process entropy labels in
+ the downstream direction.
+
+ The bit number for the ELC flag is 9.
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 14]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+5.4. Multicast LSPs and Entropy Labels
+
+ Multicast LSPs [RFC4875] [RFC6388] typically do not use ECMP for load
+ balancing, as the combination of replication and multi-pathing can
+ lead to duplicate traffic delivery. However, these LSPs can traverse
+ bundled links [RFC4201] and LAGs. In both these cases, load
+ balancing is useful, and hence entropy labels can be of value for
+ multicast LSPs.
+
+ The methodology defined for entropy labels here will be used for
+ multicast LSPs; however, the details of signaling and processing ELs
+ for multicast LSPs will be specified in a future document.
+
+6. Operations, Administration, and Maintenance (OAM) and Entropy Labels
+
+ Generally, OAM comprises a set of functions operating in the data
+ plane to allow a network operator to monitor its network
+ infrastructure and to implement mechanisms in order to enhance the
+ general behavior and the level of performance of its network, e.g.,
+ the efficient and automatic detection, localization, diagnosis, and
+ handling of defects.
+
+ Currently defined OAM mechanisms for MPLS include LSP ping/traceroute
+ [RFC4379] and Bidirectional Forwarding Detection (BFD) for MPLS
+ [RFC5884]. The latter provides connectivity verification between the
+ endpoints of an LSP, and recommends establishing a separate BFD
+ session for every path between the endpoints.
+
+ The LSP traceroute procedures of [RFC4379] allow an ingress LSR to
+ obtain label ranges that can be used to send packets on every path to
+ the egress LSR. It works by having the ingress LSR sequentially ask
+ the transit LSRs along a particular path to a given egress LSR to
+ return a label range such that the inclusion of a label in that range
+ in a packet will cause the replying transit LSR to send that packet
+ out the egress interface for that path. The ingress provides the
+ label range returned by transit LSR N to transit LSR N + 1, which
+ returns a label range that is less than or equal in span to the range
+ provided to it. This process iterates until the penultimate transit
+ LSR replies to the ingress LSR with a label range that is acceptable
+ to it and to all LSRs along path preceding it for forwarding a packet
+ along the path.
+
+ However, the LSP traceroute procedures do not specify where in the
+ label stack the value from the label range is to be placed, whether
+ deep packet inspection is allowed, and if so, which keys and key
+ values are to be used.
+
+
+
+
+
+Kompella, et al. Standards Track [Page 15]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ This memo updates LSP traceroute by specifying that the value from
+ the label range is to be placed in the entropy label. Deep packet
+ inspection is thus not necessary, although an LSR may use it,
+ provided it does so consistently, i.e., if the label range to go to a
+ given downstream LSR is computed with deep packet inspection, then
+ the data path should use the same approach and the same keys.
+
+ In order to have a BFD session on a given path, a value from the
+ label range for that path should be used as the EL value for BFD
+ packets sent on that path.
+
+7. MPLS-TP and Entropy Labels
+
+ Since the MPLS Transport Profile (MPLS-TP) does not use ECMP, entropy
+ labels are not applicable to an MPLS-TP deployment.
+
+8. Entropy Labels in Various Scenarios
+
+ This section describes the use of entropy labels in various
+ scenarios. The material in this section is illustrative and offers
+ guidance to implementations, but it does not form a normative part of
+ this specification.
+
+ In the figures below, the following conventions are used to depict
+ processing between X and Y. Note that control plane signaling goes
+ right to left, whereas data plane processing goes left to right.
+
+ Protocols
+ Y: <--- [L, E] Y signals L to X
+ X ------------- Y
+ Data Plane:
+ X-Y: <L, ELI, EL> Label Stack from X -> Y
+ Label Stack Operations:
+ X: +<L, ELI, EL> X pushes <L, ELI, EL>
+ Y: -<L, ELI, EL> Y pops <L, ELI, EL>
+
+ This means that Y signals to X label L for an LDP tunnel. E can be
+ one of:
+
+ 0: meaning egress is NOT entropy label capable or
+
+ 1: meaning egress is entropy label capable
+
+ The line with LS: shows the label stack on the wire. Below that is
+ the operation that each LSR does in the data plane, where + means
+ push the following label stack, - means pop the following label
+ stack, L~L' means swap L with L'.
+
+
+
+
+Kompella, et al. Standards Track [Page 16]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+8.1. LDP Tunnel
+
+ The following figures illustrate several simple intra-AS LDP tunnels.
+ The first diagram shows ultimate hop popping (UHP) with the ingress
+ inserting an EL, the second UHP with no ELs, the third PHP with ELs,
+ and finally, PHP with no ELs, but also with an application label AL
+ (which could, for example, be a VPN label).
+
+ Note that, in all the cases below, the MPLS application does not
+ matter; it may be that X pushes some more labels (perhaps for a VPN
+ or VPLS) below the ones shown, and Y pops them.
+
+ A: <--- [TL4, 1]
+ B: <-- [TL3, 1]
+ W: <-- [TL2, 1]
+ Y: <-- [TL0, 1]
+ X --------------- A --------- B --- W ---------- Y
+ Data Plane:
+ X-A: <TL4, ELI, EL>
+ A-B: <TL3,ELI,EL>
+ B-W: <TL2,ELI,EL>
+ W-Y: <TL0,ELI,EL>
+ Label Stack Operations:
+ X: +<TL4, ELI, EL>
+ A: TL4~TL3
+ B: TL3~TL2
+ W: TL2~TL0
+ Y: -<TL0, ELI, EL>
+
+ Figure 2: LDP with UHP; Ingress Inserts ELs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 17]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ A: <--- [TL4, 1]
+ B: <-- [TL3, 1]
+ W: <-- [TL2, 1]
+ Y: <-- [TL0, 1]
+ X --------------- A --------- B --- W ---------- Y
+ Data Plane:
+ X-A: <TL4>
+ A-B: <TL3>
+ B-W: <TL2>
+ W-Y: <TL0>
+ Label Stack Operations:
+ X: +<TL4>
+ A: TL4~TL3
+ B: TL3~TL2
+ W: TL2~TL0
+ Y: -<TL0>
+
+ Figure 3: LDP with UHP; Ingress Does Not Insert ELs
+
+ Note that in Figure 3, above, the Egress Y is signaling it is EL-
+ capable, but the Ingress X has chosen not to insert ELs.
+
+ A: <--- [TL4, 1]
+ B: <-- [TL3, 1]
+ W: <-- [TL2, 1]
+ Y: <-- [3, 1]
+ X --------------- A --------- B --- W ---------- Y
+ Data Plane:
+ X-A: <TL4, ELI, EL>
+ A-B: <TL3,ELI,EL>
+ B-W: <TL2,ELI,EL>
+ W-Y: <ELI,EL>
+ Label Stack Operations:
+ X: +<TL4, ELI, EL>
+ A: TL4~TL3
+ B: TL3~TL2
+ W: -TL2
+ Y: -<ELI, EL>
+
+ Figure 4: LDP with PHP; Ingress Inserts ELs
+
+
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 18]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ A: <--- [TL4, 1]
+ B: <-- [TL3, 1]
+ W: <-- [TL2, 1]
+ Y: <-- [3, 1]
+ VPN: <------------------------------------------ [AL]
+ X --------------- A --------- B --- W ---------- Y
+ Data Plane:
+ X-A: <TL4, AL>
+ A-B: <TL3, AL>
+ B-W: <TL2, AL>
+ W-Y: <AL>
+ Label Stack Operations:
+ X: +<TL4, AL>
+ A: TL4~TL3
+ B: TL3~TL2
+ W: -TL2
+ Y: -<AL>
+
+ Figure 5: LDP with PHP + VPN; Ingress Does Not Insert ELs
+
+ Note that in Figure 5, above, the Egress Y is signaling it is EL-
+ capable, but the Ingress X has chosen not to insert ELs.
+
+ A: <--- [TL4, 1]
+ B: <-- [TL3, 1]
+ W: <-- [TL2, 1]
+ Y: <-- [3, 1]
+ VPN: <--------------------------------------------- [AL]
+ X --------------- A ------------ B --- W ---------- Y
+ Data Plane:
+ X-A: <TL4,ELI,EL,AL>
+ A-B: <TL3,ELI,EL,AL>
+ B-W: <TL2,ELI,EL,AL>
+ W-Y: <ELI,EL,AL>
+ Label Stack Operations:
+ X: +<TL4,ELI,EL,AL>
+ A: TL4~TL3
+ B: TL3~TL2
+ W: -TL2
+ Y: -<ELI,EL,AL>
+
+ Figure 6: LDP with PHP + VPN; Ingress Inserts ELs
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 19]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+8.2. LDP over RSVP-TE
+
+ Figure 7 illustrates "LDP over RSVP-TE" tunnels. X and Y are the
+ ingress and egress (respectively) of the LDP tunnel; A and W are the
+ ingress and egress of the RSVP-TE tunnel. It is assumed that both
+ the LDP and RSVP-TE tunnels have PHP.
+
+ LDP: <--- [L4, 1] <------- [L3, 1] <--- [3, 1]
+ RSVP-TE: <-- [Rn, 0]
+ <-- [3, 0]
+ X --------------- A --------- B --- W ---------- Y
+ Data Plane:
+ X-A: <L4, ELI, EL>
+ A-B: <Rn,L3,ELI,EL>
+ B-W: <L3,ELI,EL>
+ W-Y: <ELI,EL>
+ Label Stack Operations:
+ X: +<L4, ELI, EL>
+ A: <L4~L3>+Rn
+ B: -Rn
+ W: -L3
+ Y: -<ELI, EL>
+
+ Figure 7: LDP with ELs over RSVP-TE Tunnels without ELs
+
+8.3. MPLS Applications
+
+ For each unicast tunnel starting at an ingress LSR X, X must remember
+ whether the egress for that tunnel can process entropy labels. X
+ does not have to keep state per application running over that tunnel.
+ However, an ingress PE can choose on a per-application basis whether
+ or not to insert ELs. For example, X may have an application for
+ which it does not wish to use ECMP (e.g., circuit emulation) or for
+ which it does not know which keys to use for load balancing (e.g.,
+ Appletalk over a pseudowire). In either of those cases, X may choose
+ not to insert entropy labels but may choose to insert entropy labels
+ for an IP VPN over the same tunnel.
+
+9. Security Considerations
+
+ This document describes advertisement of the capability to support
+ receipt of entropy labels that an ingress LSR may insert in MPLS
+ packets in order to allow transit LSRs to attain better load
+ balancing across LAG and/or ECMP paths in the network.
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 20]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ This document does not introduce new security vulnerabilities to LDP,
+ BGP or RSVP-TE. Please refer to the Security Considerations sections
+ of these protocols ([RFC5036], [RFC4271], and [RFC3209]) for security
+ mechanisms applicable to each.
+
+ Given that there is no end-user control over the values used for
+ entropy labels, there is little risk of entropy label forgery, which
+ could cause uneven load balancing in the network. Note that if the
+ EL value is calculated only based on packet headers, then a
+ relatively efficient wiretapping interface could be added depending
+ on the function used to generate the EL value. An implementation may
+ protect against this by adding some other input to the generation of
+ the EL values that would make it harder to build a table of EL values
+ to tap given knowledge of the keys from the packet. For example, the
+ ingress LSR could generate a random input to the EL generation
+ process. In practice, many ECMP hashing algorithms contain a random
+ factor in any case so as to avoid polarization issues.
+
+ If Entropy Label Capability is not signaled from an egress PE to an
+ ingress PE, due to, for example, malicious configuration activity on
+ the egress PE, then the PE will fall back to not using entropy labels
+ for load balancing traffic over LAG or ECMP paths, which is, in
+ general, no worse than the behavior observed in current production
+ networks. That said, it is recommended that operators monitor
+ changes to PE configurations and, more importantly, the fairness of
+ load distribution over LAG or ECMP paths. If the fairness of load
+ distribution over a set of paths changes that could indicate a
+ misconfiguration, bug, or other non-optimal behavior on their PEs,
+ and they should take corrective action.
+
+10. IANA Considerations
+
+10.1. Reserved Label for ELI
+
+ IANA has allocated a reserved label for the Entropy Label Indicator
+ (ELI) from the "Multiprotocol Label Switching Architecture (MPLS)
+ Label Values" registry.
+
+10.2. LDP Entropy Label Capability TLV
+
+ IANA has allocated the value of 0x0206 from the IETF Consensus range
+ (0x0001-0x07FF) in the "TLV Type Name Space" registry as the "Entropy
+ Label Capability TLV".
+
+10.3. BGP Entropy Label Capability Attribute
+
+ IANA has allocated the Path Attribute Type Code 28 from the "BGP Path
+ Attributes" registry as the "BGP Entropy Label Capability Attribute".
+
+
+
+Kompella, et al. Standards Track [Page 21]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+10.4. RSVP-TE Entropy Label Capability Flag
+
+ IANA has allocated a new bit from the "Attribute Flags" sub-registry
+ of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
+ Parameters" registry.
+
+
+ Bit | Name | Attribute | Attribute | RRO
+ No | | Flags Path | Flags Resv |
+ ----+--------------------------+------------+------------+-----
+ 9 Entropy Label Capability Yes Yes No
+
+11. Acknowledgments
+
+ We wish to thank Ulrich Drafz for his contributions, as well as the
+ entire "hash label" team for their valuable comments and discussion.
+
+ Sincere thanks to Nischal Sheth for his many suggestions and comments
+ and for his careful reading of the document, especially with regard
+ to data plane processing of entropy labels.
+
+ Most of the work Kireeti Kompella did on this document was done while
+ he was at Juniper Networks. He has since moved to Contrail Systems.
+
+12. References
+
+12.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ 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.,
+ Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+ Encoding", RFC 3032, January 2001.
+
+ [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
+ BGP-4", RFC 3107, May 2001.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, December 2001.
+
+ [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
+ Specification", RFC 5036, October 2007.
+
+
+
+
+Kompella, et al. Standards Track [Page 22]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+ [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
+ Ayyangarps, "Encoding of Attributes for MPLS LSP
+ Establishment Using Resource Reservation Protocol Traffic
+ Engineering (RSVP-TE)", RFC 5420, February 2009.
+
+12.2. Informative References
+
+ [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
+ in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
+
+ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+ Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+ [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+ Label Switched (MPLS) Data Plane Failures", RFC 4379,
+ February 2006.
+
+ [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
+ Heron, "Pseudowire Setup and Maintenance Using the Label
+ Distribution Protocol (LDP)", RFC 4447, April 2006.
+
+ [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
+ "Extensions to Resource Reservation Protocol - Traffic
+ Engineering (RSVP-TE) for Point-to-Multipoint TE Label
+ Switched Paths (LSPs)", RFC 4875, May 2007.
+
+ [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+ "Bidirectional Forwarding Detection (BFD) for MPLS Label
+ Switched Paths (LSPs)", RFC 5884, June 2010.
+
+ [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
+ "Label Distribution Protocol Extensions for Point-to-
+ Multipoint and Multipoint-to-Multipoint Label Switched
+ Paths", RFC 6388, November 2011.
+
+ [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
+ J., and S. Amante, "Flow-Aware Transport of Pseudowires
+ over an MPLS Packet Switched Network", RFC 6391,
+ November 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 23]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+Appendix A. Applicability of LDP Entropy Label Capability TLV
+
+ In the case of unlabeled IPv4 (Internet) traffic, the best practice
+ is for an egress LSR to propagate eBGP learned routes within a
+ Service Provider's Autonomous System after resetting the BGP next-hop
+ attribute to one of its loopback IP addresses. That loopback IP
+ address is injected into the Service Provider's IGP and,
+ concurrently, a label assigned to it via LDP. Thus, when an ingress
+ LSR is performing a forwarding lookup for a BGP destination, it
+ recursively resolves the associated next hop to a loopback IP address
+ and associated LDP label of the egress LSR.
+
+ Thus, in the context of unlabeled IPv4 traffic, the LDP Entropy Label
+ Capability TLV will typically be applied only to the FEC for the
+ loopback IP address of the egress LSR, and the egress LSR need not
+ announce an Entropy Label Capability for the eBGP learned route.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 24]
+
+RFC 6790 MPLS Entropy Labels November 2012
+
+
+Authors' Addresses
+
+ Kireeti Kompella
+ Contrail Systems
+ 2350 Mission College Blvd.
+ Santa Clara, CA 95054
+ US
+
+ EMail: kireeti.kompella@gmail.com
+
+
+ John Drake
+ Juniper Networks
+ 1194 N. Mathilda Ave.
+ Sunnyvale, CA 94089
+ US
+
+ EMail: jdrake@juniper.net
+
+
+ Shane Amante
+ Level 3 Communications, Inc.
+ 1025 Eldorado Blvd
+ Broomfield, CO 80021
+ US
+
+ EMail: shane@level3.net
+
+
+ Wim Henderickx
+ Alcatel-Lucent
+ Copernicuslaan 50
+ 2018 Antwerp
+ Belgium
+
+ EMail: wim.henderickx@alcatel-lucent.com
+
+
+ Lucy Yong
+ Huawei USA
+ 5340 Legacy Dr.
+ Plano, TX 75024
+ US
+
+ EMail: lucy.yong@huawei.com
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 25]
+