Source Based Time Variant Routing
draft-yu-tvr-source-based-time-variant-routing-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tianpeng Yu | ||
| Last updated | 2024-07-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yu-tvr-source-based-time-variant-routing-00
TVR Workgroup T. Yu
Internet-Draft 10 July 2024
Intended status: Informational
Expires: 11 January 2025
Source Based Time Variant Routing
draft-yu-tvr-source-based-time-variant-routing-00
Abstract
This document describes a source-based time variant routing
methodology that can be used in a network with predicted variations.
By using source-based time variant routing, the source node uses
stable information (e.g. orbit of satellite) to calculate the
forwarding path between source and destination nodes. The
intermediate node does not need to maintain routing information, such
that in case of neighbor variations (restoration, activation, change
of quality, or loss), there are no routing information changes. The
routing decision is done by the source node. This makes building a
highly scalable network with predicted variations possible (e.g. tens
of thousands of satellites).
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 11 January 2025.
Copyright Notice
Copyright (c) 2024 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.
Yu Expires 11 January 2025 [Page 1]
Internet-Draft Source Based Time Variant Routing July 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Basic Logic of Source Based Time Variant Routing . . . . . . 4
5. Maintaining and Synchronizing SGDB . . . . . . . . . . . . . 7
5.1. SGDB Synchronization Between Satellites . . . . . . . . . 7
5.2. Ground Station Registration . . . . . . . . . . . . . . . 8
6. User Terminal Registration . . . . . . . . . . . . . . . . . 8
6.1. User Terminal Registration Towards Satellite . . . . . . 8
6.2. User Terminal Registration Towards Ground Station . . . . 8
7. Network Topology Changes Considerations . . . . . . . . . . . 9
7.1. Overall Considerations on Network Topology Changes . . . 9
7.2. UT Switching Between Satellites . . . . . . . . . . . . . 9
7.3. GS Switching Between Satellites . . . . . . . . . . . . . 10
7.4. ISL Status Changing . . . . . . . . . . . . . . . . . . . 10
8. Load Balancing Considerations . . . . . . . . . . . . . . . . 11
9. Service Scenarios . . . . . . . . . . . . . . . . . . . . . . 11
9.1. L3 services . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. L2 services . . . . . . . . . . . . . . . . . . . . . . . 12
9.3. L1 service . . . . . . . . . . . . . . . . . . . . . . . 12
9.4. Multicast service . . . . . . . . . . . . . . . . . . . . 12
10. Comparison with Existing Researches and Solutions . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
[draft-ietf-tvr-use-cases] describes the use cases of time variant
routing. This document describes a source-based time variant routing
methodology that can be used in a network with predicted variations.
By using source-based time variant routing, the source node uses
stable information (e.g. orbit of satellite) to calculate the
forwarding path between source and destination nodes. The
intermediate node does not need to maintain routing information, such
that in case of neighbor variations (restoration, activation, change
of quality, or loss), there are no routing information changes. The
Yu Expires 11 January 2025 [Page 2]
Internet-Draft Source Based Time Variant Routing July 2024
routing decision is done by the source node. This makes building a
highly scalable network with predicted variations possible (e.g. tens
of thousands of satellites).
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
3. 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.
TN: Terrestrial Network; refers to networks providing connectivity
through communication lines that travel on, near, and/or below
ground.
UT: User Terminal. Usually known as a dish. Using cellphone as a
user terminal will be described in a separate document.
UTID: A permanent ID uniquely identifies a UT. UTID is globally
unique over the world.
UTTID: User Terminal Temporary ID.
GS: Ground Station, a device on the ground connecting the satellite
and also connecting to TN.
GSID: A permanent ID uniquely identifies a GS. GSID is globally
unique over the world.
SL: Satellite Link. Link between UT and satellite or link between GS
and satellite.
FP: Forwarding path built via source based routing between UT,
satellites and GS. A FP is calculated by UT via source-based routing
algorithm. GS maintains a reversed FP used for reversed traffic from
GS to UT.
Yu Expires 11 January 2025 [Page 3]
Internet-Draft Source Based Time Variant Routing July 2024
SGDB: Satellite and GS database. Each satellite has a unique
identifier (ID). SGDB maintains a database containing information of
each satellite, including but not limited:
* Inclination (i)
* Longitude of the ascending node (Omega)
* Eccentricity (e)
* Semimajor axis (a)
* Argument of periapsis (omega)
* True anomaly (nu)
* Number and direction of the lasers (for ISL communication)
SGDB also maintains the information of each GS:
* The position (longitude, latitude) of ground station (the site
connecting to PoP providing internet access).
SGDB does not maintain the position of UT(s).
To be clear, these information looks a lot, but these information is
quite stable, and does not change due to the movement of the
satellites.
For a given time T, the position (longitude, latitude, height) of any
satellite is known based on the SGDB. Also the number of ISLs of a
satellite is known, the adjacency(adjacencies) of a satellite can be
determined and the bandwidth of the ISL(s) can be calculated.
4. Basic Logic of Source Based Time Variant Routing
One important character of source based time variant routing
described in this document is that the routing decision is determined
by the source node on the ground (user terminal or ground station),
instead of on the satellite. The SGDB does not maintain any MAC and
routing tables from users. The decision is made based on SGDB which
is a stable database.
There are pre-conditions below to allow source based time variant
routing algorithm work:
* It is required that UT and GS have SGDB. The method of
synchronizing SGDB is described in section TBD.
Yu Expires 11 January 2025 [Page 4]
Internet-Draft Source Based Time Variant Routing July 2024
* It is required that UT and GS are time synchronized. Detailed
considerations on time synchronization is described in section
TBD.
* It is required that UT, GS know their location(longitude,
latitude).
T=T0
+-+-+-+ +-+-+-+ +-+-+-+
| C |~~~~~| D |~~~| F |
+-+-+-+ +-+-+-+ +-+-+-+
~ ~
~ ~
+-+-+-+ +-+-+-+ +-+-+-+
| E |~~~~~~~| A |~~~~~~| B |
+-+-+-+ +-+-+-+ +-+-+-+
* *
* *
* *
+-+-+-+ +-+-+-+ +-+-+-+
| UT | | GS |===| PoP |
+-+-+-+ +-+-+-+ +-+-+-+
*** Satellite link
~~~ ISL (Inter Satellite Link)
=== Link on the ground (e.g. fiber)
Figure 1: Topology at time T0
Yu Expires 11 January 2025 [Page 5]
Internet-Draft Source Based Time Variant Routing July 2024
T=T0+T'
+-+-+-+ +-+-+-+ +-+-+-+
| C |~~~| D |~~~~~| F |
+-+-+-+ +-+-+-+ +-+-+-+
~ ~
~ ~
+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+
| G |~~~~~~~| E | | A |~~~~~| B |
+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+
* *
* *
* *
+-+-+-+ +-+-+-+ +-+-+-+
| UT | | GS |===| PoP |
+-+-+-+ +-+-+-+ +-+-+-+
*** Satellite link
~~~ ISL (Inter Satellite Link)
=== Link on the ground (e.g. fiber)
Figure 2: Topology at time T=T0+T'
Figure 1 shows a basic topology diagram of satellite constellations
used to explain the terminology of source-based time variant routing.
Let's assume that UT knows its location (Xu, Yu) and the location of
the nearest GS (Xg, Yg). UT and GS also know the orbit of the
satellites from SGDB. The detailed method of getting this
information is described in section 4.
With this information, given a time T=T0, it is not difficult for UT
to calculate the shortest path towards GS using the Dijkstra
algorithm (or similar ones). Considering a GS can have many UT
connected, to minimize the load of GS, GS will maintain a reversed
And vice versa from GS to UT, But this is not necessary considering
this will bring a significant load on the GS, as a GS can have many
UT connected. This is described below.
For the topology in Figure 1, at time T0, the best path to the
nearest GS is UT->A->B->GS.
The source node UT encapsulates the entire path containing the
source, destination, and a list of IDs of the satellites and the
nearest GS, with a pointer toward the ID of the satellite which
should process the packet (in the left diagram of Figure 1, UT
encapsulates path list {[UTID,(A, B), GSID], current=A}, and points
towards A), in front of the original packet.
Yu Expires 11 January 2025 [Page 6]
Internet-Draft Source Based Time Variant Routing July 2024
When A receives the packet, it first checks if the satellite ID (the
pointer points to) is equal to the ID itself. If yes, A checks if
the next ID is in the adjacency table. If yes, move the pointer to
the next ID and forward the packet to the corresponding ISL. So A
forwards the packet towards B and moves the pointer pointing to B,
the packet becomes {[UTID,(A, B), GSID], current=B}.
After B receives the packet, if the validations pass (same as the
process of A described above), it forwards the packet towards GS via
SL (air interface) and moves the pointer to the next, without
removing the header. So the packet becomes {[UTID,(A,B),GSID],
current=GSID}.
After GS receives the packet, it values GSID equal to the ID of
itself. If yes, it records a reversed path, which sends traffic back
to UT. The reversed path from GS back to UT is {[GSID,(B, A), UTID],
current=GSID}. GS can either reply to UT using this path for
protocol packets (e.g. UT authentication, IP allocation, etc.) or
send the data packet to PoP. For the data packet back from PoP, GS
can use the binding relationship between the IP address of the UT
allocated by GS and FP, and send traffic to UT based on the
destination IP of the packet. GS located the IP address to UT and
built a binding relationship between the IP and the FP.
After the process above, the UT and GS build a bi-directional path
over the SL and ISL. The path is stateless, which means the
satellites do not need to maintain the status of the path.
As the satellites keep moving, after time T', the satellites covering
the UT and GS change to E, D, and A as shown in the right diagram in
Figure 1. The UT recalculates the path towards the closest GS, based
on the SGDB and time T=T0+T', and the new path is UT->E->D->A->GS.
The UT sends a path with a notification message to GS with the new
path information, GS updates the binding relation between the IP of
UT and FP, sends an acknowledge message back to UT, and switches the
FP towards UT to the new path. After UT receives the acknowledge
message, it switches the FP to the new path.
5. Maintaining and Synchronizing SGDB
5.1. SGDB Synchronization Between Satellites
A control channel(or protocol) between satellites is used to
synchronize SGDB. The synchronizing mechanism SHOULD be incremental.
Each time an ISL established between satellites, the two satellites
compare if the SGDB each other are the same (a checksum based
mechanism MAY be used). If SGDBs are not the same, then incremental
synchronization(s) are initialized. Also when a new SGDB item is
Yu Expires 11 January 2025 [Page 7]
Internet-Draft Source Based Time Variant Routing July 2024
added into SGDB, such information MUST also be flooded to all other
satellite neighbors via ISL(s). Instead of synchronizing routing
prefixes via IGP(OSPF/IS-IS), SGDB synchronizes orbit of the
satellite and location of the ground station, which does not change
due to ISLs reestablishments. The detailed mechanism will be
described in a separate document.
To be clear that SGDB is a stable database. SGDB does not change due
to movements of satellites and up/down of ISLs.
5.2. Ground Station Registration
SGDB also needs to maintain the location(longitude, latitude)
information of all ground stations. When a new GS is built, and
linked with one of the satellite (S), it reports {GSID, (longitude,
latitude)} to satellite S. Satellite S add such info into its SGDB
and spread it via the mechanism described above.
The organizer information of a GS MAY also be reported. This allows
a specific organization (e.g. ISP) to use satellite constellation
together with its TN resources to provide specific services.
6. User Terminal Registration
6.1. User Terminal Registration Towards Satellite
When a new UT is connected to one of the satellite, it downloads the
SGDB from the satellite. With SGDB, the UT is able to use source-
based time variant routing algorithm to calculate the FP (forwarding
path) towards the closest GS.
UT MAY also report specific organization code, thus getting the SGDB
belonging to specific organization only.
Be aware that the UT information is NOT synchronized in the SGDB.
6.2. User Terminal Registration Towards Ground Station
To connect a UT to the internet, it is required that the UT gets the
IP address from the GS. GS acts as a gateway and allocate IPv6
address to UT.
GS SHOULD maintain a permanent mapping relationship between UTID and
the IPv6 address of UT. This consideration is because a UT MAY be
movable (e.g. Plane, Ship), a UT MAY switch to another GS after a
period of time. The detailed considerations on roaming UT is
described in section TBD.
Yu Expires 11 January 2025 [Page 8]
Internet-Draft Source Based Time Variant Routing July 2024
After UT downloads the SGDB from the connected satellite, the UT
itself is able to calculate a FP towards the GS. The UT initiates an
IPv6 address allocation request using the FP (DHCPv6 or similar
methods MAY be used). GS validates the UTID and allocates the IPv6
address to UT with a reply packet with the reversed FP.
7. Network Topology Changes Considerations
7.1. Overall Considerations on Network Topology Changes
As the satellites keep moving, SLs and ISLs goes up and down (but
predictable). The source node (UT) needs to recalculate a new FP
before any of the SLs or ISLs becomes unavailable.
The scenarios requiring the source node to recalculate the FP
include:
* UT/GS moves from coverage of one satellite to another one (or
signal strength changes).
* GS moves from coverage of one satellite to another one (or signal
strength changes).
* ISLs goes up/down due to movements of satellites.
The process (3-way handshake) is as below:
* T0: UT initiates a path change request using the old forwarding
path, with the new path info included in the request towards GS.
* T1: GS receives the path change request and records the new path
and start to accept packets with the new FP from UT, sends
acknowledge packet using the old FP.
* T2: UT sends acknowledge packet 2 using the new FP, and start
sending traffic with the new FP.
* T3: GS receives acknowledge packet 2 from UT. GS stop accepting
packets from UT with old FP. GS starts to send traffic towards UT
with the new FP.
7.2. UT Switching Between Satellites
Yu Expires 11 January 2025 [Page 9]
Internet-Draft Source Based Time Variant Routing July 2024
# ^
# ^
# ^
+-+-+-+ +-+-+^ # +-+-+-+
| A |**| UT| # | B |
+-+-+-+ +-+-+^ # +-+-+-+
#
# ^
# ^
# ^
#### coverage of satellite A
^^^^ coverage of satellite B
**** satellite link between satellite and UT
Figure 3: UT Considerations on Satellite Coverage
During time T0 and T3, it is required that UT maintains links towards
both of the satellites. UT needs to accept packets from GS with both
old FP and new FP.
7.3. GS Switching Between Satellites
GS is desired to have multiple antennas towards satellites where
possible. This allows GS to have higher bandwidth with satellite
link(s).
When GS moves from coverage of one satellite to another one (or
signal strength changes), GS notify all connected UT using the SL
being switched to initiate a FP switching process. Then UT starts
switching process based on the process described in Section 7.1 of
this document.
During time T0 and T3, it is required that GS maintains links towards
both of the satellites. GS needs to accept packets from GS with both
old FP and new FP.
7.4. ISL Status Changing
UT needs to initiate a path before any of the ISL being used as
current FP. Due to the up/down and quality of ISLs are predicable by
UT, it is the responsibility of UT to initiate a FP change request
before an ISL becomes unusable. The procedure is same with the
process described in Section 7.1. UT and GS do not need to maintain
extra SLs during the switch of ISLs.
Yu Expires 11 January 2025 [Page 10]
Internet-Draft Source Based Time Variant Routing July 2024
8. Load Balancing Considerations
Due to ISLs are established in nearly vacuo space, the bandwidth of
ISLs can reach much much higher bandwidth than SLs. So in most of
the cases, ISL won't get full.
But still in some cases, one of the ISL MAY be used together by
couple of other satellites as an intermediate node. Let's assume
A,B,C and D have ISLs based in Figure 5. Traffic from UT connecting
to A can have two paths towards the GS connecting to D, which are
A-C-D and A-B-D. But UT connecting to B MAY also uses ISL B-D. This
may lead to ISL B-D becomes overloaded.
This can be addressed in several ways:
* When a source UT have multiple ECMP towards (the number of
paths=M) a destination GS, it sorts the path in ascending order
based on satellite ID of each hop, then generates a random number
N with a seed (the seed CAN use the permanent UTID). Then UT
choose the Ith path (I=N%M).
* Quality of service mechanism SHOULD be introduced to ensure
critical control packets are not lost and important service is not
impacted.
* When an ISL utilization reaches a threshold, a satellite MAY
randomly pick part of the best effort packets and generate FP
switch notifications towards UT. UT recalculates the path without
the corresponding link. The FP switch process is the same with
the process described in section 7.1.
+-+-+ +-+-+
| A |~~~~~~| B |
+-+-+ +-+-+
~ ~
~ ~
~ ~
+-+-+ +-+-+
| C |~~~~~~| D |
+-+-+ +-+-+
~~~ ISL (Inter Satellite Link)
Figure 5: Load Balancing between ISLs
9. Service Scenarios
Yu Expires 11 January 2025 [Page 11]
Internet-Draft Source Based Time Variant Routing July 2024
9.1. L3 services
Source-based time variant solution described in this document can be
used to provide L3 services to end users. L3 services can be
internet service or L3VPN service. L3VPN service can be achieved via
NVO3 [RFC7365]
9.2. L2 services
Source-based time variant solution described in this document does
not directly provide L2 service directly. But L2 services (e.g.
ELine, ELAN) can be achieved via NVO3 [RFC7365].
9.3. L1 service
Source-based time variant solution described in this document can be
used to provide L1 service (e.g. pseudo wire). Theoretically it is
possible to allow two UTs communicate each other via source-based
routing, as long as they know the location each other. But from
security perspective, the UTs SHOULD be authenticated before being
able to
9.4. Multicast service
To be studied.
10. Comparison with Existing Researches and Solutions
11. Security Considerations
TBD
12. IANA Considerations
This document does not make any requests from IANA.
13. References
13.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>.
[draft-ietf-tvr-use-cases]
Birrane, E. J., Kuhn, N., Qu, Y., Taylor, R., and L.
Zhang, "TVR (Time-Variant Routing) Use Cases", Work in
Yu Expires 11 January 2025 [Page 12]
Internet-Draft Source Based Time Variant Routing July 2024
Progress, Internet-Draft, draft-ietf-tvr-use-cases-09, 29
February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-tvr-use-cases-09>.
13.2. Informative References
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <https://www.rfc-editor.org/info/rfc7365>.
Author's Address
Tianpeng Yu
Email: [email protected]
Yu Expires 11 January 2025 [Page 13]