< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/