Internet DRAFT - draft-song-ship-edge
draft-song-ship-edge
Network Working Group H. Song
Internet-Draft Futurewei Technologies
Intended status: Experimental 12 April 2023
Expires: 14 October 2023
Short Hierarchical IP Addresses for Edge Networks
draft-song-ship-edge-05
Abstract
To mitigate the IPv6 header overhead and improve the scalability and
performance in edge networks, this draft proposes to use short
hierarchical IP addresses excluding the network prefix within edge
networks. An edge network can be further organized into a
hierarchical architecture containing one or more levels of networks.
While each end node only needs to keep a short address suffix as its
identifier, the border routers for each hierarchical level are
responsible for address augmenting and pruning when a packet leaves
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
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Song Expires 14 October 2023 [Page 1]
Internet-Draft SHIP for Edge Networks April 2023
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 October 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Short Hierarchical IP Address (SHIP) in Edge Networks . . . . 4
2.1. Edge Network Hierarchy . . . . . . . . . . . . . . . . . 4
2.2. Address Fields . . . . . . . . . . . . . . . . . . . . . 5
2.3. Router Roles and Function . . . . . . . . . . . . . . . . 6
3. Deployment and Interoperability Consideration . . . . . . . . 9
3.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Using NAT for the edge network . . . . . . . . . . . . . 11
3.4. Extension Beyond IPv6 . . . . . . . . . . . . . . . . . . 12
4. Comparison with Existing IPv6 Header Compression Schemes . . 12
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Song Expires 14 October 2023 [Page 2]
Internet-Draft SHIP for Edge Networks April 2023
1. Introduction
Internet of Things (IoT) and 5G introduce to the Internet a huge
number of addressable entities (e.g., sensors, machines, vehicles,
and robots). The transition to IPv6 is inevitable. While the
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
IPv6 header is consumed by addresses.
In IoT networks, thing-to-thing communication through wireless
connections is dominant, which presents several distinct
characteristics. (1) The communication pattern is often frequent
short-message exchanges (e.g., industry robots and networked
vehicles). (2) The communication is usually energy sensitive (e.g.,
battery-powered sensors). (3) The communication often requires low
latency (e.g., industry control). (4) The precious wireless channels
demand high bandwidth utilization (e.g., ZigBee, Bluetooth, Wi-Fi,
and 5G). These characteristics render a large header overhead
unfavorable and even prohibitive.
The address overhead also takes its toll on Data Center Networks
(DCN), especially when large scale containers are deployed, the east-
west traffic is dominant, and the prevailing communications are
comprised of short messages (e.g., key-value pairs) and conducted
through virtual switches.
In IoT and DCN, since most communications happen between adjacent and
related entities, it is a good practice to locally confine
communication, computing, and storage due to performance, efficiency,
and security considerations, as advocated by Edge Computing. Such a
communication pattern provides an opportunity to mitigate the IPv6
header overhead problem due to the long addresses.
When an IPv6 address block is allocated to an edge network, all the
entities in the edge network share the same address prefix. When
these entities communicate with each other, they can ignore the
common prefix. In fact, they don not even need to know the common
prefix. Only when they need to communicate with entities outside of
the edge network, the full addresses are needed. Even in this case,
the entities in the edge network still do not need to know the
prefix. It is sufficient for the gateway routers at the network
border to manipulate the addresses (i.e., augmenting or pruning the
address) to meet the addressing requirement.
Song Expires 14 October 2023 [Page 3]
Internet-Draft SHIP for Edge Networks April 2023
Following this line of thought, an edge network can be further
partitioned into multiple hierarchical levels, which support flexible
sub-networking. The result is that an end entity needs to maintain
an even shorter address as its identifier. For communication
crossing network levels, the address manipulation is done at each
gateway router on the path recursively.
2. Short Hierarchical IP Address (SHIP) in Edge Networks
2.1. Edge Network Hierarchy
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
IPv6 address block (i.e., a prefix). In this sense, a data center
network in cloud can also be considered as an edge network. An edge
network usually falls under a single network administration domain.
The address block assigned to an edge network is identified by a
prefix P with the length of L < 128 bits. The remaining S = 128-L
bits can be used to assign addresses to the entities in this network.
A key observation is: the entities in this network do not need to be
aware of P's length and value at all. We can further partition the
edge network into multiple hierarchical levels, making a tree
architecture. The root represents the entire edge network. Each
other node represents a lower level network occupying a sub address
space owned by its parent node. A leaf node represents a lowest
level network. We name the root level network the L_0 network. Its
children are all L_1 networks, and so on so forth. In other words,
the network level is the depth of the corresponding node in the tree.
The network hierarchy partitions the S-bit address into multiple
sections. Assume an entity is in an L_n network. The S-bit address
is partitioned into n+1 sections. The entity only needs to keep the
last section of the S-bit address as its ID. The gateway routers for
each level of network maintain one section of the S-bit address.
Specifically, the gateway routers of L_i (i>0) keep the i-th section
of the S-bit address, and the gateway routers of L_0 keep the
assigned IPv6 address block prefix P.
Figure 1 shows an edge network example, in which are three network
levels. The edge network A is assigned a 96-bit IPv6 address prefix
(2001:0db8:ac10:fe01::0001), which means it owns a 32-bit address
space. In this space, two L_1 networks are created: B with a 16-bit
prefix (0xaaaa) and C with a 24-bit prefix (0xcccccc). Note that the
prefixes at the same level must not overlap in order to guarantee
entities in the edge network are uniquely addressable. Network B
contains two entities x and y, and Network C contains one entity z.
In network B, an L_2 network C is further created with a 8-bit prefix
Song Expires 14 October 2023 [Page 4]
Internet-Draft SHIP for Edge Networks April 2023
(0xbb). In this example, an entity in C or D (e.g., m and z) only
need to own a 8-bit address, an entity in B but not in D (e.g., x and
y) needs to own a 16-bit address, and an entity in A but not in B and
C needs to own a 32-bit address. In this way, each entity in A still
logically owns a unique IPv6 address (e.g., the IPv6 address of the
entity m in D with ID of 5 is 2001:0db8:ac10:fe01::0001:aaaa:bb05),
although the entity m is only aware of its local ID (0x05).
+------+
| L0:A | 2001:0db8:ac10:fe01::0001/96
+-+--+-+
| |
+------+ +-------+
| |
+---+--+ +--+---+
(x,y) | L1:B | aaaa/16 | L1:C | cccccc/24
+---+--+ +------+
| (z)
+---+--+
(m) | L2:D | bb/8
+------+
Figure 1: A Hierarchical Edge Network Example
2.2. Address Fields
The edge networks adopting the short and variable size address scheme
need a new type of IP header, which is referred as IPvn in this
draft. Apart from the IP version, the major difference between IPvn
and IPv6 headers is the address fields. IPvn replaces IPv6's 128-bit
source address field and 128-bit destination address field with the
four fields shown in Figure 2.
+------------+------------+
| SAL | DAL |
+------------+------------+
| SA (variable length) |
+-------------------------+
| DA (variable length) |
+-------------------------+
Figure 2: IPvn Address Fields
The Source Address Length (SAL) and the Destination Address Length
(DAL) fields have fixed length, while the Source Address (SA) and the
Destination Address (DA) fields are of variable length. To simplify
Song Expires 14 October 2023 [Page 5]
Internet-Draft SHIP for Edge Networks April 2023
the implementation, SA and DA are preferred to be byte-aligned. It
is possible to define the length of address in the unit of byte,
nibble, or bit. Each has its own pros and cons. The unit of byte
can help reduce the size of the SAL/DAL but results in coarse network
granularity which might be inefficient in address allocation. For
example, a 3-bit SAL/DAL is enough to encode 8 possible address
lengths (one to eight bytes) for networks. In this design, each
higher level network's address space expands 256 times. On the other
extreme, the unit of bit allows fine network granularity but requires
more space for SAL/DAL. For example, 6-bit SAL and DAL can support
an address length up to 64 bits (8 bytes) and each higher level
network is only twice larger.
With a few bits, it is also possible to design a more sophisticated
encoding scheme that supports variable address length steps and
adapts to the ideal network sizes at different levels.
Assuming SA and DA are 2 bytes each, and SAL and DAL are 4 bits each,
the address fields are only 5 bytes in total. Comparing to IPv6, the
size of the address fields is reduced by 84%.
2.3. Router Roles and Function
In the edge network hierarchy, each network has one or more Level
Gateway Routers (LGR) which are responsible for forwarding packets in
or out of this network. The LGRs are the only interface between a
network and its parent network.
A network can be in a single L2 domain, which means all the entities
in this network (excluding those in its child networks) and all the
network devices (including the LGRs to the parent network and the
child networks) are L2 reachable. A network can also be a pure L3
network in which no L2 device is allowed. Each entity in a network
is directly connected to either an LGR or some internal routers named
Intra-Level Router (ILR) which is solely responsible for packet
forwarding within the network. In this case, the entities need to
partially participate in the routing process (e.g., advertising its
address).
The scale of an intra-level network can be used to guide the L2/L3
selection. Small networks prefer the L2-based solution and large
networks prefer the L3-based solution. In the higher level networks
(e.g., closer to the top level network or the tree root), since the
number of entities is usually small, it is free to choose between L2
or L3-based solution. The leaf level networks are usually L2-based
for simplicity.
Song Expires 14 October 2023 [Page 6]
Internet-Draft SHIP for Edge Networks April 2023
Unlike in IPv4 and IPv6 networks, the address related fields in IPvn
header can be modified by LGRs. An LGR of a network keeps a prefix
that can augment the SAs from this network to an address outside of
this network. If an LGR needs to forward an internal packet outside
(i.e., DAL > SAL), it augments the packet's SA and updates its SAL
accordingly. Reversely, if an LGR receives a packet from the parent
network destined for the child network for which it serves as a
gateway (i.e., the parent network prefix matches the DA's prefix), it
strips off the parent network prefix from the packet's DA and updates
its DAL accordingly.
In contrast, within an L3-based level network, ILRs do not modify the
address fields. An ILR can decide the packet forwarding direction by
examining the DAL. If DAL > SAL, the packet needs to be forwarded to
an LGR of this network; otherwise, the packet needs to be forwarded
within the current network, and possibly into a lower-level child
network.
An LGR of the top-level network (i.e., the L0 network) is special.
In addition to the address manipulation, it is also responsible for
converting the IPvn header to and from the standard IPv6 header to
support the Internet interoperability. We name such a router IP
Translator (IPT).
We use the edge network shown in Figure 1 to illustrate some packet
forwarding examples. The details for the involved entities are
summarized in Figure 3. In the IPvn packet header, we use 4 bits to
encode the address length. In particular, 0b0000 is used to indicate
the address is 16 bytes long (i.e., a complete IPv6 address).
+------+------+------+-----+-------+------------+
|Entity| ID |Length|Level|Network| Prefix |
+------+------+------+-----+-------+------------+
| x |0x0001| | | | |
+------+------|2bytes| 1 | B |0xaaaa/16 |
| y |0x0002| | | | |
+------+------+------+-----+-------+------------+
| z |0x01 |1byte | 1 | C |0xcccccc/24 |
+------+------+------+-----+-------+------------+
| m |0x08 |1byte | 2 | D |0xbb/8 |
+------+------+------+-----+-------+------------+
Figure 3: Entity Address Configuration
The first example in Figure 4 shows how packets are forwarded from x
to y within the same network B. In this case, the source address and
destination address have the same length. The packets only pass
through an ILR which does not change the address fields.
Song Expires 14 October 2023 [Page 7]
Internet-Draft SHIP for Edge Networks April 2023
+-----------------+ +-----------------+ +-----------------+
| IPvn Header | | IPvn Header | | IPvn Header |
+--------+--------+ +--------+--------+ +--------+--------+
|SAL:0x2 |DAL:0x2 | |SAL:0x2 |DAL:0x2 | |SAL:0x2 |DAL:0x2 |
+--------+--------+ +--------+--------+ +--------+--------+
|SA: 0x0001 | |SA: 0x0001 | |SA: 0x0001 |
+-----------------+ +-----------------+ +-----------------+
|DA: 0x0002 | |DA: 0x0002 | |DA: 0x0002 |
+-----------------+ +-----------------+ +-----------------+
Entity x ------> ILR in B ------> Entity y
Figure 4: Forward within a network level in the edge
The second example in Figure 5 shows how packets are forwarded from x
in B to z in C. At LGR of B, the source address is augmented, and at
the LGR of C, the destination address is pruned. Since x and z's
nearest common ancestor network is A, so the packets never need to
leave network A, so A's prefix is oblivious throughout the
communication.
+---------------+ +---------------+ +---------------+ +---------------+
| IPvn Header | | IPvn Header | | IPvn Header | | IPvn Header |
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
|SAL:0x2|DAL:0x4| |SAL:0x4|DAL:0x4| |SAL:0x4|DAL:0x1| |SAL:0x4|DAL:0x1|
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
|SA: 0x0001 | |SA: 0xaaaa0001 | |SA: 0xaaaa0001 | |SA: 0xaaaa0001 |
+---------------+ +---------------+ +---------------+ +---------------+
|DA: 0xcccccc01 | |DA: 0xcccccc01 | |DA: 0x01 | |DA: 0x01 |
+---------------+ +---------------+ +---------------+ +---------------+
Entity x -----> LGR of B -----> LGR of C -----> Entity z
Figure 5: Forward to another network in the edge
The last example in Figure 6 shows how packets are forwarded from x
in B to a host in IPv6 domain. In the IPT of A, the IPvn header is
converted to an IPv6 header.
Song Expires 14 October 2023 [Page 8]
Internet-Draft SHIP for Edge Networks April 2023
+---------------+ +---------------+ +---------------+ +---------------+
| IPvn Header | | IPvn Header | | IPv6 Header | | IPv6 Header |
+-------+-------+ +-------+-------+ +---------------+ +---------------+
|SAL:0x2|DAL:0x0| |SAL:0x4|DAL:0x0| |SA: 2001:0db8 | |SA: 2001:0db8 |
+-------+-------+ +-------+-------+ | ac10:fe01: | | ac10:fe01: |
|SA: 0x0001 | |SA: 0xaaaa0001 | | 0000:0001: | | 0000:0001: |
+---------------+ +---------------+ | aaaa:0001 | | aaaa:0001 |
|DA: 2001:0db8: | |DA: 2001:0db8: | +---------------+ +---------------+
| 85a3:0000: | | 85a3:0000: | |DA: 2001:0db8: | |DA: 2001:0db8: |
| 0000:8a2e: | | 0000:8a2e: | | 85a3:0000: | | 85a3:0000: |
| 0370:7334 | | 0370:7334 | | 0000:8a2e: | | 0000:8a2e: |
+---------------+ +---------------+ | 0370:7334 | | 0370:7334 |
+---------------+ +---------------+
Entity x -----> LGR of B -----> IPT of A -----> Entity n
Figure 6: Forward out of the edge network
3. Deployment and Interoperability Consideration
3.1. Control Plane
Within the edge networks where IPvn is applied, all the control plane
functions and protocols need to be modified or redesigned due to the
hierarchical network architecture of IPvn. Fortunately, the updates
are often incremental and the results are usually simpler than their
counterparts in IPv4 and IPv6. We briefly discuss a few essential
protocols that enable the operation of IPvn.
DHCP: An entity can be manually configured or dynamically acquire
its address when booting up. Each network in the edge network
hierarchy may contain a Dynamic Host Configuration Protocol (DHCP)
server responsible for assigning addresses (i.e., IDs) to the
entities in the same network. The protocol is almost identical to
that for IPv4 and IPv6, except that the assigned address length is
adaptive to the allocated network size.
DNS: For an entity to acquire the address of a peer entity in order
to initiate a communication, Domain Name System (DNS) is the
prominent approach but with a new service model. Any network in
the hierarchy can provide name service. Each entity is configured
with the address of the closest DNS server on the path to the root
network. The hierarchical network architecture allows a scoped
domain name service. That is, a name registered in a network is
only valid in this network and its child networks. It is possible
that a same name is registered in two networks and one network is
the other's ancestor. Such name conflict is not a bug but a
Song Expires 14 October 2023 [Page 9]
Internet-Draft SHIP for Edge Networks April 2023
feature for name reuse, which is transparent to the name query
process. In this case, the name resolved from the closer DNS
server is used.
Each network may contain a DNS server (the notation is only
logical. The actual implementation may follow the same
hierarchical and distributed architecture of today's DNS). Each
DNS server knows the nearest DNS server in a higher level network
and the nearest DNS servers in lower level networks. This
essentially organizes the DNS servers in the same tree structure
as the hierarchical network. Each named entity in a network is
registered with the DNS server that covers its scope, which is
basically a subtree.
We have several methods to populate the name to support the scoped
name queries, each with different storage and performance trade-
off: 1) register the name in all the DNS servers in its scope
(i.e., all the subtree nodes); 2) recursively register the name in
every parent DNS server until the scope root; and 3) register the
name only in the DNS server in its scope root. The address for a
name returned by a DNS server is on a "need-to-know" basis. In a
network, if the address's prefix matches the query's address
prefix, the prefix is removed. This can be easily done by the
original or the relay DNS servers. If a query cannot be resolved
by the DNS server in the L0 network, the query, after the IP
protocol translation is done, exits the IPvn domain and enters
into the IPv4/IPv6 domain to a public DNS server. When the
response comes back and enters the edge network, the result can be
cached by the DNS servers on the path.
ARP: In a L2-based network, the operation of Address Resolution
Protocol (ARP) or Neighbor Discovery Protocol (NDP) is almost
identical to that for IPv4 and IPv6. In an L2- based network,
each immediate entity should be configured with a default gateway
address to its parent network. If no default gateway is
configured, a network LGR should be configured as an ARP proxy to
respond to all internal ARP requests for addresses out of the
network. Similarly, the LGRs to any child network of this network
are also needed to be configured as ARP proxy to response all ARP
requests for addresses in that network. Due to the multi-homing
gateway routers, an ARP request may receive multiple responses.
It is up to the requester to determine which one to cache.
Routing Protocol: The entire edge network may belong to a single AS,
so the interior gateway routing protocols (IGP) such as OSPF and
IS-IS can be used. Other child networks in this network can be
considered OSPF stub areas or IS-IS levels. A simpler way is that
each network run an independent instance of OSPF or IS-IS.
Song Expires 14 October 2023 [Page 10]
Internet-Draft SHIP for Edge Networks April 2023
Specially, an LGR at a network border runs two OSPF/IS-IS
instances: one for the upper-level network and the other for the
lower-level network. The hierarchical architecture solves the
routing protocol scalability issue, and simplifies the protocol
implementation by removing unnecessary features. The clean
routing scope helps to secure the infrastructure and troubleshoot
the networks.
3.2. Data Plane
IPvn Socket for End Entities: To enable IPvn as a new network layer
protocol in end entities, we need to add the protocol
implementation in the OS Kernel and allow applications to invoke
the socket API using the address family parameter AF_INETN. The
L4-L7 protocol stack and the application logic remains the same,
allowing direct communication between entities in IPvn domain and
in IPv4/IPv6 domain.
Forwarding Table Lookups in Networks: The short hierarchical address
simplifies the router forwarding table structure in L3-based
networks. A forwarding table only contains the addresses to local
entities and the prefixes to the child networks. Since there is
no nested prefixes, the Longest Prefix Matching (LPM) is not
necessary. The small number of unique prefix lengths allows the
prefixes to be grouped on lengths and each group to be implemented
as a hash table. A lookup can search all the hash tables in
parallel, and at most one table can result a positive match. This
design avoids the use of expensive TCAM or other complex trie-
based algorithms.
An LGR between an L_i network and an L_(i+1) network has two types
of interfaces: one faces the L_i network and the other faces the
L_(i+1) network. One LGR may serve more than one L_(i+1) network.
Hence, an LGR may contain multiple logical forwarding tables, with
each for a network. For a packet in LGR, once its target network
is determined and the address related fields are processed, the
proper forwarding table can be searched.
3.3. Using NAT for the edge network
To expand the address space of the edge network, the IPT of the edge
network can also support functions similar to NAT. In this case, the
edge network is assigned one or more public IPv4/IPv6 addresses. The
entities in IPvn domain use private addresses. The IPT maintains the
mapping table between the private address and public address.
Song Expires 14 October 2023 [Page 11]
Internet-Draft SHIP for Edge Networks April 2023
3.4. Extension Beyond IPv6
Although the motivation of this draft is to support shorter address
(i.e., smaller L3 header overhead) in edge networks, it is worth
noting that the scheme allows the addresses to be extend to arbitrary
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
network can be considered an edge network of the IPvn network. This
scenario should be considered when specifying the address fields of
IPvn.
4. Comparison with Existing IPv6 Header Compression Schemes
IPv6 header compression schemes have been specified for some
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.
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.
Song Expires 14 October 2023 [Page 12]
Internet-Draft SHIP for Edge Networks April 2023
* LEO satellite constellations and communication also require high
bandwidth efficiency and low latency.
6. Security Considerations
The SHIP addressing scheme and architecture allow a securer edge
network. The IPTs and LGRs naturally support the access control.
7. IANA Considerations
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.
8. Acknowledgments
We acknowledge the technical contributions, suggestions and comments
from Yingzhe Qu, Zhaobo Zhang, James Guichard, Toerless Eckert,
Stewart Bryant, Michael McBride, Adnan Rashid, Alexander Pelov,
Michael Richardson, Pascal Thubert, Uma Chunduri, Kerry Lynn, and
many others.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<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>.
Song Expires 14 October 2023 [Page 13]
Internet-Draft SHIP for Edge Networks April 2023
Author's Address
Haoyu Song
Futurewei Technologies
Santa Clara,
United States of America
Email: haoyu.song@futurewei.com
Song Expires 14 October 2023 [Page 14]
