draft-ietf-mpls-forwarding-03.txt		draft-ietf-mpls-forwarding-04.txt
	MPLS C. Villamizar, Ed.		MPLS C. Villamizar, Ed.
	Internet-Draft OCCNC		Internet-Draft OCCNC
	Intended status: Informational K. Kompella		Intended status: Informational K. Kompella
	Expires: May 18, 2014 Juniper Networks		Expires: June 20, 2014 Juniper Networks
	S. Amante		S. Amante
	Apple Inc.		Apple Inc.
	A. Malis		A. Malis
	Consultant		Consultant
	C. Pignataro		C. Pignataro
	Cisco		Cisco
	November 14, 2013		December 17, 2013
	MPLS Forwarding Compliance and Performance Requirements		MPLS Forwarding Compliance and Performance Requirements
	draft-ietf-mpls-forwarding-03		draft-ietf-mpls-forwarding-04
	Abstract		Abstract
	This document provides guidelines for implementers regarding MPLS		This document provides guidelines for implementers regarding MPLS
	forwarding and a basis for evaluations of forwarding implementations.		forwarding and a basis for evaluations of forwarding implementations.
	Guidelines cover many aspects of MPLS forwarding. Topics are		Guidelines cover many aspects of MPLS forwarding. Topics are
	highlighted where implementers might otherwise overlook practical		highlighted where implementers might otherwise overlook practical
	requirements which are unstated or under emphasized or are optional		requirements which are unstated or under emphasized or are optional
	for conformance to RFCs but are often considered mandatory by		for conformance to RFCs but are often considered mandatory by
	providers.		providers.
	skipping to change at page 1, line 43		skipping to change at page 1, line 43
	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 May 18, 2014.		This Internet-Draft will expire on June 20, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 38		skipping to change at page 2, line 38
	2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10		2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10
	2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11		2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11
	2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12		2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12
	2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13		2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13
	2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14		2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14
	2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15		2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15
	2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15		2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15
	2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15		2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15
	2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16		2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16
	2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 16		2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 16
	2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 17		2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18
	2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 17		2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 18
	2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 18		2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 19
	2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 20		2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21
	2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21		2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22
	2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 22		2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 22
	2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22		2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23
	2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 22		2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 23
	2.4.5. Fields Used for Multipath Load Balance . . . . . . . 23		2.4.5. Fields Used for Multipath Load Balance . . . . . . . 23
	2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 23		2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24
	2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 25		2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 25
	2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 26		2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 27
	2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 26		2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 27
	2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27		2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 28
	2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 27		2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 28
	2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 28		2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 28
	2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 30		2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 30
	2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 31		2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 31
	2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31		2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 32
	2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 32		2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 33
	2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33		2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33
	2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 34		2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 34
	3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 34		3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 35
	3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 34		3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 35
	3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36		3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36
	3.3. Multipath Capabilities and Performance . . . . . . . . . 37		3.3. Multipath Capabilities and Performance . . . . . . . . . 37
	3.4. Pseudowire Capabilities and Performance . . . . . . . . . 37		3.4. Pseudowire Capabilities and Performance . . . . . . . . . 38
	3.5. Entropy Label Support and Performance . . . . . . . . . . 38		3.5. Entropy Label Support and Performance . . . . . . . . . . 38
	3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 38		3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 38
	3.7. OAM Capabilities and Performance . . . . . . . . . . . . 38		3.7. OAM Capabilities and Performance . . . . . . . . . . . . 39
	4. Forwarding Compliance and Performance Testing . . . . . . . . 39		4. Forwarding Compliance and Performance Testing . . . . . . . . 39
	4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 39		4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 40
	4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40		4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40
	4.3. Multipath Capabilities and Performance . . . . . . . . . 40		4.3. Multipath Capabilities and Performance . . . . . . . . . 41
	4.4. Pseudowire Capabilities and Performance . . . . . . . . . 41		4.4. Pseudowire Capabilities and Performance . . . . . . . . . 42
	4.5. Entropy Label Support and Performance . . . . . . . . . . 42		4.5. Entropy Label Support and Performance . . . . . . . . . . 42
	4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 42		4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 43
	4.7. OAM Capabilities and Performance . . . . . . . . . . . . 43		4.7. OAM Capabilities and Performance . . . . . . . . . . . . 43
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 44		7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	8.1. Normative References . . . . . . . . . . . . . . . . . . 45		8.1. Normative References . . . . . . . . . . . . . . . . . . 45
	8.2. Informative References . . . . . . . . . . . . . . . . . 46		8.2. Informative References . . . . . . . . . . . . . . . . . 46
	Appendix A. Organization of References Section . . . . . . . . . 51		Appendix A. Organization of References Section . . . . . . . . . 51
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
	1. Introduction and Document Scope		1. Introduction and Document Scope
	The initial purpose of this document was to address concerns raised		The initial purpose of this document was to address concerns raised
	on the MPLS WG mailing list about shortcomings in implementations of		on the MPLS WG mailing list about shortcomings in implementations of
	MPLS forwarding. Documenting existing misconceptions and potential		MPLS forwarding. Documenting existing misconceptions and potential
	skipping to change at page 12, line 7		skipping to change at page 12, line 7
	general purpose CPU or other highly programmable hardware. For		general purpose CPU or other highly programmable hardware. For
	example, ELI will only be sent to LSR which have signaled support for		example, ELI will only be sent to LSR which have signaled support for
	[RFC6790] and high OAM packet rate must be negotiated among		[RFC6790] and high OAM packet rate must be negotiated among
	endpoints.		endpoints.
	[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not		[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not
	work with multipath and its use is strongly discouraged.		work with multipath and its use is strongly discouraged.
	The current list of special purpose labels can be found on the		The current list of special purpose labels can be found on the
	"Multiprotocol Label Switching Architecture (MPLS) Label Values"		"Multiprotocol Label Switching Architecture (MPLS) Label Values"
	registry reachable at IANA's pages at [1].		registry reachable at IANA's pages at http://www.iana.org.
	[I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended		[I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended
	Special Purpose MPLS Label Values" registry and makes use of the		Special Purpose MPLS Label Values" registry and makes use of the
	"extension" label, label 15, to indicate that the next label is an		"extension" label, label 15, to indicate that the next label is an
	extended special purpose label and requires special handling. The		extended special purpose label and requires special handling. The
	range of only 16 values for special purpose labels allows a table to		range of only 16 values for special purpose labels allows a table to
	be used. The range of extended special purpose labels with 20 bits		be used. The range of extended special purpose labels with 20 bits
	available for use may have to be handled in some other way in the		available for use may have to be handled in some other way in the
	unlikely event that in the future the range of currently reserved		unlikely event that in the future the range of currently reserved
	values 256-1048575 are used. If only the standards action range,		values 256-1048575 are used. If only the standards action range,
	skipping to change at page 16, line 35		skipping to change at page 16, line 35
	The pseudowire encapsulation is out of scope for this document.		The pseudowire encapsulation is out of scope for this document.
	Pseudowire impact on MPLS forwarding at midpoint LSR is within scope.		Pseudowire impact on MPLS forwarding at midpoint LSR is within scope.
	The impact on ingress MPLS push and egress MPLS UHP pop are within		The impact on ingress MPLS push and egress MPLS UHP pop are within
	scope. While pseudowire encapsulation is out of scope, some advice		scope. While pseudowire encapsulation is out of scope, some advice
	is given on sequence number support.		is given on sequence number support.
	2.1.8.1. Pseudowire Sequence Number		2.1.8.1. Pseudowire Sequence Number
	Pseudowire (PW) sequence number support is most important for PW		Pseudowire (PW) sequence number support is most important for PW
	payload types with a high expectation of in-order delivery.		payload types with a high expectation of lossless and/or in-order
	Resequencing support, rather than dropping at egress on out of order		delivery. Identifying lost PW packets and exact amount of lost
	arrival, is most important for PW payload types with a high		payload is critical for PW services which maintain bit timing, such
	expectation of lossless delivery. For example, TDM payloads require		as Time Division Multiplexing (TDM) services since these services
	sequence number support and require resequencing support. The same		MUST compensate lost payload on a bit-for-bit basis.
	is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxed
	requirements, but generally require ATM Early Packet Discard (EPD) or		With PW services which maintain bit timing, packets that have been
	ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence		received out of order also MUST be identified and may be either re-
	number support and resequencing support are beneficial to PW packet		ordered or dropped. Reordering requires, in addition to sequence
	oriented payloads such as FR and Ethernet, they are highly desirable		numbering, a "reorder buffer" in the egress PE, and ability to
	but not as strongly required.		reorder is limited by the depth of this buffer. The down side of
			maintaining a large reorder buffer is added end-to-end service delay.
			For PW services which maintain bit timing or any other service where
			jitter must be bounded, a jitter buffer is always necessary. The
			jitter buffer is needed regardless of whether reordering is done. In
			order to be effective, a reorder buffer must often be larger than a
			jitter buffer needs to be creating a tradeoff between reducing loss
			and minimizing delay.
			PW services which are not timing critical bit streams in nature are
			cell oriented or frame oriented. Though resequencing support may be
			beneficial to PW cell and frame oriented payloads such as ATM, FR and
			Ethernet, this support is desirable but not required. Requirements
			to hamdle out of order packets at all vary among services and
			deployments. For example for Ethernet PW, occasional (very rare)
			reordering is usually acceptable. If the Ethernet PW is carrying
			MPLS-TP, then this reordering may be acceptable.
			Reducing jitter is best done by an end-system, given that the
			tradeoff of loss vs delay varies among services. For example with
			interactive real time services low delay is preferred, while with
			non-interactive (one way) real time services low loss is preferred.
			The same end-site may be receiving both types of traffic. Regardless
			of this, bounded jitter is sometimes a requiremnet for specific
			deployments.
	Packet reorder should be rare except in a small number of		Packet reorder should be rare except in a small number of
	circumstances, most of which are due to network design or equipment		circumstances, most of which are due to network design or equipment
	design errors:		design errors:
	1. The most common case is where reordering occurs is rare,		1. The most common case is where reordering occurs is rare,
	occurring only when a network or equipment fault forces traffic		occurring only when a network or equipment fault forces traffic
	on a new path with different delay. The packet loss that		on a new path with different delay. The packet loss that
	accompanies a network or equipment fault is generally more		accompanies a network or equipment fault is generally more
	disruptive than any reordering which may occur.		disruptive than any reordering which may occur.
	skipping to change at page 17, line 30		skipping to change at page 18, line 5
	4. Another avoidable case is where some core equipment has multipath		4. Another avoidable case is where some core equipment has multipath
	and for some reason insists on periodically installing a new		and for some reason insists on periodically installing a new
	random number as the multipath hash seed. If supporting MPLS-TP,		random number as the multipath hash seed. If supporting MPLS-TP,
	equipment MUST provide a means to disable periodic hash reseeding		equipment MUST provide a means to disable periodic hash reseeding
	and deployments MUST disable periodic hash reseeding. Even if		and deployments MUST disable periodic hash reseeding. Even if
	not supporting MPLS-TP, equipment should provide a means to		not supporting MPLS-TP, equipment should provide a means to
	disable periodic hash reseeding and deployments should disable		disable periodic hash reseeding and deployments should disable
	periodic hash reseeding.		periodic hash reseeding.
			In provider networks which use multipath techniques and which may
			occassionally rebalance traffic or which may change PW paths
			occasionally for other reasons, reordering may be far more common
			than loss. Where reordering is more common than loss, resequencing
			packets is beneficial, rather than dropping packets at egress when
			out of order arrival occus. Resequencing is most important for PW
			payload types with a high expectation of lossless delivery since in
			such cases out of order delivery within the network results in PW
			loss.
	2.1.9. Layer-2 and Layer-3 VPN		2.1.9. Layer-2 and Layer-3 VPN
	Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label		Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label
	entry to the MPLS label stack. VPN encapsulations are out of scope		entry to the MPLS label stack. VPN encapsulations are out of scope
	for this document. Its impact on forwarding at midpoint LSR are		for this document. Its impact on forwarding at midpoint LSR are
	within scope.		within scope.
	Any of these services may be used on an MPLS entropy label enabled		Any of these services may be used on an MPLS entropy label enabled
	ingress and egress (see Section 2.4.4 for discussion of entropy		ingress and egress (see Section 2.4.4 for discussion of entropy
	label) which would add an additional two labels to the MPLS label		label) which would add an additional two labels to the MPLS label
	skipping to change at page 44, line 24		skipping to change at page 44, line 50
	also provided a number of clarifications to the questions and tests		also provided a number of clarifications to the questions and tests
	in Section 3 and Section 4.		in Section 3 and Section 4.
	Gregory Mirsky and Thomas Beckhaus provided useful comments during		Gregory Mirsky and Thomas Beckhaus provided useful comments during
	the MPLS RT review.		the MPLS RT review.
	Tal Mizrahi provided comments that prompted clarifications regarding		Tal Mizrahi provided comments that prompted clarifications regarding
	timestamp processing, local delivery of packets, and the need for		timestamp processing, local delivery of packets, and the need for
	hardware assistance in processing OAM traffic.		hardware assistance in processing OAM traffic.
			Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1
			and suggested new text which after lengthy discussion resulted in
			restating the sumarization of requirements from PWE3 RFCs and more
			clearly stating the benefits and drawbacks of packet resequencing
			based on PW sequence number.
	6. IANA Considerations		6. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	7. Security Considerations		7. Security Considerations
	This document reviews forwarding behavior specified elsewhere and		This document reviews forwarding behavior specified elsewhere and
	points out compliance and performance requirements. As such it		points out compliance and performance requirements. As such it
	introduces no new security requirements or concerns.		introduces no new security requirements or concerns.
	skipping to change at page 46, line 17		skipping to change at page 46, line 42
	RFC 6790, November 2012.		RFC 6790, November 2012.
	8.2. Informative References		8.2. Informative References
	[ACK-compression]		[ACK-compression]
	, , , "Observations and Dynamics of a Congestion Control		, , , "Observations and Dynamics of a Congestion Control
	Algorithm: The Effects of Two-Way Traffic", Proc. ACM		Algorithm: The Effects of Two-Way Traffic", Proc. ACM
	SIGCOMM, ACM Computer Communications Review (CCR) Vol 21,		SIGCOMM, ACM Computer Communications Review (CCR) Vol 21,
	No 4, 1991, pp.133-147., 1991.		No 4, 1991, pp.133-147., 1991.
	[ATM-EPD-and-PPD]
	, "Dynamics of TCP Traffic over ATM Networks", IEEE
	Journal of Special Areas of Communication Vol 13 No 4, May
	1995, pp. 633-641., May 1995.
	[I-D.ietf-mpls-special-purpose-labels]		[I-D.ietf-mpls-special-purpose-labels]
	Kompella, K., Andersson, L., and A. Farrel, "Allocating		Kompella, K., Andersson, L., and A. Farrel, "Allocating
	and Retiring Special Purpose MPLS Labels", draft-ietf-		and Retiring Special Purpose MPLS Labels", draft-ietf-
	mpls-special-purpose-labels-03 (work in progress), July		mpls-special-purpose-labels-03 (work in progress), July
	2013.		2013.
	[I-D.ietf-pwe3-vccv-impl-survey-results]		[I-D.ietf-pwe3-vccv-impl-survey-results]
	Malis, A., "The Pseudowire (PW) & Virtual Circuit		Malis, A., "The Pseudowire (PW) & Virtual Circuit
	Connectivity Verification (VCCV) Implementation Survey		Connectivity Verification (VCCV) Implementation Survey
	Results", draft-ietf-pwe3-vccv-impl-survey-results-03		Results", draft-ietf-pwe3-vccv-impl-survey-results-03
End of changes. 21 change blocks.
	47 lines changed or deleted		83 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/