< draft-song-ship-edge-02.txt		draft-song-ship-edge-03.txt >
	Network Working Group H. Song		Network Working Group H. Song
	Internet-Draft Futurewei Technologies		Internet-Draft Futurewei Technologies
	Intended status: Experimental 11 October 2021		Intended status: Experimental 11 April 2022
	Expires: 14 April 2022		Expires: 13 October 2022
	Short Hierarchical IP Addresses at Edge Networks		Short Hierarchical IP Addresses for Edge Networks
	draft-song-ship-edge-02		draft-song-ship-edge-03
	Abstract		Abstract
	To mitigate the IPv6 header overhead in edge networks, this draft		To mitigate the IPv6 header overhead and improve the scalability and
	proposes to use short hierarchical addresses excluding the network		performance in edge networks, this draft proposes to use short
	prefix within edge networks. An edge network can be further		hierarchical IP addresses excluding the network prefix within edge
	organized into a hierarchical architecture containing one or more		networks. An edge network can be further organized into a
	levels of networks. The border routers for each hierarchical level		hierarchical architecture containing one or more levels of networks.
	are responsible for address augmenting and pruning when a packet		While each end node only needs to keep a short address suffix as its
	leaves or enter a lower level network. Specifically, the top-level		identifier, the border routers for each hierarchical level are
	border routers convert the internal IP header to and from the		responsible for address augmenting and pruning when a packet leaves
	standard IPv6 header. This draft presents an incrementally		or enter a lower level network. Specifically, the top-level border
			routers of an edge network convert the internal IP header to and from
			the standard IPv6 header. This draft presents an incrementally
	deployable scheme allowing packet header to be effectively compressed		deployable scheme allowing packet header to be effectively compressed
	in edge networks without affecting the network interoperability.		in edge networks without affecting the network interoperability.
			Simplifying both network data plane and control plane, the SHIP
			architecture is suitable for any types of edge networks, especially
			when low latency, high performance, and high bandwidth efficiency are
			required.
	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 2, line 10 ¶
	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 14 April 2022.		This Internet-Draft will expire on 13 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Short Hierarchical Address in Edge Networks . . . . . . . . . 3		2. Short Hierarchical IP Address (SHIP) in Edge Networks . . . . 4
	2.1. Edge Network Hierarchy . . . . . . . . . . . . . . . . . 3		2.1. Edge Network Hierarchy . . . . . . . . . . . . . . . . . 4
	2.2. Address Fields . . . . . . . . . . . . . . . . . . . . . 5		2.2. Address Fields . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Router Roles and Function . . . . . . . . . . . . . . . . 6		2.3. Router Roles and Function . . . . . . . . . . . . . . . . 6
	3. Deployment and Interoperability Consideration . . . . . . . . 9		3. Deployment and Interoperability Consideration . . . . . . . . 9
	3.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 9
	3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 11		3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 11
	3.3. Using NAT for the edge network . . . . . . . . . . . . . 11		3.3. Using NAT for the edge network . . . . . . . . . . . . . 11
	3.4. Extension Beyond IPv6 . . . . . . . . . . . . . . . . . . 12		3.4. Extension Beyond IPv6 . . . . . . . . . . . . . . . . . . 12
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Comparison with Existing IPv6 Header Compression Schemes . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		6. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . 12		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
			10.1. Normative References . . . . . . . . . . . . . . . . . . 13
			10.2. Informative References . . . . . . . . . . . . . . . . . 13
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Internet of Things (IoT) and 5G introduce to the Internet a huge		Internet of Things (IoT) and 5G introduce to the Internet a huge
	number of addressable entities (e.g., sensors, machines, vehicles,		number of addressable entities (e.g., sensors, machines, vehicles,
	and robots). The transition to IPv6 is inevitable. While the		and robots). The transition to IPv6 is inevitable. While the
	128-bit address of IPv6 was considered large enough and future-proof,		128-bit address of IPv6 was considered large enough and future-proof,
	the long IP addresses inflate the packet header size. 80% of a basic		the long IP addresses inflate the packet header size. 80% of a basic
	IPv6 header is consumed by addresses.		IPv6 header is consumed by addresses.
	skipping to change at page 3, line 41 ¶		skipping to change at page 4, line 12 ¶
	border to manipulate the addresses (i.e., augmenting or pruning the		border to manipulate the addresses (i.e., augmenting or pruning the
	address) to meet the addressing requirement.		address) to meet the addressing requirement.
	Following this line of thought, an edge network can be further		Following this line of thought, an edge network can be further
	partitioned into multiple hierarchical levels, which support flexible		partitioned into multiple hierarchical levels, which support flexible
	sub-networking. The result is that an end entity needs to maintain		sub-networking. The result is that an end entity needs to maintain
	an even shorter address as its identifier. For communication		an even shorter address as its identifier. For communication
	crossing network levels, the address manipulation is done at each		crossing network levels, the address manipulation is done at each
	gateway router on the path recursively.		gateway router on the path recursively.
	2. Short Hierarchical Address in Edge Networks		2. Short Hierarchical IP Address (SHIP) in Edge Networks
	2.1. Edge Network Hierarchy		2.1. Edge Network Hierarchy
	In this draft, we define an edge network as a stub network which does		In this draft, we define an edge network as a stub network which does
	not support traffic transit service. The stub network is assigned an		not support traffic transit service. The stub network is assigned an
	IPv6 address block. In this sense, a data center network in cloud		IPv6 address block. In this sense, a data center network in cloud
	can also be considered as an edge network. An edge network usually		can also be considered as an edge network. An edge network usually
	falls under a single network administration domain.		falls under a single network administration domain.
	The address block assigned to an edge network is identified by a		The address block assigned to an edge network is identified by a
	skipping to change at page 12, line 16 ¶		skipping to change at page 12, line 16 ¶
	Although the motivation of this draft is to support shorter address		Although the motivation of this draft is to support shorter address
	(i.e., smaller L3 header overhead) in edge networks, it is worth		(i.e., smaller L3 header overhead) in edge networks, it is worth
	noting that the scheme allows the addresses to be extend to arbitrary		noting that the scheme allows the addresses to be extend to arbitrary
	length, even longer than 128bits. In that case, the address space of		length, even longer than 128bits. In that case, the address space of
	the IPvn network can be greater than that of IPv6 and the entire IPv6		the IPvn network can be greater than that of IPv6 and the entire IPv6
	network can be considered an edge network of the IPvn network. This		network can be considered an edge network of the IPvn network. This
	scenario should be considered when specifying the address fields of		scenario should be considered when specifying the address fields of
	IPvn.		IPvn.
	4. Security Considerations		4. Comparison with Existing IPv6 Header Compression Schemes
	The addressing scheme and architecture allow a securer edge network.		IPv6 header compression schemes have been specified for some
	The IPTs and LGRs naturally support the access control.		particular low power IoT networks such as 6loWPAN ([RFC6282]) and
			LPWAN ([RFC8724]). These networks feature low data rate and are
			insensitive to latency, however, due to the low power constraint,
			they are extremely sensitive to bandwidth efficiency. Therefore,
			they adopt the context-based compression schemes which, while needing
			extra storage and computation, can reduce the header overhead to the
			utmost extend.
	5. IANA Considerations		In contrast, SHIP is context-less and independent to the edge network
			type. Hence, SHIP is free from the packet-based compression/
			decompression process and the context maintenance, making it suitable
			for high bandwidth and low latency communications. Also, SHIP
			provides a hierarchical network architecture which allows better
			network manageability and isolation.
			The current proposal only concerns the address part of the IPv6
			packet header. In edge networks and for particular applications, the
			context-less field eliding and reduction on the other non-essential
			IPv6 header fields are possible to further reduce the header overhead
			while maintaining the high performance.
			5. Use Cases
			Below is a list of potential use cases in addition to the DCN
			discussed in Section 1 which can appreciate the unique property of
			SHIP.
			* A subset of mIOT UEs needs low latency and high bandwidth and are
			sensitive to power consumption. For example, the V2X UEs and AR/
			VR UEs (e.g., advanced handset or 5G enabled headset) are
			constrained by battery power but demand for high bandwidth and low
			latency.
			* LEO satellite constellations and communication also require high
			bandwidth efficiency and low latency.
			6. Evaluation
			TBD
			7. Security Considerations
			The SHIP addressing scheme and architecture allow a securer edge
			network. The IPTs and LGRs naturally support the access control.
			8. IANA Considerations
	The proposal requires to use a new IP version and define a new IP		The proposal requires to use a new IP version and define a new IP
	header which can be converted to/from an equivalent IPv6 header.		header which can be converted to/from an equivalent IPv6 header.
	6. Acknowledgments		9. Acknowledgments
	We acknowledge the technical contributions, suggestions and comments		We acknowledge the technical contributions, suggestions and comments
	from Yingzhe Qu, Zhaobo Zhang, James Guichard, Toerless Eckert,		from Yingzhe Qu, Zhaobo Zhang, James Guichard, Toerless Eckert,
	Stewart Bryant, and Michael McBride.		Stewart Bryant, Michael McBride, Adnan Rashid, Alexander Pelov,
			Michael Richardson, Pascal Thubert, Uma Chunduri, Kerry Lynn, and
			many others.
	7. References		10. References
	7.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>.
	[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>.
	7.2. Informative References		10.2. Informative References
	[RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route		[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
	Preference for Extended IP and IPv6 Reachability",		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	RFC 7775, DOI 10.17487/RFC7775, February 2016,		DOI 10.17487/RFC6282, September 2011,
	<https://www.rfc-editor.org/info/rfc7775>.		<https://www.rfc-editor.org/info/rfc6282>.
			[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
			Zuniga, "SCHC: Generic Framework for Static Context Header
			Compression and Fragmentation", RFC 8724,
			DOI 10.17487/RFC8724, April 2020,
			<https://www.rfc-editor.org/info/rfc8724>.
	Author's Address		Author's Address
	Haoyu Song		Haoyu Song
	Futurewei Technologies		Futurewei Technologies
	Santa Clara,		Santa Clara,
	United States of America		United States of America
	Email: haoyu.song@futurewei.com		Email: haoyu.song@futurewei.com
End of changes. 20 change blocks.
	43 lines changed or deleted		102 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/