Internet-Draft Satellite Semantic Addressing March 2022
Han, et al. Expires 7 September 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-lhan-satellite-semantic-addressing-01
Published:
Intended Status:
Informational
Expires:
Authors:
L. Han, Ed.
Futurewei Technologies, Inc.
R. Li
Futurewei Technologies, Inc.
A. Retana
Futurewei Technologies, Inc.
M. Chen
China Mobile
N. Wang
University of Surrey

Satellite Semantic Addressing for Satellite Constellation

Abstract

This document presents a semantic addressing method for satellites in satellite constellation connecting with Internet. The satellite semantic address can indicate the relative position of satellites in a constellation. The address can be used with traditional IP address or MAC address or used independently for IP routing and switching.

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/.

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 7 September 2022.

Table of Contents

1. Introduction

Satellite constellation technologies for Internet are emerging and expected to provide Internet service like the traditional wired network on the ground. A typical satellite constellation will have couple of thousands or over ten thousand of LEO and/or VLEO. Satellites in a constellation will be connected to adjacent satellites by Inter-Satellite-Links (ISL), and/or connected to ground station by microwave or laser links. ISL is still in research stage and will be deployed soon. This memo is for the satellite networking with the use of ISL.

The memo proposes to use some indexes to represent a satellite's orbit information. The indexes can form satellite semantic address, the address can then be embedded into IPv6 address or MAC address for IP routing and switching. The address can also be used independently if the shorter than 128-bit length of IP address is accepted. As an internal address for satellite network, it only applies to satellites that will form a constellation to transport Internet traffic between ground stations and will not be populated to Internet by BGP.

2. Terminology

LEO
Low Earth Orbit with the altitude from 180 km to 2000 km.
VLEO
Very Low Earth Orbit with the altitude below 450 km
GEO
Geosynchronous orbit with the altitude 35786 km
ISL
Inter Satellite Link
ISLL
Inter Satellite Laser Link
3D
Three Dimensional
GS
Ground Station, a device on ground connecting the satellite. In the document, GS will hypothetically provide L2 and/or L3 functionality in addition to process/send/receive radio wave. It might be different as the reality that the device to process/send/receive radio wave and the device to provide L2 and/or L3 functionality could be separated.
SGS
Source ground station. For a specified flow, a ground station that will send data to a satellite through its uplink.
DGS
Destination ground station. For a specified flow, a ground station that is connected to a local network or Internet, it will receive data from a satellite through its downlink and then forward to a local network or Internet.
L1
Layer 1, or Physical Layer in OSI model [OSI-Model]
L2
Layer 2, or Data Link Layer in OSI model [OSI-Model]
L3
Layer 3, or Network Layer in OSI model [OSI-Model], it is also called IP layer in TCP/IP model
BGP
Border Gateway Protocol [RFC4271]
IGP
Interior gateway protocol, examples of IGPs include Open Shortest Path First (OSPF [RFC2328]), Routing Information Protocol (RIP [RFC2453]), Intermediate System to Intermediate System (IS-IS [RFC7142]) and Enhanced Interior Gateway Routing Protocol (EIGRP [RFC7868]).

3. Overview

For IP based satellite networking, the topology is very dynamic and the traditional IGP and BGP based routing technologies will face challenges according to the analysis in [I-D.lhan-problems-requirements-satellite-net]. From the paper, we can easily categorize satellite links as two types, steady and un-steady. For un-steady links, the link status will be flipping every couple of minutes.

Section 5.5 has more details about how to identify different links.

Some researches have been done to handle such fast changed topologies. one method to overcome the difficulties for routing with un-steady links is to only use the steady links, and get rid of un-steady links unless it is necessary. For example, for real deployment, only links between satellite and ground stations are mandatory to use, other un-steady links can be avoided in routing and switching algorithms. [Routing-for-LEO] proposed to calculate the shortest path by avoiding un-steady links in polar area and links crossing Seam line since satellites will move in the opposite direction crossing the Seam line.

Traditionally, to establish an IP network for satellites, each satellite and its interface between satellites and to ground stations have to be assigned IP addresses (IPv4 or IPv6). The IP address can be either private or public. IP address itself does not mean anything except routing prefix and interface identifier [RFC8200].

To utilize the satellite relative position for routing, it is desired that there is an easy way to identify the relative positions of different satellites and identify un-steady links quickly. The traditional IP address cannot provide such functionality unless we have the real-time processing for 3D coordinates of satellites to figure out the relative positions of each satellite, and some math calculation and dynamic database are also needed in routing algorithm to check if a link is steady or not. This will introduce extra data exchanged for routing protocols and burden for the computation in every satellite. Considering the ISL link speed (up to 10G for 2000km) and hardware cost (Radiation-hardened semiconductor components are needed) in satellite are more constraint than for network device on ground, it is expected to simplify the routing algorithm, reduce the requirement of ISL, onboard CPU and memory.

The document proposes to form a semantic address by satellite orbit information, and then embedded it into a proper IP address. The IP address of IGP neighbors can directly tell the relative position of different satellites and if links between two satellites are stead or not.

The document does not describe the details how the semantic address is used to improve routing and switching or new routing protocols, those will be addressed in different documents.

4. Basics of Satellite Constellation and Satellite Orbit

This section will introduce some basics for satellite such as orbit parameters.

4.1. Satellite Orbit

The orbit of a satellite can be either circular or ecliptic, it can be described by following Keplerian elements [KeplerianElement]:

  1. Inclination (i)
  2. Longitude of the ascending node (Omega)
  3. Eccentricity (e)
  4. Semimajor axis (a)
  5. Argument of periapsis (omega)
  6. True anomaly (nu)

The circular orbit is widely used by proposals of satellite constellation from different companies and countries.

For a circular orbit, we will have:

  • Eccentricity e = 0
  • Semimajor axis a = Altitude of satellite
  • Argument of periapsis omega = 90 degree

So, three parameters, Altitude, Inclination and Longitude of the ascending node, will be enough to describe the orbit. The satellite will move in a constant speed and True anomaly (nu) can be easily calculated after the epoch time is defined.

4.2. Satellite Constellation Compositions

One satellite constellation may be composed of many satellites (LEO and VLEO), but normally all satellites are grouped in a certain order that is never changed during the life of satellite constellation. Each satellite constellation's orbits parameters described in Section 4.1 must be approved by regulator and cannot be changed either. Follows are characters of one satellite constellation:

  1. One Satellite Constellation is composed of couple of shell groups of satellites.
  2. Same shell group of satellite will have the same altitude and inclination.
  3. The total N orbit planes in the same shell group of satellites will be evenly distributed by the same interval of Longitude of the ascending node (Omega). The interval equals to (360 degree/N). As a result, all orbit planes in the same shell group will effectively form a shell to cover earth (there will be a coverage hole for the shell if the inclination angle is less than 90 degree).
  4. Each orbit plane in the same shell group will have the same number of satellites, all satellites in the same orbit plane will be evenly distributed angularly in the orbit plane.
  5. All satellites in the same shell group are moving in the same circular direction within the same orbit plane. As a result, at any location on earth, we can see there will have two group of satellites moving on the opposite direction. One group moves from south to north, and another group moves from north to south. Section 5.5 has more details.

4.3. Communication between Satellites by ISL

When ISL is used for the communication between satellites, each satellite will have a fixed number of links to connect to its neighbor. Due to the cost of ISL and the constraints of power supply on satellite, the number of ISL is normally limited to connect to its closest neighbors. In 3D space, each satellite may have six types of adjacent satellites, each type represents one direction. The number of adjacent neighbors in one direction is dependent on the number of deployment of ISL device on satellites, for example, the laser transmitter and receiver for ISLL. Figure 1 illustrates satellite S0 and its adjacent neighbors.

       /           /           /
      /           /           /
     /           /           /
    S7          S8          S9
   /           /           /
  /           /           /
 /           /           /
       /           S1          /
      S5          /           S3
     /           /           /
    /           S0          /
   /           /           /
  S6          /           S4
 /           S2          /
       /           /           /
      /           /           /
     /           /           /
    S10         S11         S12
   /           /           /         ^ Moving direction
  /           /           /         /
 /           /           /         /
orbit      orbit       orbit
Figure 1: Satellite S0 and its adjacent neighbors

All adjacent satellites of S0 in Figure 1 are listed below:

  1. The front adjacent satellite S1 that is on the same orbit plane as S0.
  2. The back adjacent satellite S2 that is on the same orbit plane as S0
  3. The right adjacent satellites S3 and S4 that are on the right orbit plane of S0
  4. The left adjacent satellites S5 and S6 that are on the left orbit plane of S0
  5. The above adjacent satellites S7 to S9 that are on the above orbit plane of S0
  6. The below adjacent satellite S10 to S12 that are on the below orbit of plane S0

The relative position of adjacent satellites will directly determine the quality of ISL and communication. From the analysis in [I-D.lhan-problems-requirements-satellite-net], The speed of satellite is only related to the altitude of the satellite (on circular orbit), all satellites with a same altitude will move with the same speed. So, in above adjacent satellites, some adjacent satellite's relative positions are steady and the ISL can be alive without interruption caused by movement. Some adjacent satellites relative positions are changing quickly, the ISL may be down since the distance may become out of reach for the laser of ISL, or the quick changed positions of two satellite make the tracking of laser too hard. Below are details:

  • The relative position of satellites in the same orbit plane will be the steadiest.
  • The relative position of satellites in the direct neighbor orbit planes in the same shell group and moving in the same direction will be steady at equator area, but will be changing when two orbits meet on the polar area. Whether the link status will be flipping depends on the tracking technology and the range of laser pointing angle of ISL. See Figure 2.
  • The relative position of satellites in the neighbor orbit planes in the same shell group but moving in the different direction will not be steady at all times. More details are explained in Figure 8
  • The relative position of satellites in the neighbor orbit planes in the different shell group will be dependent on the difference of altitude and inclination. This has been analyzed in [I-D.lhan-problems-requirements-satellite-net].
             \      /
              P3   P4
               \  /
                \/
                /\
               /  \
              P1   P2
             /      \

* Two satellites S1 and S2 are at position P1 and P2 at time T1
* S1's right facing ISL connected to S2's left facing ISL
* S1 and S2 move to the position P4 and P3 at time T2
* S1's left facing ISL connected to S2's right facing ISL
* So, if the range of laser pointing angle is 360 degree and
  tracking technology supports, the ISL will not be flipping
  after passing polar area; Otherwise, the link will be flipping

Figure 2: Satellite's Position and ISL Change at Polar Area

5. Addressing of Satellite

When ISL is deployed in satellite constellation, all satellites in the constellation can form a network like the wired network on ground. Due to the big number of satellites in a constellation, the network could be either L2 or L3. The document proposes to use L3 network for better scalability.

When satellites form a L3 network, it is expected that IP address is needed for each satellite and its ISLs.

While the traditional IP address can still be used for satellite network, the document proposes an alternative new method for satellite's addressing system. The new addressing system can indicate a satellite's orbit info such as shell group index, orbit plane index and satellite index. This will make the adjacent satellite identification for link status easier and benefit the routing algorithms.

5.1. Indexes of Satellite

As described in Section 4.2, one satellite has three important orbit related information as described below.

  1. Index for the shell group of satellites in a satellite constellation
  2. Index for the orbit plane in a shell group of satellites
  3. Index for the satellite in an orbit plane

It should be noted that for all type of indexes, it is up to the owner to assign the index number. There is no rule for which one should be assigned with which number. The only important rule is that all index number should be in sequential to reflect its relative order and position with others. Below is an example of assignment rules:

  1. The 1st satellite launched in an orbit plane can be assigned for the 1st satellite index (0), the incremental direction of the satellite index in the same orbit plane is the incremental direction of "Argument of periapsis (omega)"
  2. The 1st orbit plane established can be assigned for the 1st orbit plane index (0), the incremental direction of the orbit plane index is the incremental direction of "Longitude of the ascending node (Omega)".
  3. The shell group of satellites with the lowest altitude can be assigned for the 1st shell group index (0), the incremental direction of shell group index is the incremental direction of altitude.

Figure 3 and Figure 4 illustrate three types of indexes for satellite.

       /           /           /   \
      /           /           /    |
     /           /           /     |
    S           S           S      > shell group3
   /           /           /       |
  /           /           /        |
 /           /           /         /
       /           S           /   \
      S           /           S    |
     /           /           /     |
    /           S           /       > shell group2
   /           /           /       |
  S           /           S        |
 /           S           /         /
       /           /           /   \
      /           /           /    |
     /           /           /     |
    S           S           S       > shell group1
   /           /           /       |
  /           /           /        |
 /           /           /         /
orbit     orbit      orbit           ----> Earth self-rotation
plane1    plane2     plane3
Figure 3: Shell Group and Orbit Plane Indexes for Satellites

Shell Group and Orbit Plane Indexes for Satellites


         , - ~ S1 ~ - ,
     S2 '              ' S8
   ,                       ,
  ,                         ,
 ,                           ,      Indexed
 S3                          S7 <-- satellite
 ,                           ,      in one orbit plane
  ,                         ,
   ,                       ,      ^  move direction
     S4                 , S6     /
       ' - , _ S5_ ,  '         /


Figure 4

Three type of Index for satellites

5.2. The Range of Satellite Indexes

The ranges of different satellite indexes will determine the range the dedicated field for semantic address. The maximum indexes depend on the number of shell group, orbit plane and satellite per orbit plane. The number of orbit plane and satellite per orbit plane have relationship with the coverage of a satellite constellation. There are minimum numbers required to cover earth. [I-D.lhan-problems-requirements-satellite-net] has given the detailed math to estimate the minimal number required to cover the earth. There are two key parameters that determine the minimal number of satellite required. One is the elevation angle, another is the altitude. SpaceLink has proposed two elevation angles, 25 and 35 degrees [SpaceX-Non-GEO]. The lowest LEO altitude can be 160km according to [Lowest-LEO-ESA]. The Table 1 and Table 2 illustrate the estimation for different altitude (As), the coverage radius (Rc), the minimal required number of orbit planes (No) and satellite per orbit plane (Ns). The elevation angle is 25 degree and 35 degrees respectively.

Table 1: Satellite coverage (Rc), minimal number of orbit plane (No) and satellite (Ns) per orbit plane for different LEO/VLEOs, Elevation angle = 25 degree
Parameters VLEO1 VLEO2 LEO1 LEO2 LEO3 LEO4 LEO5
As(km) 160 300 600 900 1200 1500 2000
Rc(km) 318 562 1009 1382 1702 1981 2379
Ns 73 42 23 17 14 12 10
No 85 48 27 20 16 14 12
Table 2: Satellite coverage (Rc), minimal number of orbit plane (No) and satellite (Ns) per orbit for different LEO/VLEOs, Elevation angle = 35 degree
Parameters VLEO1 VLEO2 LEO1 LEO2 LEO3 LEO4 LEO5
As(km) 160 300 600 900 1200 1500 2000
Rc(km) 218 392 726 1015 1271 1498 1828
Ns 107 59 32 23 19 16 13
No 123 69 37 27 22 18 15

The real deployment may be different as above analysis. Normally, more satellites and orbit planes are used to provide better coverage. So far, there are only two proposals available, one is StarLink, another is from China Constellation. For proposals of [StarLink], there are 7 shell groups, the number of orbit plane and satellites per orbit plane in all shell groups are 72 and 58; For proposals of [China-constellation], there are 7 shell groups, the number of orbit plane and satellites per orbit plane in all shell groups are 60 and 60;

It should be noted that some technical parameters, such as the inclination and altitude of orbit planes, in above proposals may be changed during the long-time deployment period, but the total numbers for indexes normally do not change.

From the above analysis, to be conservative, it is safe to conclude that the range of all three satellite indexes are less than 256, or 8-bit number.

5.3. Other Info for satellite addressing

In addition to three satellite indexes described in Section 5.1, other information is also important and can also be embedded into satellite address:

  1. The company or country code, or the owner code. In the future, there may have multiple satellite constellations on the sky from different organizations, and the inter-constellation communication may become as normal that is similar to the network on the ground. This code will be useful to distinguish different satellite constellation and make the inter-constellation communication possible. One satellite constellation will have one code assigned by international regulator (IANA or ITU). Considering the limit of LEO orbits and the cost of satellite constellations, the total number of satellite constellation is very limited. So, the size of code is limited.
  2. The Interface Index. This index is to identify the ISL or ISLL for a satellite. As described in Section 4.3, the total number of ISL is limited. So, the size of interface index is also limited.

5.4. Encoding of Satellite Semantic Address

The encoding for satellite semantic address is dependent on what routing and switching (L2 or L3 solution) technologies are used for satellite networking, and finally dependent on the decision of IETF community.

Follows are some initial proposals:

  1. When satellite network is using L3 solution, the satellite semantic address is encoded as the interface identifier (i.e., the rightmost 64 bits) of the IPv6 address for IPv6. Figure 5 shows the format of IPv6 Satellite Address.
  2. When satellite network is using L2 solution, the satellite semantic address can be embedded into the field of "Network Interface Controller (NIC) Specific" in MAC address [IEEE-MAC-Address]. But due to shorter space for NIC, the "Index for the shell group" and "Index for Interface" will only have 4-bit. This is illustrated in Figure 6. This encoded MAC address can also be used for L3 solution where the interface MAC may be also needed to be configured for each ISL.
  3. Recently, some works suggested to use Length Variable IP address for routing and switching [Length-Variable-IP] or use flexible IP address [I-D.jia-flex-ip-address-structure] or shorter IP address [I-D.li-native-short-addresses] to solve some specific problems that regular IPv6 is not very suitable. Satellite network also belongs to such specific network. Due to the resource and cost constraints and requirement for radiation hardened electronic components, the ISL speed, on-board processor and memory are limited in performance, power consumption and capacity compared with network devices on ground. So, using IPv6 directly in satellite network is not an optimal solution because IPv6 header size is too long for such small network. From above analysis, 32-bit to 64-bit length of IP address is enough for satellite networking. Using 128-bit IPv6 will consume more resource especially the ISL bandwidth, processing power and memory, etc. If shorter than 128-bit IP address is accepted as IETF work, the satellite semantic address can be categorized as a similar use case. Figure 7 illustrates a 32-bit Semantic Satellite Address format. The final coding for the shorter IP address can be decided by the community. How to use the 32-bit Semantic Satellite address can be addressed later on in different document.
  0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                     Subnet Prefix (64 bits)                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Owner Code  |  Shell_Index  |  Orbit_Index  |   Sat_Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Intf_Index  |                    Reserved                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Owner Code: Identifier for the owner of the constellation
Shell_Index: Index for the shell group of satellite in a satellite
             constellation
Orbit_Index: Index for the orbit plane in a shell group of satellite
Sat_Index: Index for the satellite in an orbit plane
Intf_Index: Index for interface on a satellite
Reserved: 24-bits reserved
Figure 5: The IPv6 Satellite Address
          3 Octets             3 Octets
    /---------^--------\ /--------^--------\
    +-------------------+-------------------+
    |        OUI        |     Sat Address   |
    +-------------------+-------------------+
                                 |
                                 |
 +-------------------------------+
 |
 |
 v

  0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shell |  Orbit_Index  |   Sat_Index   |Intf_Id|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OUI: Organizationally Unique Identifier assigned by IEEE
Shell: 4-bit Index for the shell group of satellite in a satellite
       constellation
Orbit_Index: Index for the orbit plane in the group of satellite
Sat_Index: Index for the satellite in the orbit plane
Intf_Id: 4-bit Index for interface on a satellite
Figure 6: The MAC Satellite Address
  0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Owner Code  |  Shell_Index  |  Orbit_Index  |   Sat_Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Owner Code: Identifier for the owner of the constellation
Shell_Index: Index for the shell group of satellite in a satellite
             constellation
Orbit_Index: Index for the orbit plane in a shell group of satellite
Sat_Index: Index for the satellite in an orbit plane

Figure 7: The 32-bit Semantic Satellite Address

6. IANA Considerations

This memo may include request to IANA for owner code, see Section 5.4.

7. Contributors

8. Acknowledgements

9. References

9.1. Normative References

[RFC4271]
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <https://www.rfc-editor.org/info/rfc4271>.
[RFC2328]
Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, , <https://www.rfc-editor.org/info/rfc2328>.
[RFC7142]
Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 to Historic", RFC 7142, DOI 10.17487/RFC7142, , <https://www.rfc-editor.org/info/rfc7142>.
[RFC2453]
Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10.17487/RFC2453, , <https://www.rfc-editor.org/info/rfc2453>.
[RFC7868]
Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and R. White, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, , <https://www.rfc-editor.org/info/rfc7868>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.

9.2. Informative References

[I-D.lhan-problems-requirements-satellite-net]
Han, L., Li, R., Retana, A., Chen, M., Su, L., and N. Wang, "Problems and Requirements of Satellite Constellation for Internet", Work in Progress, Internet-Draft, draft-lhan-problems-requirements-satellite-net-02, , <https://datatracker.ietf.org/doc/html/draft-lhan-problems-requirements-satellite-net-02>.
[I-D.jia-flex-ip-address-structure]
Jia, Y., Chen, Z., and S. Jiang, "Flexible IP: An Adaptable IP Address Structure", Work in Progress, Internet-Draft, draft-jia-flex-ip-address-structure-00, , <https://datatracker.ietf.org/doc/html/draft-jia-flex-ip-address-structure-00>.
[I-D.li-native-short-addresses]
Li, G., Jiang, S., and D. E. 3rd, "Native Short Addresses for the Internet Edge", Work in Progress, Internet-Draft, draft-li-native-short-addresses-01, , <https://datatracker.ietf.org/doc/html/draft-li-native-short-addresses-01>.
[Routing-for-LEO]
E. Ekici, I. F. Akyildiz and M. D. Bender, ""Datagram routing algorithm for LEO satellite networks," Proceedings IEEE INFOCOM 2000. Conference on Computer Communications. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies (Cat. No.00CH37064), 2000, pp. 500-508 vol.2, doi: 10.1109/INFCOM.2000.832223.", <https://ieeexplore.ieee.org/document/832223>.
[Length-Variable-IP]
Shoushou Ren, Delei Yu, Guangpeng Li, Shihui Hu, Ye Tian, Xiangyang Gong, Robert Moskowitz, ""Routing and Addressing with Length Variable IP Address," NEAT'19: Proceedings of the ACM SIGCOMM 2019 Workshop on Networking for Emerging Applications and Technologies, August 2019", <https://doi.org/10.1145/3341558.3342204>.
[IEEE-MAC-Address]
"IEEE Std 802-2001 (PDF). The Institute of Electrical and Electronics Engineers, Inc. (IEEE). 2002-02-07. p. 19. ISBN 978-0-7381-2941-9. Retrieved 2011-09-08.", <https://standards.ieee.org/getieee802/download/802-2001.pdf>.
[Lowest-LEO-ESA]
"Lowest LEO by ESA", <https://www.esa.int/ESA_Multimedia/Images/2020/03/Low_Earth_orbit#:~:text=A%20low%20Earth%20orbit%20(LEO,very%20far%20above%20Earth's%20surface.>.
[KeplerianElement]
"Keplerian elements", <https://en.wikipedia.org/wiki/Orbital_elements>.
[OSI-Model]
"OSI Model", <https://en.wikipedia.org/wiki/OSI_model>.
"Star Link", <https://en.wikipedia.org/wiki/Starlink>.
[China-constellation]
"China Constellation", <https://www.itu.int/ITU-R/space/asreceived/Publication/DisplayPublication/23706>.
[SpaceX-Non-GEO]
"FCC report: SPACEX V-BAND NON-GEOSTATIONARY SATELLITE SYSTEM", <https://fcc.report/IBFS/SAT-LOA-20170301-00027/1190019.pdf>.

Appendix A. Change Log

Authors' Addresses

Lin Han (editor)
Futurewei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050,
United States of America
Richard Li
Futurewei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050,
United States of America
Alvaro Retana
Futurewei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050,
United States of America
Meiling Chen
China Mobile
32, Xuanwumen West
BeiJing 100053
China
Ning Wang
University of Surrey
Guildford
Surrey, GU2 7XH
United Kingdom

mirror server hosted at Truenetwork, Russian Federation.