Tout le monde connait aujourd'hui l'utilisation de
constellations de
satellites en
orbite
basse pour les télécommunications et, par exemple, pour
l'accès à l'Internet. Contrairement à
l'ancienne technique de communication via des satellites en
orbite géostationnaire, la communication
directe entre satellites y joue un rôle important. Les satellites se
déplacent les uns par rapport aux autres, changeant en permanence la
topologie de ce réseau. Alors, comment se fait le
routage ? Ce RFC décrit une méthode possible, reposant
largement sur le protocole IS-IS.
Ce n'est pas forcément la technique réellement utilisée. Les
constellations existantes, dont la plus connue est
Starlink, sont des entreprises privées, très
secrètes, et qui ne décrivent pas leur configuration interne. Ce
RFC est donc un
travail de réflexion, mené à partir des rares informations
publiques. Il ne peut pas spécifier une solution complète. Si vous
envisagez de créer une constellation, il vous restera du travail
pour avoir une solution de routage.
D'abord, il faut voir les
particularités de ce réseau de satellites. Il est bien moins fiable
qu'un réseau terrestre (l'espace est agité, un satellite en panne
n'est pas facile à réparer) et il est tout le temps en mouvement. Ce
rythme important de changement est un défi pour les protocoles de
routage. Sauf si les satellites sont
exactement sur la même orbite, leur mouvement relatif fait qu'on a
une possibilité de communiquer à certains moments seulement, voire
quasiment jamais. Si deux satellites se déplacent en direction
opposée, leur vitesse relative, de l'ordre de dizaines de milliers
de km/h, ne permettra guère de communication entre eux.
Par contre, un point qui va faciliter les choses est que ces
mouvements, et donc l'établissement et la coupure du lien, sont
prévisibles. On peut compter sur Kepler et Newton !
La section 1.2 du RFC
rappelle le vocabulaire important. Notons le sigle ISL, pour
Inter-Satellite Link, la liaison directe entre
satellites, typiquement via un faisceau
laser. (Le RFC cite ce très vieil article de
Bell, « On the Production and
Reproduction of Sound by Light ».) Si vous ne le
connaissez pas, il faut aussi apprendre le sigle LEO, pour
Low Earth Orbit, désignant les satellites qui
orbitent à moins de 2 000 km de la surface de la Terre. On utilisera
aussi SR (Segment Routing), la technique du
routage par segments, décrite dans le RFC 8402 et SID (Segment IDentifier), qui
vient de cette technique. Et IS-IS (Intermediate System to
Intermediate System ) ? Ce protocole de routage est
normalisé par l'ISO (et donc la spécification n'est
normalement pas
librement disponible) mais il est aussi décrit dans le RFC 1142 et le RFC 1195 explique comment s'en servir pour IP. Attention : c'est un vieux RFC, datant
d'une époque où on pensait encore que les
protocoles OSI avaient peut-être un avenir (aujourd'hui, ils n'ont
même pas de page Wikipédia). Le RFC 1195 se
concentre donc sur la possibilité d'utiliser IS-IS pour router à la
fois OSI et TCP/IP. Aujourd'hui, il ne sert
plus qu'aux protocoles Internet.
La section 2 de notre RFC rappelle les points essentiels des
satellites LEO,
qui vont impacter les choix techniques. Quand deux satellites se
parlent via un ISL (Inter-Satellite Link), la
liaison ne peut avoir qu'une durée limitée, les deux satellites ne
restant pas visibles l'un par l'autre éternellement, s'ils sont sur
des orbites différentes. Par contre, les
périodes de visibilité et de non-visibilité peuvent être calculées à
l'avance, on peut compter sur les lois de la physique.
Les constellations peuvent être de grande
taille. En 2021, déjà, celle du milliardaire d'extrême-droite représentait un
tiers du total des satellites en orbite. Aujourd'hui, des
constellations de dizaines de milliers de satellites sont prévues
(occupant l'espace public et bloquant la visibilité sans
vergogne). Les protocoles de routage traditionnels peuvent gérer des
réseaux de grande taille mais à condition qu'ils soient relativement
statiques, avec juste une panne ou une addition d'un lien de temps
en temps, ce qui n'est pas le cas pour des réseaux de satellites en
mouvement. L'IETF a sous la main deux protocoles de routage
normalisés pour les réseaux mono-organisation, OSPF (RFC 2328 et RFC 5340) et
IS-IS (RFC 1195). (Il
existe d'autres protocoles pour ces réseaux mais convenant plutôt à
des réseaux plus petits.) Tous les deux sont à état des
liaisons et, pour passer à
l'échelle, tous les deux permettent de partitionner le
réseau en zones (areas) à l'intérieur desquelles
l'information de routage est complète, alors qu'entre zones, on ne
passe qu'une partie de l'information. Dans OSPF, il y a forcément
une zone spéciale, l'épine dorsale (backbone, la
zone de numéro 0). Rien que pour cela, le RFC estime qu'OSPF ne
serait pas un bon choix : contrairement aux réseaux terrestres, les
constellations n'ont rien qui pourrait servir d'épine dorsale. IS-IS
repose sur un système différent, où des zones dites « L1 » (de
niveau 1) regroupent des parties du réseau qui ne servent pas au
transit entre zones, qui est assuré par des zones « L2 ». La machine
individuelle peut aussi bien être dans L1 que dans L2 ou même dans
les deux. Si on adoptait le système simple de mettre chaque
satellite dans une zone L2 (puisque tout satellite peut servir au
transit), on perdrait tous les avantages du partitionnement.
L'utilisation de IS-IS va donc nécessiter des ajustements.
La
section 3 du RFC expose le mécanisme de transmission des paquets
choisi. Elle propose d'utiliser MPLS (RFC 3031), en
raison de sa souplesse (puisque la topologie change tout le temps),
avec le SR (Segment Routing) du RFC 8402
(et RFC 8660 pour son adaptation à MPLS). Dans cette
vision, il n'y a pas de transmission au niveau IP et donc un
traceroute ne montrerait pas le trajet entre
les satellites.
Reste le choix de l'IGP. La section 4 décrit la préférence
de l'auteur pour IS-IS. Dans cette hypothèse,
tous les satellites seraient des nœuds L1L2 (appartement aux deux
types de zones). Le passage à l'échelle serait assuré grâce au
système des relais, normalisé dans le RFC 9666. Un réseau de 1 000 zones L1, chacune comportant
1 000 satellites, n'aurait besoin que de mille entrées (et pas un
million) dans ses tables de routage, aussi bien L1 que L2. Idem pour
la table des étiquettes MPLS.
La section 5 introduit le
concept de bande (stripe). La bande est un
ensemble de satellites dont les orbites sont suffisamment proches
pour que la connectivité entre eux change peu.
On l'a dit,
une particularité importante des réseaux de satellites est la
prévisibilité des coupures. Un calcul de mécanique
céleste permet de dire quand deux satellites
ne pourront plus communiquer. On peut bien sûr router comme s'il
s'agissait de pannes imprévues, mais on améliorera certainement la
qualité du routage (et on diminuera le nombre de pertes de paquets
lorsque la topologie change) si on prévient les satellites à
l'avance. Par exemple, une fois informés d'un changement proche, les
routeurs peuvent annoncer une métrique très élevée pour les ISL qui
vont bientôt être coupés, comme on le fait sur les réseaux
terrestres quand une maintenance est prévue. Il y a une proposition
concrète d'un mécanisme d'information dans le brouillon
draft-ietf-tvr-schedule-yang.
Quelques lectures recommandées par notre RFC :
