On Traffic Engineering and MPLS for Satellite Networks

This discussion is split into two broad parts:

1) The first part addresses Traffic Engineering as an instrument for optimizing the operational performance of networks and related core problems, discuss solutions in both connectionless and signalled approach, and point to topics for future research and development. Techniques such as multi-path routing, traffic splitting, constraint-based routing (CBR), path-protection etc. that are used for traffic engineering in contemporary Internet Service Provider (ISP) networks are discussed for both connection oriented ( e.g. MPLS ) and connectionless classes ( e.g., distance-vector and link-state algorithms, routing metrics etc.).

2) The second part addresses traffic engineering aspects of MPLS for Satellite Networks. The large-area coverage at efficient infrastructure costs makes satellite networks attractive from a provider’s point of view. However, communication suffers in case of geostationary (GEO) satellites from high free space attenuation, latency and link budgeting criteria. In contrast, Low Earth Orbit (LEO) satellites with their lower latency and link budgets and less free space loss offers better promises for an high efficiency solution. Advantages of MPLS such as forwarding based on exact match of fixed length labels, integration of ATM and IP technologies, traffic engineering and QoS routing, conveniently separated routing and forwarding networks etc. suggests that it can implemented over satellite links to guarantee required QoS service levels. In the past Asynchronous Transfer Mode (ATM) have been considered for dynamic or fixed satellite network topologies for reliable and robust traffic engineering methods. Connectionless IP protocol demands implementation of IP Quality of Service (QoS) architecture [Integrated Service (IntServ) or Differentiated Service (DiffServ)] to provide the required QoS, but does not satisfy mechanisms for traffic engineering as compared ATM. Multiprotocol Label Switching (MPLS), on the other hand, allows adoption of new parameters for conventional IP traffic by decoupling packet forwarding from the information carried in the IP header. This section discusses proposals for IntServ, DiffServ, and MPLS based new QoS architectures for satellite based IP networks.

Note: Would having three Geostationary satellites, rule out the need for MEO Satellite/s to cover Polar surface data? It is a known fact that three Geostationary satellites are sufficient for covering entire earth surface, but do they cover the Polar surfaces too?

Answer: No they don't. Due to its high altitude (approx. 36000 km), one GEO spacecraft caters for approximately one- third of the earth surface. As such, 3 equally-spaced GEO satellites should provide full coverage of the earth BUT with the exception of the polar regions. The polar regions will not be covered in this case. GEO satellites are advantageous because of the few numbers of ground stations that are needed to handle their signals since they move at the same pace as the earth. On the other hand, their costs are high and GEO satellites have some limitations when applied to telephony: the long signal paths offer challenges in terms of signal propagation delay (about 260 ms of round-trip propagation time) which is significant. Also, due to power restrictions, it is not possible to provide a direct satellite connection for handheld mobile phones.

In contrast, the Middle-Earth Orbit (MEO) satellites are 5000 to 12000 km high and have round-trip delays of about 100 ms. For global coverage number of satellies required varies with altitude of the system. LEO/MEO satellites grouped into constellations move at a different pace than the earth and as such, it is necessary to provide a larger number of ground stations, but the number of satellites in their reach varies with time. For an example of diagrams and work on MEO satellite system and its effective data handling, the following paper by Dittberner et. al. is referred: http://www.eumetsat.int/Home/Main/Publications/Conference_and_Workshop_Proceedings/groups/cps/documents/document/pdf_conf_p48_s1_09_dittbern_v.pdf


[ material from above submitted to & accepted by MPLS 2008: http://www.isocore.com/mpls2008/program/technical_sessions.htm]