Content uploaded by Anton Donner
Author content
All content in this area was uploaded by Anton Donner on Oct 09, 2017
Content may be subject to copyright.
An MPLS Networking Concept for Satellite Constellations
Anton Donner, Matteo Berioli and Markus Werner
German Aerospace Center (DLR)
Institute of Communications and Navigation, Oberpfaffenhofen
82234 Weßling, Germany
MPLS has been designed for IP backbone networks and offers many possibilities to
exert influence on traffic flows. Therefore it is an attractive candidate for use in broadband
non-geostationary satellite constellations with their continuously changing topologies. The
logical structure of an MPLS domain with its ingress, egress and core routers has to be
mapped onto the elements of the satellite network, and special attention has to be paid
to route computation in order to fulfill user Quality of Service (QoS) requirements.
A general MPLS-based networking concept for satellite networks is developed and diffe-
rent possible scenarios considering the particularities and constraints of satellite networks
are discussed. As route computation and performance is crucial, an analytical estimation
of routing effort is deduced and numerical results are presented.
1. INTRODUCTION
There are compelling reasons to develop non-geostationary satellite constellations in-
stead of their geostationary counterparts as they offer smaller latency, lower free space
loss, truly global coverage and better reuse of available ground-space communication fre-
quencies. Earlier work on constellations with Intersatellite Links (ISLs) has shown that
Asynchronous Transfer Mode (ATM)-based operation can provide QoS guarantees and
powerful traffic engineering methods in a dynamic topology environment due to its virtu-
al path/virtual channel concept [1].
In order to provide comparable performance and features when moving towards the
connectionless IP world, this imposes to think about a connection-oriented solution for
future IP-based core networks. Multiprotocol Label Switching (MPLS) seems to be an
interesting candidate to bridge this gap: it allows to adopt new paradigms for conventional
IP traffic by decoupling packet forwarding from the information carried in the IP header.
This paper is organized as follows. Section 2 provides a brief introduction to dynamic sa-
tellite constellation networks and rerouting problems. A general MPLS-based networking
concept for dynamic satellite constellations is presented in Sec. 3, and three implementa-
tion scenarios are discussed in more detail, focusing on their respective advantages and
drawbacks. As routing performance turns out to be of key significance, a generic analytical
estimation of (re)routing effort in this particular environment is deduced in Sec. 4, and
some numerical results are presented under reference assumptions. A short summary and
an outlook on future research work concludes the paper.
0
1 2
3
4 5
6
7
8
9
10
11
12 13
14
15 16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32 33
34
35
36
37
38
39
40
41
42
43 44
45
46 47
48
49
50
51
52
53
54
55
56
57
58
59
60 61
62
63 64
65
66
67
68
69
70
71
-180 -150 -120 -90 -60 -30 0 30 60 90 120 150 18
0
-90
-60
-30
0
30
60
90
Longitude [deg]
Latitude [deg]
Figure 1. M-Star ISL topology; solid lines, intra-orbit ISLs; dashed lines, inter-orbit ISLs.
2. FUNDAMENTALS OF SATELLITE CONSTELLATION NETWORKS
2.1. Basics of Dynamic Satellite Constellation Networks
In developing an MPLS-based networking concept for satellite constellation networks
it is first necessary to recall their relevant features setting the framework and particular
challenges; among these, the most obvious is the twofold dynamics of the network: first,
variations within the ISL topology, and second, dynamics of the whole ISL network with
respect to served ground users.
Earlier studies on the routing in ISL networks of polar or near-polar star pattern con-
stellations (like Iridium) have clearly identified the seam between counter-rotating orbits
and the on/off-switching of its inter-orbit ISLs as two fundamental drawbacks for the
connection-oriented operation. This has stimulated the investigation of moderately incli-
ned delta pattern constellations employing ISLs. It was shown that such constellations
generally provide the possibility to set up a number of inter-orbit ISLs that can be main-
tained permanently with acceptable pointing, acquisition and tracking requirements; such
link permanence is particularly important for optical ISLs, which seems to be the most
promising technology for future broadband systems. Moreover, permanence of physical
ISLs is in general a desirable feature in the light of real-time connection-oriented ser-
vices, as path switching can be completely reduced to cases where it is inevitable due to
handover of the satellites serving the ground users.
M-Star was one of the first commercial system proposals aiming at the promising combi-
nation of a delta pattern constellation and optical ISLs. The M-Star constellation consists
of 72 satellites evenly distributed in 12 orbit planes; the snapshot of the whole resulting
ISL topology is displayed in Fig. 1. It is important to note that a completely regular and
permanent topology is achieved where ISLs are always available, only the inter-orbit type
links introduce a link delay variation over time. However, the major challenge for any
connection-oriented networking approach remains the inevitable relative movement bet-
ween the satellite network and served ground users, which accounts for permanent forced
satellite handovers.
2.2. Rerouting in Dynamic Topologies
One key issue for a continuously changing topology is rerouting of existing traffic paths.
Both label distribution protocols, RSVP-TE and CR-LDP, already provide two mecha-
nisms for this purpose: fast rerouting and make-before-break.
Fast rerouting is a technique developed for setting up backup paths for failure protection
of links, nodes or complete network segments. It is very expensive in terms of resource
reservation and is normally only used in case of very strict reliability requirements.
The idea behind make-before-break is to set up a new Label Switched Path (LSP) in
parallel to the still existing old LSP due to topology or traffic variations. The protocols
avoid unnecessary double reservations of bandwidth on commonly used links as normally
the two links are used one after the other and not simultaneously. In case of an explicitly
routed LSP it is of course up to the ingress Label Edge Router (LER) to set up the
alternative LSP. Throughout this paper, make-before-break rerouting is assumed, and
without further consideration it is anticipated that non-disruptive operation of end user
connections is guaranteed by a proper mechanism, e.g. [2], that aligns the packet streams
flowing on the old and new LSPs, respectively.
3. MPLS NETWORKING CONCEPT FOR DYNAMIC SATELLITE CON-
STELLATIONS
In this section we bring together the two worlds of MPLS networking and satellite con-
stellations with a dynamic ISL core network. We first define the appropriate boundaries
of the satellite MPLS network, then move on to describing the overall networking con-
cept discussing its main functionalities, and finally present three possible implementation
scenarios comparing their advantages and drawbacks.
3.1. Network Boundaries
As already explained, the dynamic scenario is dominated by inevitable, regular and
frequent handovers between ground stations and serving satellites, which are both network
nodes. This characteristic raises the question where to set the boundaries of the MPLS
network most reasonably.
A first option is that those satellites serving ground stations could be considered as
LERs; this would restrict the MPLS backbone network completely to the ISL space
segment, which has a permanent topology and could thus in principle be operated wi-
thout stringent LSP rerouting requirements. However, since LERs initiate LSP setups
and perform route computation in special scenarios, placing them ‘in the sky’ would
mean notable on-board processing load. Leaving the satellites as simple Label Switching
Routers (LSRs), we must place the LERs (and the network boundaries) on ground and
the critical earth-satellite links fall inside the MPLS network. Frequent link handovers
then imply continuous rerouting decisions and computations for the LSP.
It should be noted, however, that rerouting has to be performed in both cases, but there
is a conceptual difference: in the former case of satellite LERs, the ground station may
trigger a systematic handover from an old to a new serving satellite (LER) by asking to
tear down the active LSP (from the old satellite) and sending a new LSP setup request to
the new satellite; consequently, a new phase of LSP activation begins with its related QoS
negotiation and its admission control. This is not required in the case of ground LERs,
Network State
motion of
constellation
Route
Computation
LSP Rerouting /
Creation /
Release
Ingress LER
(scenario 1 & 2) Central Station
(scenario 3)
topology (edges, nodes)
used / reserved bandwidth
changing link delay
•
•
delay
network utilization
•
•
CSPF
MIRA
optimization for e.g.
different algorithms, e.g.
User Behavior /
QoS Requirements
•
•
•
•
•
setup / release request
bandwidth
tolerated delay
priority
source / destination
Figure 2. Functional blocks and their interrelation for MPLS-based networking in dynamic
satellite constellations.
for the attributes of the already active LSP are further valid.
In conclusion, there are no worthwhile advantages to implement LER functionalities
on-board, whereas with ground LERs there is no need to re-start a QoS negotiation or
admission control for LSP rerouting due to satellite handover, and, secondly, expensive
and complex on-board processing for advanced routing functionality is avoided.
3.2. Overall Concept: Functionalities
In a systematic top-down approach, all relevant components can be assigned to four
main functional blocks:
1. Network State including in particular monitoring and state information distribution;
2. User Behavior/QoS Requirements making up the demand;
3. Route Computation as the key block comprising ‘intelligence’ in terms of traffic
engineering, adaptiveness and/or optimization;
4. LSP Rerouting/Creation/Release establishing the result of ‘route computation’.
The distribution of network state information is usually performed through link state
protocols (such as Open Shortest Path First (OSPF) or IS-IS). In the ISL network scenario,
relevant state information comprises link availability, capacity, available bandwidth after
resource allocation, and delay (if not calculated on demand, or pre-calculated and kept
in memory, as the topology is periodically deterministic); additionally, the state of active
LSPs to perform proper rerouting.
‘Route computation’ deals with QoS negotiation, admission control and traffic enginee-
ring issues. An LSP request is formulated including particular constraints that have to
be respected by the computed path. This module evaluates all incoming requests, checks
whether the satellite network is able to host the requested LSPs, calculates the routes and
gives the authorization to set up the paths. Constraint-based routing is usually performed
as optimization with respect to a scalar metric, and may be implemented using one of
several proven algorithms where the choice depends on the particular set of optimization
metric and constraints.
An important aspect is the frequency of route re-computations (see Sec. 4). One option
is that a route is only calculated once after a setup request and each LSP would then stick
to this route until a handover between ground and serving satellite causes a re-computa-
tion. Alternatively routes could be re-computed periodically, which may prove useful in
the considered dynamic scenario with continuously changing network state. Better routes
may become available for already existing paths, resulting in a network performance gain.
However this must be thoroughly traded off versus an increase in both computational
effort and signaling load due to label distribution.
In the remainder of this section, we now focus on the question where routing functio-
nality should be physically implemented in the network.
(a) Distributed routing and LSP
management
(b) Centralized routing, distribu-
ted LSP management
(c) Centralized routing and LSP
management (dedicated logical
connections)
Figure 3. MPLS networking concept: candidate implementation scenarios.
3.3. Scenario 1: Distributed Routing and LSP Management
A direct adaption of the terrestrial situation to the satellite network is shown in
Fig. 3(a). All LERs on ground and the LERs on-board the satellites maintain identi-
cal Link State Databases (LSDBs) representing the entire network state, and routes are
computed at the ingress points of the network. It is up to the ingress LER on ground
to initiate a setup of and switch-over to an alternative LSP according to the information
stored in its LSDB, and therefore it is crucial to receive continuous updates for the LSDB.
OSPF-TE uses opaque Link State Advertisements (LSAs) [3] and distributes much
more information than standard OSPF can do. Besides a traffic engineering metric the
routers know also about maximum (reservable/unreserved) bandwidth and can include
these constraints in their path computation. In order to avoid an excessive flooding of
the network with LSAs, a link attribute (e.g., bandwidth, which can vary quickly) may
have to cross a certain threshold before an update is sent, but all other link attributes are
distributed as well. Ongoing further developments try to avoid this unnecessary traffic by
distributing only incremental updates of single attributes without sending the complete
LSA, but again the whole network has to be flooded.
In spite of the improvements of OSPF for use with MPLS, a direct adaption of the
terrestrial scenario to the satellite network is abundantly questionable. The nodes are
not fixed and there is a continuously changing delay of the inter-orbit links which has to
be monitored and announced to all LSDBs. Moreover, the synchronization of the LSDBs
suffers from this changing inter-orbit satellite distance and the high signal propagation
delay caused by the earth enclosing size of the topology, too. It would be possible to avoid
OSPF traffic related to a change in link delay by pre-calculation in every node as the
constellation moves in a deterministic manner, but for reasonable traffic engineering it is
still necessary to distribute link state information.
3.4. Scenario 2: Centralized Routing – Distributed LSP Management
A more efficient traffic engineering can be performed only with a global view of the
network. For this it is necessary that each ingress LER trying to access the network
sends the traffic parameters (traffic category, bandwidth, etc.) to a central database,
which has total knowledge of the network state and computes an optimum route for
the incoming request. Then the central database answers with a message containing the
Explicit Route (ER) for an LSP which the ingress LER has to create itself. In parallel
the central LSDB may send new ERs for existing LSPs to other ingress LERs in order to
trigger handover events or to reroute traffic flows for a better network utilization.
This approach (see Fig. 3(b)) has two major advantages: first, satellites with their
typical constraints in computing power and memory do not have to maintain LSDBs and
perform route calculations, and second, the network utilization is increased drastically [4].
The drawbacks are the necessity of a new protocol exchanging information between ingress
LER and central LSDB and a more or less accurate knowledge of the ground stations’
coordinates. In scenario 1 the ground-stations only need information about visibility and
distance of satellites for determining alternative LSPs and the time to switch to the new
path. Scenario 2 however offers two possibilities regarding the time of rerouting: either the
central LSDB offers one or several alternatives for ERs and the decision when to start the
rerouting is completely up to the ground station (like in scenario 1), which then of course
has to tell the central LSDB again of what it did, or the ground station has to take the
new route directly after reception of the ER from the central LSDB. The former option
does not require detailed position information and is suitable for satellite constellations
with several visible satellites at the same time (satellite diversity), out of which the best
one is chosen, and the latter option is more appropriate for a small number of visible
satellites, but then the LSDB needs very accurate information about the ground stations’
locations to avoid routing errors.
3.5. Scenario 3: Centralized Routing and LSP Management
Further development of the centrally triggered LSP rerouting leads to the absolute
control scenario shown in Fig. 3(c). Here the ingress points of the network do not set
up LSPs any more; all nodes of the network get their tables for label swapping directly
from the central database. All decision are up to LSDB, but this approach has only
little remaining commonalities with terrestrial use of MPLS (e.g., the label swapping
mechanism).
One advantage of this approach is the faster installation of LSPs. The central LSDB
distributes label swapping tables among the satellites directly after the reception of a
setup request from one of the LERs (or of course due to handover or rerouting events).
Then it sends an acknowledgement back to the origin of the connection request and this
may immediately start to use the already existing LSP without having to set up one itself.
In case of handover or rerouting events, the procedure has to be carefully considered
with respect to synchronization requirements: all updated tables must start to be used
at the same time. A possible solution is to update all tables along the new LSP with the
ingress LER being the last node updated. A major drawback of this scenario is the design
of a new signaling protocol to distribute labels among the LSRs.
Both centralized scenarios (2 and 3) present scalability problems with respect to the
number of LSPs: the central station may only be able to handle up to a limited number of
them. This is a crucial point and is therefore (implicitly) addressed in the following when
we estimate the routing/rerouting effort required to maintain a certain number of LSPs.
4. ESTIMATION OF ROUTE COMPUTATION EFFORT
The effort which is spent in route computations for both LSP setup and rerouting is a
key performance parameter for the operation of a satellite MPLS network. Route compu-
tation effort may be measured in several ways and at different levels (e.g., related amount
of signaling, calls of the basic routing algorithm, elementary processor operations, ...).
Here we are interested in a simple general metric. For the scope of this paper, this is
the sheer number of LSP setup and rerouting occurrences, and more specifically, just its
(long-term) time average value for the whole network. This selection is mainly motiva-
ted by two facts: first, for any more sophisticated metric this number would certainly
remain an important multiplicative factor; second, one single average value is a quick and
intuitive way to perform qualitative case studies – as needed at this initial stage of our
research – and to ‘compare at a glance’ complete global traffic scenarios and/or different
constellations.
In the following we first develop a generic analytical estimation approach. Subsequently,
a simple numerical example is presented and discussed to derive qualitative as well as first
quantitative conclusions that are indicative for the ongoing research work.
4.1. Analytical Model
As concluded in Sec. 3.1, we assume that LERs are located on ground and that all
satellites exclusively act as LSRs. Taking a queuing modelling approach, we further assume
that each ground LER receives requests to create LSPs according to a Poisson arrival
process. For the sake of notation simplicity we further consider λas the effective average
arrival rate and τas the effective average remaining time of the LSPs served by one
satellite, respectively, no matter if they actually originate from one or more LERs. One
could alternatively assume that all LSPs in a satellite always come from one fictive ground
LER only.
We now assume that the duration of an LSP itself (until it expires, not affected by
handover/rerouting) is negative exponentially distributed with an average LSP duration
of 1/µ.
Under the further assumption that all LSP requests can be accepted, the above cha-
racteristics hold for active or established LSPs in the satellite MPLS network. Thus our
system model is an M/M/∞queuing system: the service time (LSP duration) doesn’t
depend on the number of users (active LSPs) inside the system. The rate at which LSPs
are torn down in one satellite, on the contrary, directly depends on the number of active
LSPs, and it can be shown [5] that the average number of users in the considered queuing
system is λ/µ, establishing equilibrium operation. In our case, we thus state the average
number of active LSPs in one satellite as Psat =λ/µ.
So far we have not taken into account that in the considered scenario satellites typically
serve ground LERs at all only during a certain share of time α,0≤α≤1, namely when
they are over populated areas, whereas they are “idle” over deserted regions and oceans.
Or equivalently, the average number of satellites serving ground stations, is Nserv =αN.
Now in the whole constellation there are N(N−1)/2 unordered origin-destination (OD)
satellite pairs. As we are looking at unidirectional LSPs established between pairs of satel-
lites, we would start to consider N(N−1) ordered OD pairs with potentially established
LSPs. Following our earlier terminology and considerations, the average number of orde-
red ‘active’ OD pairs would amount to Nserv(Nserv −1), and thus αN(αN −1). In other
words, in the average each of the αN active satellite shares its Psat active paths with
αN −1 partner satellites. Thus the average number of active LSPs for a given OD pair is
POD =Psat
1
αN −1=λ
µ
1
(αN −1).(1)
With 1/τ being the average handover rate – for both LERs and LSPs according to our
earlier assumptions – and assuming completely uncorrelated handover occurence in the
corresponding source and destination satellites, the handover rate for one single LSP is
simply the sum of the handover rates of its source and destination satellites, rLSP =2/τ,
and with (1) the LSP handover rate for each OD pair becomes
rOD =rLSP POD =2
τ
λ
µ
1
(αN −1).(2)
Finally, multiplication of this value with the average number of ordered ‘active’ OD
pairs gives us the average LSP handover rate for the whole network:
rnet =αN(αN −1)rOD =αN(αN −1) λ
µ
1
(αN −1)
2
τ=2αNλ
µτ .(3)
Finally, the transition back to route computation effort in the network is straightforward
due to the chosen simple metric for the latter, namely average number of (re)routing
occurences per time unit. The rerouting effort Rrer per time unit is simply identical with
the average LSP handover rate in the network as given in (3), and the routing effort
related to setup of new LSPs, Rnew per time unit, is just the product of their arrival rate
per satellite λwith the average number of active satellites, αN. Thus the total network
route computation effort becomes
Rnet =Rnew +Rrer =αNλ +2αNλ
µτ .(4)
4.2. Qualitative and Numerical Discussion
In the following we assume α,Nand τas fixed values reflecting the dynamic constel-
lation considered. λand µare the two parameters of interest. First of all, Rnet increases
with both λand 1/µ, i.e., routing effort increases when LSP requests come more often
and when requested LSP durations get longer.
Table 1
Network route computation effort Rnet for selected combinations of λand µ.Thenumber
of active LSPs per satellite is constant, Psat =λ/µ = 600.
λ1/s1/10 s 1/min 1/h
1/µ 10 min 100 min 10 h 600 h
Rnet[1/s] 30 + 60 3 + 60 0.5+60 0.0083 + 60
More specifically, the routing effort related to setup of new LSPs, Rnew,ofcourse,de-
pends only on their arrival rate λ, whereas the rerouting effort Rrer, on the other hand,
depends on the average number of active LSPs, λ/µ, because they remain in the constel-
lation during handovers.
Let us also state the following two indicative results from (4), concerning the relative
contributions from LSP setup and LSP rerouting:
•the rerouting effort is smaller than the setup effort if the average LSP duration
remains below half the average time till handover,
αNλ > 2αNλ
µτ ⇒1
µ<τ
2;(5)
•the rerouting effort becomes completely dominating (and the setup effort negligible)
if the average LSP duration is much larger than half the average time till handover,
1
µτ
2⇒Rnet ≈2αNλ
µτ .(6)
Now consider that realistic values of τin satellite constellations are in the order of
tens of minutes, whereas LSPs in MPLS networks certainly last much longer if applied in
typical fashion. Thus, in satellite constellation networks employing MPLS, the rerouting
effort can be expected to be dominating – unlike in terrestrial MPLS networks. This fact
raises the importance of research into highly efficient LSP rerouting mechanisms for the
satellite scenario.
Regarding the scalability problem of a centralized approach, from (6) one can see that
the rerouting effort increases linearly with the number of active LSPs, and a similar
behavior can be expected for the amount of signalling.
Let us finally adopt some reference values to perform a small numerical case study. We
fix the constellation related values as N= 72 (M-Star), τ= 600 s, and α=0.42 (ap-
prox. the share of the earth’s landmasses) and let λand µvary. For a given constellation,
we want to see what happens if incoming traffic changes its characteristics, namely the
average rate of incoming LSP requests, λ, and the average requested LSP duration, 1/µ.
The numerical results are summarized in Table 1 and in Fig. 4. They impressively
confirm the above qualitative considerations. In particular, Fig. 4(b) illustrates how the
route computation effort asymptotically approaches the value set in (6) when rerouting
becomes dominating.
00.2 0.4 0.6 0.8
1
0
100
200
300
400
500
600
0
500
1000
1500
2000
2500
3000
3500
4000
λ [1/s]
1/µ [min]
Rnet [1/s]
λ/µ = 600
(a) ‘Full’ range, up to large numbers of active LSPs
Psat
00.2 0.4 0.6 0.8
1
0
100
200
300
400
500
600
60
65
70
75
80
85
90
λ [1/s]
1/µ [min]
Rnet [1/s]
λ/µ = 600
(b) Focus on the considered numerical example of
Psat = 600.
Figure 4. Route computation effort (Rnet). The circles denote the values in the first three
columns of Table 1.
5. CONCLUSION
This work has focused on an MPLS networking concepts and on the estimation of si-
gnaling traffic for dynamic satellite constellation networks. Offering rerouting capabilities,
MPLS is well suited for use in dynamic topologies. The key for sensible traffic enginee-
ring in terms of QoS guarantees and network utilization is centralized route calculation
(scenarios 2 and 3) which benefits a lot from periodicity and regularity of Walker delta
constellations.
As routing performance is particularly crucial in the considered dynamic network topo-
logy, a generic analytical estimation of route computation effort has been developed. The
approach allows to derive qualitative as well as initial quantitative conclusions that are
indicative for the ongoing research work. It has been demonstrated that LSP rerouting
effort tends to be dominating over LSP setup effort in dynamic satellite networks. Future
research work will therefore focus on efficiency and optimization of rerouting algorithms
and performance.
REFERENCES
1. M. Werner, J. Frings, F. Wauquiez, G. Maral, Topological design, routing and capa-
city dimensioning for ISL networks in broadband LEO satellite systems, Int. J. Sat.
Commun. 19 (6) (2001) 499–527.
2. B. Edmaier, J. Ebersp¨
acher, W. Fischer, A. Klug, Alignment server for hitless
path-switching in ATM networks, in: Proc. XV International Switching Symposium
(ISS ’95), Berlin, Germany, 1995, pp. 403–407.
3. R. Culton, The OSPF opaque LSA option, RFC 2370 (Apr. 1998).
4. G. Haßlinger, S. Schnitter, How service providers can profit from traffic engineering,
in: Proc. EURESCOM Summit 2002, VDE, Heidelberg, Germany, 2002.
5. L. Kleinrock, Queuing Systems, John Wiley and Sons, Inc., 1976.
