Starlink routing

(inline)

the ability to route messages between each satellite. Would conventional
routing protocols be up to such a challenge?

If conventional is taken to mean “stock” link-state stuff, then probably no (speculating).

Or would it have to be
custom made for that problem? And since a lot of companies and countries
are getting on that action, it seems like fertile ground for (bad) wheel
reinvention?

As others might comment, “it’s all been done (and modeled) before,” or “we tried it 20 years ago, and it worked then” - more inline here:

My present understanding is that starlink satellites with lasers are not designed to communicate inter-plane. Each launch of starlink satellites is put into exactly the same orbital inclination (53.2 degrees or the more rare near polar orbits now launched from Vandenberg).

In the weeks and months following their launch they spread out into an extended line all following each other in the same plane. Plane change maneuvers are extremely expensive in delta-v for any satellite and are generally avoided unless absolutely necessary. Best conjecture is that starlink satellites’ on board propellant for hall effect or ion thrusters (or whatever they’re using that has an ISP above 3000) is used almost exclusively for thrusting prograde to maintain altitude.

If you view a launch of 45 or 50 starlink satellites in a live animated satellite tracking application, based on their TLE orbital data, they all follow each other in a line. Satellites in the same line may be using inter-satellite lasers to speak to the unit immediately in front of it, and immediately behind it, forming a conga-line like network of linked satellites until they get to one that is generally above a starlink earth station/terrestrial network facility. At which point the traffic is transferred.

Starlink has recently made service available for purchase in Nunavut and all of the other high-latitude areas of northern Canada, which means that they clearly think they have sufficient (82 degree plus) inclination sets of satellites and inter-satellite links working to provide service in an area that definitely has no terrestrial fiber or starlink earth stations.

Don’t quote me on this, but I wouldn’t say they are doing anything different than you or I can do and have access to on the routing layer. It's probably just Nokia and Arista and whatever those systems provide. Stuff like Tunneling, ECMP, BFD and VxLan... Think spatially coordinated Zerotier and not based on latency. They also have a pretty good team of experts that have experience with large scale networking and automation they've plucked from various places.

How the Satellites talk to the end users is where all the magic is. But my understanding is that it's all custom developed networking as code that handles all the frequency coordination and hand offs with the ground.

For the people who have seen their US48 state earth station setups in person it is pretty normal on the network level. Being colocated with major inter-city long haul dark fiber DWDM regen sites (Level3 dark fiber path Seattle to Boise, ID which has a regen hut site in Prosser, WA is a perfect example) gives them the ability to buy a transport circuit to the nearest major city/IX point and haul traffic there. I believe they’re buying single 100 Gbps waves.

My original thought was this would be more like Client Optimized Roaming with WiFi access points.

Communication between the client dish or base station and satellites to transparently move client dish and base station from satellites moving out of view to a satellite in view.

Kevin McCormick

The original and traditional high-cost way of how this is done for MEO/LEO is exemplified by an o3b terminal, which has two active motorized tracking antennas. The antenna presently in use for the satellite that is overhead follows it until it’s descending towards the horizon, while at the same time the second antenna aims itself at where the next ‘rising’ satellite is predicted to appear at the opposite horizon, and forms a link to it. Make-before-break. If anyone has seen photographs in their marketing material/videos of the Oneweb beta test earth stations in Alaska they are operating using the same general concept.

Oneweb has clearly positioned their market focus for telecoms and ISPs and large enterprise end users, because their CPE equipment is considerably larger, expensive and more power hungry. The beta test sites I’ve seen installed on top of a telecom equipment shelter occupy an area approximately 8 feet long x 4 feet wide including radomes and mounting.

I'm trying to understand this so sorry if this comes off dumb. So does the base station mediate all handoffs where the CPE is told when/what to handoff? Or does the CPE have some part in it (other than receiving the handoff)? Does the CPE accept control traffic (L2?) from any bird? Are there cases where the CPE needs to de-dup packets due to handoffs?

This is pretty fascinating stuff.

Mike

FYI,

We are in the process of starting a new Working Group at IETF, Timer Variant Routing or TVR.
https://datatracker.ietf.org/group/tvr/about/

Some of the uses cases are for space applications where you can predict or schedule the availability and capacity of “links” (radio, optical)

This gets sort of merged with DTN (Delay/Disruption Tolerant Networking.)

NASA GRC has developed a High Speed version of DTN aka HDTN that is being tested in terrestrial setups but soon to be tested in space.
https://www1.grc.nasa.gov/space/scan/acs/tech-studies/dtn/

For now all this is experimental.

Plus there are several commercial entities also working in this realm, one is https://www.aalyria.com/, spin-off of Google’s Loon project.

-J

I think it’s useful to clarify terminology - the starlink antenna unit itself is the CPE. With my v1 starlink terminal you can plug literally anything into the PoE injector that is a 1500 MTU 1000BaseT DHCP client and it’ll get an address and a default route out to the internet. All of the smarts happen in the antenna unit/phased array unit which also has its own fairly capable embedded CPU/RAM and routing capability.

The starlink indoor CPE, the home wifi router itself ,is a very basic thing that looks like something derived from a Taiwan ODM 802.11ac home router OpenWRT reference design with a custom firmware load.Or similar. If you’ve seen a teardown of one they’re very simple.

With the v2 rectangular terminals it’s similar but you need a cable adapter to go from the proprietary starlink cable to indoor unit, and additionally the indoor CPE unit also serves as the PoE injector.

In some other ISP type environments you might be expecting the indoor unit to be the CPE, such as what you’d get with a Comcast DOCSIS3.0 all-in-one modem+coax interface+router+wifi device attached to some coax coming in through a wall.

Jorge Amodio wrote:

We are in the process of starting a new Working Group at IETF, Timer
Variant Routing or TVR.
Time-Variant Routing (tvr)

Some of the uses cases are for space applications where you can predict or
schedule the availability and capacity of "links" (radio, optical)

Even though the current routing protocols have no difficulty
to treat unpredictable/unscheduled changes on links?

This gets sort of merged with DTN (Delay/Disruption Tolerant Networking.)

I have been saying that DTN is a reinvention of UUNET.

As such, it should be noted that, in UUNET, availability of
phone links between computers was scheduled.

          Masataka Ohta

This gets sort of merged with DTN (Delay/Disruption Tolerant Networking.)

I have been saying that DTN is a reinvention of UUNET.

Hmmm, nope not even close.

As such, it should be noted that, in UUNET, availability of
phone links between computers was scheduled.

You must be talking about UCCP, UUNET was a company.

Availability of links was declared not scheduled, so pathalias was able to figure the best UUCP path from a given UUCP node.

-J

Jorge Amodio wrote:

This gets sort of merged with DTN (Delay/Disruption Tolerant Networking.)

I have been saying that DTN is a reinvention of UUNET.

Hmmm, nope not even close.

You, seemingly, do not have much knowledge on UUNET.

As such, it should be noted that, in UUNET, availability of
phone links between computers was scheduled.

You must be talking about UCCP, UUNET was a company.

Why, do you think, UUNET as a company named so?

It was an organization to offer connectivity to UseNET but some
used the word to just mean UseNET. See, for example:

  “UA” to “UUNET” (Sun Global Glossary)
  UUNET
  (n.) A network that carries electronic newsgroups, aggregates
  of many electronic messages that are sorted by topic, to
  thousands of users on hundreds of workstations worldwide.

Availability of links was declared not scheduled,

Declared in map files used by pathalias? But that's not my point.

UUCP links were not permanent but scheduled. See, for example:

  IBM Documentation
  Schedule periodic UUCP transfers with cron

so pathalias was able to
figure the best UUCP path from a given UUCP node.

Such initial attempts were not so elegant or scalable.

UUCP networks as DTN were brought to perfection through
integration with the Internet relying on DNS MX RRs.

            Masataka Ohta

You, seemingly, do not have much knowledge on UUNET.

Of course I don’t :slight_smile:

#N atina
#S Everex 386 Step 33; SCO Xenix System V 2.3.3
#O Ministerio de Relaciones Exteriores y Culto
#C Jorge Marcelo Amodio
#E atina!postmaster
#T +54 1 315 4804, Fax: +54 1 315 4824
#P Reconquista 1088, Buenos Aires (1003) - ARGENTINA
#L 34 34 S / 58 03 W city
#R
#W atina!pete ( Jorge M. Amodio ); Fri Mar 16 14:43:03 ARG 1990
atina .ar
atina .mrec.ar
atina = atina.ar, atina.mrec.ar
atina agomar(DAILY), antar(DAILY), biotlp(DAILY), cab(HOURLY),
cedro(EVENING), cenep(DAILY), cneaint(DAILY), cnea(EVENING),
cnielf(DAILY), colimpo(DAILY), confein(DAILY), criba(EVENING),
curbre(EVENING), dacfyb(DEMAND), dcfcen(DEMAND), ecord(DEMAND),
enace(DAILY), epfrn(EVENING), fb1(DAILY), fcys(DAILY), fecic(DAILY),
gagcha(EVENING), getinfo(DAILY), hasar(DAILY), iaros(DAILY),
intiar(DAILY), invapba(DAILY/2), invapqq(DAILY/2), isoft(DAILY),
itcgi(DAILY), labdig(DAILY), lasbe(DAILY), licmdp(EVENING),
lis(EVENING), ludo(DAILY), maap(DAILY), meyosp(DAILY),
minerva(DAILY), minjus(DAILY), mlearn(DAILY), occam(EVENING),
oceanar(DAILY), onba(DAILY), opsarg(DEMAND), pnud009(EVENING),
sadio(DAILY), saravia(DAILY), sdinam(DAILY), secyt(DEMAND),
spok(DAILY), sykes(DAILY), tandil(DAILY), tsgfred(WEEKLY),
ulatar(EVENING), unisel(EVENING), uunet(DEMAND)

-J

Jorge Amodio wrote:

You, seemingly, do not have much knowledge on UUNET.

Of course I don't :slight_smile:

atina agomar(DAILY), antar(DAILY), biotlp(DAILY), cab(HOURLY),
         cedro(EVENING), cenep(DAILY), cneaint(DAILY), cnea(EVENING),
         cnielf(DAILY), colimpo(DAILY), confein(DAILY), criba(EVENING),
         curbre(EVENING), dacfyb(DEMAND), dcfcen(DEMAND), ecord(DEMAND),
         enace(DAILY), epfrn(EVENING), fb1(DAILY), fcys(DAILY), fecic(DAILY),
         gagcha(EVENING), getinfo(DAILY), hasar(DAILY), iaros(DAILY),
         intiar(DAILY), invapba(DAILY/2), invapqq(DAILY/2), isoft(DAILY),
         itcgi(DAILY), labdig(DAILY), lasbe(DAILY), licmdp(EVENING),
         lis(EVENING), ludo(DAILY), maap(DAILY), meyosp(DAILY),
         minerva(DAILY), minjus(DAILY), mlearn(DAILY), occam(EVENING),
         oceanar(DAILY), onba(DAILY), opsarg(DEMAND), pnud009(EVENING),
         sadio(DAILY), saravia(DAILY), sdinam(DAILY), secyt(DEMAND),
         spok(DAILY), sykes(DAILY), tandil(DAILY), tsgfred(WEEKLY),
         ulatar(EVENING), unisel(EVENING), uunet(DEMAND)

So, you now remember that UUCP links were scheduled.

            Masataka Ohta