< draft-song-mpls-extension-header-02.txt		draft-song-mpls-extension-header-03.txt >
	MPLS H. Song, Ed.		MPLS H. Song, Ed.
	Internet-Draft Z. Li		Internet-Draft Futurewei Technologies
	Intended status: Standards Track T. Zhou		Intended status: Standards Track Z. Li
	Expires: August 9, 2019 Huawei		Expires: September 11, 2021 T. Zhou
			Huawei
	L. Andersson		L. Andersson
	Bronze Dragon Consulting		Bronze Dragon Consulting
	February 5, 2019		March 10, 2021
	MPLS Extension Header		MPLS Extension Header
	draft-song-mpls-extension-header-02		draft-song-mpls-extension-header-03
	Abstract		Abstract
	Motivated by the need to support multiple in-network services and		Motivated by the need to support multiple in-network services and
	functions in an MPLS network, this document describes a method to		functions in an MPLS network, this document describes a generic and
	encapsulate extension headers into MPLS packets. The encapsulation		extensible method to encapsulate extension headers into MPLS packets.
	method allows stacking multiple extension headers and quickly		The encapsulation method allows stacking multiple extension headers
	accessing any of them as well as the original upper layer protocol		and quickly accessing any of them as well as the original upper layer
	header and payload. We show how the extension header can be used to		protocol header and payload. We show how the extension header can be
	support several new network applications and optimize some existing		used to support several new network applications and optimize some
	network services.		existing network services.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 49 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 August 9, 2019.		This Internet-Draft will expire on September 11, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 40 ¶		skipping to change at page 2, line 40 ¶
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Motivation		1. Motivation
	Some applications require adding instructions and/or metadata to user		Some applications require adding instructions and/or metadata to user
	packets within a network. Such examples include In-situ OAM (IOAM)		packets within a network. Such examples include In-situ OAM (IOAM)
	[I-D.brockners-inband-oam-requirements] and Service Function Chaining		[I-D.ietf-ippm-ioam-data] and Service Function Chaining (SFC)
	(SFC) [RFC7665]. New applications are emerging. It is possible that		[RFC7665]. New applications are emerging. It is possible that the
	the instructions and/or metadata for multiple applications are		instructions and/or metadata for multiple applications are stacked
	stacked together in one packet to support a compound service.		together in one packet to support a compound service.
	Conceivably, such instructions and/or metadata would be encoded as		Conceivably, such instructions and/or metadata would be encoded as
	new headers and encapsulated in user packets. Such headers may		new headers and encapsulated in user packets. Such headers may
	require to be processed in fast path or in slow path. Moreover, such		require to be processed in fast path or in slow path. Moreover, such
	headers may require being attended at each hop on the forwarding path		headers may require being attended at each hop on the forwarding path
	(i.e., hop-by-hop or HBH) or at designated end nodes (i.e., end-to-		(i.e., hop-by-hop or HBH) or at designated end nodes (i.e., end-to-
	end or E2E).		end or E2E).
	The encapsulation of the new header(s) poses some challenges to MPLS		The encapsulation of the new header(s) poses some challenges to MPLS
	networks, because the MPLS protocol header contains no explicit		networks, because the MPLS protocol header contains no explicit
	indicator for the upper layer protocols by design. We leave the		indicator for the upper layer protocols by design. We leave the
	discussion on the indicator of new header(s) in an MPLS packet to		discussion on the indicator of new header(s) in an MPLS packet to
	another companion document. In this document, we focus on the encode		another companion document [I-D.song-mpls-eh-indicator]. In this
	and encapsulation of new headers in an MPLS packet.		document, we focus on the encode and encapsulation of new headers in
			an MPLS packet.
	The similar problem has been tackled for some particular application		The similar problem has been tackled for some particular application
	before. However, the solutions have some drawbacks:		before. However, the solutions have some drawbacks:
	o These solutions rely on either the built-in next-protocol		o These solutions rely on either the built-in next-protocol
	indicator in the header or the knowledge of the format and size of		indicator in the header or the knowledge of the format and size of
	the header to access the following packet data. The node is		the header to access the following packet data. The node is
	required to be able to parse the new header, which is unrealistic		required to be able to parse the new header, which is unrealistic
	in an incremental deployment environment.		in an incremental deployment environment.
	o A piecemeal solution often assumes the new header is the only		o A piecemeal solution often assumes the new header is the only
	extra header and its location in the packet is fixed by default.		extra header and its location in the packet is fixed by default.
	It is impossible or difficult to support multiple new headers in		It is impossible or difficult to support multiple new headers in
	one packet due to the conflicted assumption.		one packet due to the conflicted assumption.
	To solve these issues, we propose to introduce extension header as a		To solve these issues, we propose to introduce extension header as a
	general and extensible means to support new in-network functions and		general and extensible means to support new in-network functions and
	applications in MPLS networks. The idea is similar to IPv6 extension		applications in MPLS networks. The idea is similar to IPv6 extension
	headers which offer a huge innovation potential (e.g, network		headers which offer a huge innovation potential (e.g, network
	security, SRv6 [I-D.ietf-spring-segment-routing], network programming		security, SRv6 [RFC8754], network programming
	[I-D.filsfils-spring-srv6-network-programming], SFC		[I-D.ietf-spring-srv6-network-programming], SFC
	[I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the		[I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the
	existing of extension headers, it is straightforward to introduce new		existing of extension headers, it is straightforward to introduce new
	in-network services into IPv6 networks. For example, it has been		in-network services into IPv6 networks. For example, it has been
	proposed to carry IOAM header [I-D.brockners-inband-oam-transport] as		proposed to carry IOAM header [I-D.brockners-inband-oam-transport] as
	a new extension header in IPv6 networks.		a new extension header in IPv6 networks.
	Nevertheless, IPv6 is not perfect either. It has two main issues.		Nevertheless, IPv6 is not perfect either. It has two main issues.
	First, IPv6's header is large compared to MPLS, claiming extra		First, IPv6's header is large compared to MPLS, claiming extra
	bandwidth overhead and complicating the packet processing. We prefer		bandwidth overhead and complicating the packet processing. We prefer
	to retain the header compactness in MPLS networks. Second, IPv6's		to retain the header compactness in MPLS networks. Second, IPv6's
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 6 ¶
	headers but not the others in an extension header stack, it can		headers but not the others in an extension header stack, it can
	process the known headers only while ignoring the others.		process the known headers only while ignoring the others.
	We assume the MPLS label stack has included some indicator of the		We assume the MPLS label stack has included some indicator of the
	extension header(s). The actual extension headers are inserted		extension header(s). The actual extension headers are inserted
	between the MPLS label stack and the original upper layer packet		between the MPLS label stack and the original upper layer packet
	header. The format of the MPLS packets with extension headers is		header. The format of the MPLS packets with extension headers is
	shown in Figure 1.		shown in Figure 1.
	0 31		0 31
	+--------+--------+--------+--------+ -		+--------+--------+--------+--------+ \
	| | |		| | |
	~ MPLS Label Stack ~ |		~ MPLS Label Stack ~ |
	| | |		| | |
	+--------+--------+--------+--------+ |		+--------+--------+--------+--------+ |
	| EH Indicator (TBD) | > MPLS Label Stack		| EH Indicator (TBD) | > MPLS Label Stack
	+--------+--------+--------+--------+ | (extended with EHI)		+--------+--------+--------+--------+ | (extended with EHI)
	| | |		| | |
	~ MPLS Label Stack ~ |		~ MPLS Label Stack ~ |
	| | |		| | |
	+--------+--------+--------+--------+ =		+--------+--------+--------+--------+ <
	| Header of Extension Headers (HEH) | |		| Header of Extension Headers (HEH) | |
	+--------+--------+--------+--------+ |		+--------+--------+--------+--------+ |
	| | |		| | |
	~ Extension Header (EH) 1 ~ |		~ Extension Header (EH) 1 ~ |
	| | |		| | |
	+--------+--------+--------+--------+ > MPLS EH Fields		+--------+--------+--------+--------+ > MPLS EH Fields
	~ ~ | (new)		~ ~ | (new)
	+--------+--------+--------+--------+ |		+--------+--------+--------+--------+ |
	| | |		| | |
	~ Extension Header (EH) N ~ |		~ Extension Header (EH) N ~ |
	| | |		| | |
	+--------+--------+--------+--------+ =		+--------+--------+--------+--------+ <
	| | |		| | |
	~ Upper Layer Headers/Payload ~ > MPLS Payload		~ Upper Layer Headers/Payload ~ > MPLS Payload
	| | | (as is)		| | | (as is)
	+--------+--------+--------+--------+ -		+--------+--------+--------+--------+ /
	Figure 1: MPLS with Extension Headers		Figure 1: MPLS with Extension Headers
	Following the MPLS label stack is the 4-octet Header of Extension		Following the MPLS label stack is the 4-octet Header of Extension
	Headers (HEH), which indicates the total number of extension headers		Headers (HEH), which indicates the total number of extension headers
	in this packet, the overall length of the extension headers, and the		in this packet, the overall length of the extension headers, and the
	type of the next header. The format of the HEH is shown in Figure 2.		type of the next header. The format of the HEH is shown in Figure 2.
	0 1 2 3		0 1 2 3
	0123 45678901 234567890123 45678901		0123 45678901 234567890123 45678901
	skipping to change at page 9, line 48 ¶		skipping to change at page 9, line 48 ¶
	10. References		10. References
	10.1. Normative References		10.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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	"MPLS Generic Associated Channel", RFC 5586,
	DOI 10.17487/RFC5586, June 2009,
	<https://www.rfc-editor.org/info/rfc5586>.
	[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function		[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
	Chaining (SFC) Architecture", RFC 7665,		Chaining (SFC) Architecture", RFC 7665,
	DOI 10.17487/RFC7665, October 2015,		DOI 10.17487/RFC7665, October 2015,
	<https://www.rfc-editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,		[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
	L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,		L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
	"Alternate-Marking Method for Passive and Hybrid		"Alternate-Marking Method for Passive and Hybrid
	Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,		Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
	January 2018, <https://www.rfc-editor.org/info/rfc8321>.		January 2018, <https://www.rfc-editor.org/info/rfc8321>.
	10.2. Informative References		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
			Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
			(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
			<https://www.rfc-editor.org/info/rfc8754>.
	[I-D.brockners-inband-oam-requirements]		10.2. Informative References
	Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
	Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
	T., Lapukhov, P., and r. remy@barefootnetworks.com,
	"Requirements for In-situ OAM", draft-brockners-inband-
	oam-requirements-03 (work in progress), March 2017.
	[I-D.brockners-inband-oam-transport]		[I-D.brockners-inband-oam-transport]
	Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,		Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
	Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,		Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
	D., Lapukhov, P., and R. Chang, "Encapsulations for In-		D., Lapukhov, P., and R. Chang, "Encapsulations for In-
	situ OAM Data", draft-brockners-inband-oam-transport-05		situ OAM Data", draft-brockners-inband-oam-transport-05
	(work in progress), July 2017.		(work in progress), July 2017.
	[I-D.filsfils-spring-srv6-network-programming]
	Filsfils, C., Camarillo, P., Leddy, J.,
	daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
	Network Programming", draft-filsfils-spring-srv6-network-
	programming-06 (work in progress), October 2018.
	[I-D.guichard-sfc-mpls-metadata]
	Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant,
	"Carrying Metadata in MPLS Networks", draft-guichard-sfc-
	mpls-metadata-00 (work in progress), September 2013.
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,		Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
	Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,		for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in
	P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,		progress), November 2020.
	"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
	data-04 (work in progress), October 2018.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-srv6-network-programming]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,		Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
	Litkowski, S., and R. Shakir, "Segment Routing		Matsushima, S., and Z. Li, "SRv6 Network Programming",
	Architecture", draft-ietf-spring-segment-routing-15 (work		draft-ietf-spring-srv6-network-programming-28 (work in
	in progress), January 2018.		progress), December 2020.
			[I-D.song-mpls-eh-indicator]
			Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for
			MPLS Extension Header Indicator", draft-song-mpls-eh-
			indicator-00 (work in progress), February 2019.
	[I-D.xu-clad-spring-sr-service-chaining]		[I-D.xu-clad-spring-sr-service-chaining]
	Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,		Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
	d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,		d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,
	S., and S. Ma, "Segment Routing for Service Chaining",		S., and S. Ma, "Segment Routing for Service Chaining",
	draft-xu-clad-spring-sr-service-chaining-00 (work in		draft-xu-clad-spring-sr-service-chaining-00 (work in
	progress), December 2017.		progress), December 2017.
	Authors' Addresses		Authors' Addresses
	Haoyu Song (editor)		Haoyu Song (editor)
	Huawei		Futurewei Technologies
	2330 Central Expressway		2330 Central Expressway
	Santa Clara		Santa Clara
	USA		USA
	Email: haoyu.song@huawei.com		Email: haoyu.song@futurewei.com
	Zhenbin Li		Zhenbin Li
	Huawei		Huawei
	156 Beiqing Road		156 Beiqing Road
	Beijing, 100095		Beijing, 100095
	P.R. China		P.R. China
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
	Tianran Zhou		Tianran Zhou
End of changes. 21 change blocks.
	61 lines changed or deleted		48 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/