ETSI TS 102 856-1 V1.1.1 (2011-07)

Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia (BSM); Multi-Protocol Label Switching (MPLS) interworking over satellite Part 1: MPLS-based Functional Architecture

DTS/SES-00306

General Information

• Status: Published
• Publication Date: 26-Jul-2011
• Technical Committee: SES BSM - SES Broadband Satellite Multimedia
• Current Stage: 12 - Completion
• Due Date: 24-Aug-2011
• Completion Date: 27-Jul-2011

Standards Content (Sample)

Technical Specification
Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM);
Multi-Protocol Label Switching (MPLS)
interworking over satellite;
Part 1: MPLS-based Functional Architecture

2 ETSI TS 102 856-1 V1.1.1 (2011-07)

Reference
DTS/SES-00306
Keywords
architecture, broadband, IMS, internet,
interworking, IP, MPLS, multimedia, satellite
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 856-1 V1.1.1 (2011-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 General . 10
4.1 BSM . 10
4.1.1 BSM Functional Architecture . 10
4.1.2 BSM QoS Architecture . 10
4.1.3 BSM Traffic Classes . 10
4.2 MPLS . 11
4.2.1 MPLS Objectives . 11
4.2.2 MPLS Signalling . 11
4.2.3 MPLS QoS Issues . 11
4.2.4 MPLS Traffic Engineering . 12
4.2.5 MPLS Encapsulation . 12
4.2.6 MPLS VPNs . 13
4.3 Functional Requirements . 13
5 MPLS/BSM Functional Architecture . 13
5.1 Scenario A: Full Interworking of MPLS . 14
5.1.1 Network Architecture . 14
5.1.2 Protocol Stack . 17
5.1.3 QoS Provisioning . 19
5.1.3.1 BSM Traffic Classes . 19
5.1.3.2 DiffServ . 20
5.1.3.3 IntServ . 21
5.1.4 Traffic Engineering . 21
5.1.5 Resiliency . 22
5.2 Scenario B: Interworking Using IP Tunnel s . 23
5.2.1 Network Architecture . 24
5.2.2 Protocol Stack . 25
5.2.3 QoS Provisioning . 25
5.2.4 Traffic Engineering . 26
5.2.5 Resiliency . 26
6 MPLS/BSM-Specific Functional Elements . 26
6.1 LSR/ST . 26
6.2 LSR/Hub . 27
6.3 LSR/GW . 27
6.4 LSR/OBP-Sat . 27
Annex A (informative): Use Cases . 28
A.1 MPLS Network using Scenario A1 . 28
A.2 MPLS Network using Scenario B1 . 29
A.3 MPLS Network using Scenario A2 . 29
A.4 MPLS VPN using Scenario A1 . 30
ETSI
4 ETSI TS 102 856-1 V1.1.1 (2011-07)
Annex B (informative): MPLS Transport Profile . 32
Annex C (informative): Bibliography . 33
History . 34

ETSI
5 ETSI TS 102 856-1 V1.1.1 (2011-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and
Systems (SES).
The present document is part 1 of a multi-part deliverable covering the issues related to the use of MPLS
(Multi-Protocol Label Switching) in "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM)", as identified below:
Part 1: "MPLS-based Functional Architecture";
Part 2: "Negotiation and management of MPLS labels and MPLS signalling with attached networks".
Introduction
Multi-protocol Label Switching (MPLS) is employed today as a solution for delivering quality of service (QoS) on
IP-based terrestrial networks by providing QoS-based routing of IP traffic, among other advanced capabilities.
Compatibility between the BSM and MPLS networks should be an essential feature, for example to provide extensions
and interconnectivity to terrestrial MPLS networks and/or a satellite back-up for terrestrial MPLS networks.
The ability to support MPLS efficiently and in a standardised manner over a BSM network forms the core rationale for
the present document. This work on MPLS and QoS is independent of, but complementary to, the existing BSM
specifications on QoS, in particular TS 102 463 [5] and TS 102 464 [6].
ETSI
6 ETSI TS 102 856-1 V1.1.1 (2011-07)
1 Scope
The present technical specifications extend and complement the existing BSM QoS functional architecture to enable
transport of MPLS signalling and data flows over a BSM network in a way such that MPLS networks connected by
different STs can communicate as if they were connected by standard terrestrial LSRs (label switching routers).
The present document forms part 1 of this multi-part deliverable. It defines the main architectural concepts, including
the network architecture and protocol stacks, and outlines the key QoS, traffic engineering and resiliency provisions.
Several architecture variants are defined and their main characteristics are analysed, also taking into account three
different BSM network types.
An Annex sketches a set of use cases that illustrate different application and configuration scenarios of the present
specifications.
In a separate document, TS 102 856-2 [11], the detailed procedures in BSM network entities and related signalling
issues are addressed. A particular focus is placed on the fully integrated MPLS/BSM architecture as defined in the
present document.
The setup of multicast MPLS paths is considered out of scope of this multi-part deliverable.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 292: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM) services and architectures; Functional architecture for IP interworking with BSM
networks".
[2] ETSI TS 102 295: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM) services and architectures; BSM Traffic Classes".
[3] ETSI TS 102 357 (V1.1.1): "Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM); Common Air interface specification; Satellite Independent Service Access
Point SI-SAP".
[4] ETSI TS 102 462: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); QoS Functional Architecture".
[5] ETSI TS 102 463: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Interworking with IntServ QoS".
[6] ETSI TS 102 464: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Interworking with DiffServ Qos".
[7] ETSI TS 102 672: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Management Functional Architecture".
ETSI
7 ETSI TS 102 856-1 V1.1.1 (2011-07)
[8] ETSI TS 102 673: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Performance Parameters".
[9] ETSI TS 102 675-1: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Part 1: Performance Management at the SI-SAP".
[10] ETSI TS 102 675-2: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Part 2: Performance Management Information Base".
[11] ETSI TS 102 856-2: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Multi-Protocol Label Switching (MPLS) interworking over satellite; Part 2: Negotiation
and management of MPLS labels and MPLS signalling with attached networks".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 101 984: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Services and architectures".
[i.2] IETF RFC 1633: "Integrated Services in the Internet Architecture: an Overview".
[i.3] IETF RFC 2205: "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification".
[i.4] IETF RFC 2210: "The Use of RSVP with IETF Integrated Services".
[i.5] IETF RFC 2702: "Requirements for Traffic Engineering over MPLS".
[i.6] IETF RFC 2983: "DiffServ and Tunnels".
[i.7] IETF RFC 3107: "Carrying Label Information in BGP-4".
[i.8] IETF RFC 3031: "Multiprotocol Label Switching Architecture".
[i.9] IETF RFC 3209: "RSVP-TE Extensions to RSVP for LSP Tunnels".
[i.10] IETF RFC 3270: "MPLS Support of Differentiated Services".
[i.11] IETF RFC 3564: "Requirements for Support of Differentiated Services - aware MPLS Traffic
Engineering".
[i.12] IETF RFC 3630: "Traffic Engineering Extensions to OSPF Version 2".
[i.13] IETF RFC 4023: "Encapsulating MPLS in IP or GRE".
[i.14] IETF RFC 4090: "Fast Reroute Extensions to RSVP-TE for LSP Tunnels".
[i.15] IETF RFC 4124: "Protocol Extensions for Support of DiffServ-aware MPLS Traffic Engineering".
[i.16] IETF RFC 4271: "A Border Gateway Protocol 4 (BGP-4)".
[i.17] IETF RFC 4364: "BGP MPLS IP VPNs".
[i.18] IETF RFC 4577: "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs".
[i.19] IETF RFC 5036: "LDP Specification".
[i.20] IETF RFC 5586: "MPLS Generic Associated Channel".
[i.21] IETF RFC 5654 - Requirements of an MPLS Transport Profile".
[i.22] IETF RFC 5860: "Requirements for Operations, Administration, and Maintenance (OAM) in
MPLS Transport Networks".
[i.23] IETF RFC 5921: "A Framework for MPLS in Transport Networks".
ETSI
8 ETSI TS 102 856-1 V1.1.1 (2011-07)
[i.24] IETF RFC 5950: "Network Management Framework for MPLS-based Transport Networks".
[i.25] IETF RFC 5960: "MPLS Transport Profile Data Plane Architecture".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
architecture: abstract representation of a communications system
NOTE: Three complementary types of architecture are defined:
� Functional Architecture: the discrete functional elements of the system and the associated logical
interfaces.
� Network Architecture: the discrete physical (network) elements of the system and the associated
physical interfaces.
� Protocol Architecture: the protocol stacks involved in the operation of the system and the
associated peering relationships.
BSM network: BSM subnetwork together with the BSM interworking and adaptation functions that are required to
provide IP interfaces (i.e. layer 3 and below) to attached networks
BSM subnetwork: all the BSM network elements below the Satellite Independent Service Access Point (SI-SAP)
control plane: plane that has a layered structure and performs the call control and connection control functions; it deals
with the signalling necessary to set up, supervise and release calls and connections
label switched path: path through one or more LSRs at one level of the hierarchy followed by a packets in a particular
FEC
NOTE: This definition is taken from RFC 3031 [i.8].
label switching router: MPLS node which is capable of forwarding native L3 packets
NOTE: This definition is taken from RFC 3031 [i.8].
MPLS label: label which is carried in a packet header, and which represents the packet's FEC
NOTE: This definition is taken from RFC 3031 [i.8].
MPLS node: node which is running MPLS
NOTE 1: An MPLS node will be aware of MPLS control protocols, will operate one or more L3 routing protocols,
and will be capable of forwarding packets based on labels. An MPLS node may optionally be also
capable of forwarding native L3 packets.
NOTE 2: This definition is taken from RFC 3031 [i.8].
multi-protocol label switching: IETF working group and the effort associated with the working group
NOTE: This definition is taken from RFC 3031 [i.8].
user plane: plane that has a layered structure and provides user information transfer, along with associated controls
(e.g. flow control, recovery from errors, etc.)
ETSI
9 ETSI TS 102 856-1 V1.1.1 (2011-07)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
BA Behaviour Aggregate
BGP Border Gateway Protocol
BSM Broadband Satellite Multimedia
CE Customer Edge
DiffServ Differentiated Services
DS Differentiated Services
DSCP DiffServ Code Point
E-LSP Explicitly TC-encoded PHB Scheduling Class
FEC Forwarding Equivalence Class
GRE Generic Routing Encapsulation
GW Gateway
HTTP Hypertext Transfer Protocol
IETF Internet Engineering Task Force
IntServ Integrated Services
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
L1 Layer 1
L2 Layer 2
L3 Layer 3
LAN Local Area Network
LER Label Edge Router
L-LSP Label-Only-Inferred PHB Scheduling Class
LSA Link State Advertisement
LSP Label Switched Path
LSR Label Switching Router
MPLS Multi-Protocol Label Switching
NCC Network Control Centre
NMC Network Management Centre
NMS Network Management System
OAM Operations, Administration, and Maintenance
OBP On-Board Processing
OPEX Operating Expense
OSPF Open Shortest Path First
PE Provider Edge
PHB Per-Hop Behaviour
PSC PHB Scheduling Class
QID Queue Identifier
QoS Quality of Service
RSM Regenerative Satellite Mesh
RSVP Resource Reservation Protocol
SD Satellite Dependent
SDU Service Data Unit
SI Satellite Independent
SI-SAP Satellite Independent Service Access Point
ST Satellite Terminal
TC Traffic Class
TE Traffic Engineering
TP Transport Profile
TSM Transparent Satellite Mesh
TSS Transparent Satellite Star
VoIP Voice over IP
VPN Virtual Private Network
ETSI
10 ETSI TS 102 856-1 V1.1.1 (2011-07)
4 General
This clause identifies and briefly sketches the core technologies that need to be brought together to define an integrated
MPLS/BSM architecture.
4.1 BSM
ETSI's Working Group SES BSM has made substantial progress over the past decade in defining an IP-based BSM
network. Among the technical specifications and reports generated by the WG, TS 102 292 [1] (Functional Architecture
for IP Interworking with BSM Networks) and TS 102 462 [4] (QoS Functional Architecture) are especially relevant for
the present purposes.
4.1.1 BSM Functional Architecture
TS 102 292 [1] introduces a satellite-independent service access point, the SI-SAP interface. This interface provides the
higher-layer BSM functions inside the satellite terminal with a service access point for the lower layer
(satellite-specific) functions. It allows the BSM protocols developed in the satellite-independent layer (above SI-SAP)
to perform over any BSM family. Moreover, the SI-SAP enables the use of standard Internet protocols directly over the
BSM or with minimal adaptation to BSM physical characteristics. Any BSM functions that are required in the satellite-
independent layer should be introduced without impacting Internet protocols, ideally via proxies or dedicated (protocol)
managers. A detailed specification of the SI-SAP interface is provided in TS 102 357 [3].
4.1.2 BSM QoS Architecture
Central to the QoS capability of a BSM network is the concept of QIDs (Queue Identifier). These represent abstract
queues that are defined at the SI-SAP for the purpose of transferring user data via the SI-SAP. The satellite dependent
layers are responsible for assigning satellite capacity to these abstract queues according to the specified queue
properties (e.g. QoS and forwarding behaviour). QIDs may be assigned statically (e.g. by management configuration) or
dynamically using specific resource reservation and signalling procedures. A QID is assigned at the time when the
associated queue is opened. An open queue is uniquely identified by the associated QID; in particular, the QID is used
to label all subsequent data transfers via that queue. It is important to note that QIDs have only local significance at the
respective interface; QID values are not communicated to entities outside the ST.
The key issue with respect to QoS provision in BSM networks concerns the mapping between QIDs and any QoS
parameters or application-specific parameters that may be present at higher layers (i.e. above SI-SAP). TS 102 462 [4]
does not specify such a mapping. Rather, it establishes the basic concepts to manage and control QID-related resources
and their mappings to resource requirements from higher layers. For these tasks, a client-server model is defined
whereby an ST QID resource manager is the client function to a centralised BSM QID manager (server) that has the
overall view of all BSM resources and their assignment status. QID resources can be allocated in a variety of ways,
including by static pre-configuration (via the management plane) or dynamically by control plane signalling and
subsequent requests across SI-SAP.
4.1.3 BSM Traffic Classes
Service providers are generally not interested in the specific QoS mechanisms or in numerically quantifying QoS
attributes, like maximum allowed delay or jitter, per application. Rather, it must simply be ensured that traffic entering
the BSM is characterised, sorted and processed according to its characteristic. For this purpose, TS 102 295 [2] (BSM
Traffic Classes) defines eight distinct traffic classes that capture and categorise the full spectrum of observed traffic
characteristics. By mapping each application to a suitable BSM Traffic Class it can thus be ensured that the
corresponding traffic receives the appropriate treatment by the BSM.
ETSI
11 ETSI TS 102 856-1 V1.1.1 (2011-07)
4.2 MPLS
4.2.1 MPLS Objectives
MPLS is an IETF mechanism (RFC 3031 [i.8]) that enables packet switched networks to operate more efficiently and
under greater control by the network operator. When MPLS was first introduced in the mid-1990's, the primary goal
was to provide new capabilities in IP routers to optimise overall traffic throughput and to categorise, separate and
process traffic for QoS differentiation. MPLS operates between the OSI layers 2 and 3, and introduces the concept of a
(unidirectional) Label Switched Path (LSP). Packet forwarding in MPLS enabled IP routers is achieved by means of an
MPLS label that is attached to each packet. The MPLS label is part of an MPLS header which is introduced between the
Layer 2 and 3 headers. It is important to note that an LSP is not characterized by a globally unique MPLS label; instead,
labels have only local significance at a specific interface, and MPLS routers are responsible for assigning the correct
label to each packet for the next hop.
Since its inception, MPLS has evolved significantly by adding new capabilities and integrating other IETF technologies.
Over the years, the focus has shifted from traffic engineering to efficient and manageable service delivery that enables
lower OPEX. MPLS is now probably the fastest growing technology for IP networking, both in terms of standardisation
as well as actual deployment in terrestrial networks.
For the purposes of the present document, the question arises as to which elements of MPLS are potentially beneficial
for BSM networks. Considering that well over 100 RFCs and active Internet Drafts currently exist, a careful reflection
on the scope of an integrated MPLS/BSM network is required. This must start by identifying and characterising the
major MPLS paradigms, as discussed in the following.
4.2.2 MPLS Signalling
Historically, MPLS was conceived as a mechanism to segregate IP traffic into distinct LSPs for QoS and traffic
engineering purposes. Different LSPs would carry different types of traffic which could receive dedicated handling and
forwarding by MPLS routers according to their priority. These LSPs can be established in different ways, including by
dynamic signalling or by management action. All packets that are placed on a given LSP are said to belong to the same
Forwarding Equivalence Class (FEC), and they receive the same treatment by the network.
Several techniques exist to generate, store and distribute MPLS labels, depending on the field of application and desired
capability. The Label Distribution Protocol (LDP, see RFC 5036 [i.19]) is a simple protocol by which LSRs inform
each other of the label bindings they have made to forward packets along LSPs. Here LSPs are instantiated
automatically according to the underlying routing information available in IP routers. To allow for a more flexible LSP
placement, RFC 3209 [i.9] (RSVP-TE: Extensions to RSVP for LSP Tunnels) extends RSVP (RFC 2205 [i.3]) by
introducing traffic engineering capabilities. In that context, LSPs are referred to as "LSP tunnels." Finally, for MPLS
applications involving VPNs, RFC 3107 [i.7] (Carrying Label Information in BGP-4) specifies a way in which MPLS
labels can be distributed using the standard routing protocol BGP-4 (RFC 4271 [i.16]).
4.2.3 MPLS QoS Issues
As regards the support of QoS in MPLS networks, an obvious approach is to simply send QoS-sensitive traffic over
dedicated, traffic-engineered LSP tunnels whose participating LSRs exhibit the desired pre-arranged forwarding
behaviour. The issue here is how to manage such a QoS provision on a large scale. One approach would be to adopt the
Internet Integrated Services (IntServ) framework and apply RFC 2210 [i.4] (The Use of RSVP with IETF Integrated
Services). However, due to the well-known inherent drawbacks of IntServ, that approach has not gained much support.
Instead, the IETF has devoted a considerable amount of effort to integrating and adapting the DiffServ approach for use
in MPLS. RFC 3270 [i.10] (MPLS Support of DiffServ) defines a flexible solution for supporting DiffServ over MPLS
networks, thus allowing the MPLS network administrator to select how DiffServ Behaviour Aggregates (BAs) are
mapped onto LSPs. A BA denotes the set of IP packets that require the same DiffServ behaviour, and therefore have the
same DSCP (DiffServ Code Point) marking in the IP header's 6-bit DS Field (which is part of the 8-bit former IPv4 ToS
field or the former IPv6 Traffic Class field). At each LSR, the DSCP is used to select the Per Hop Behaviour (PHB) that
determines the scheduling treatment and, in some cases, drop probability for each packet. Examples of common PHBs
are BE (Best Effort), CS (Class Selector), AF (Assured Forwarding), and EF (Expedited Forwarding), as listed e.g. in
Annex C of TS 102 464 [6] together with their associated DSCPs. Obviously, the total space available for DSCPs
(6 bits) greatly exceeds the number of useful PHBs, leaving considerable room for locally configurable (proprietary)
mappings.
ETSI
12 ETSI TS 102 856-1 V1.1.1 (2011-07)
Now, RFC 3270 [i.10] defines two types of approaches to employing fields of the MPLS shim header for PHB
encoding:
• E-LSP: In the E-LSP (Explicitly TC-encoded PHB Scheduling Class) LSP approach, the MPLS shim header's
3-bit TC field is used to indicate the packet's PHB, covering both information about the packet's scheduling
treatment and its drop precedence. Note that here the MPLS label determines only the forwarding behaviour,
and does not convey any QoS provisions. Also note that a PHB Scheduling Class (PSC) denotes a set of PHBs
for which packets must not be reordered.
• L-LSP: In the L-LSP (Label-Only-Inferred PHB Scheduling Class) LSP approach, an MPLS label is assigned
for each PHB scheduling class; the packet's drop precedence is conveyed in the MPLS TC field. In this
approach, the LSR thus determines both its forwarding and its scheduling behaviour from the MPLS label.
The E-LSP and the L-LSP approaches may co-exist in any given MPLS network.
4.2.4 MPLS Traffic Engineering
Traffic Engineering is concerned with performance optimisation of operational networks. RFC 2702 [i.5]
(Requirements for Traffic Engineering over MPLS) identifies the functional capabilities required to implement policies
that facilitate efficient and reliable network operations in an MPLS network. An important concept introduced in
RFC 2702 [i.5] is the MPLS traffic trunk. This is a unidirectional routable object that can be thought of as an
aggregation of traffic flows of the same class which are placed inside an LSP. An LSP can contain more than one traffic
trunk, and traffic trunks can be re-routed over another LSP. Furthermore, two LSPs between the same source and
destination may be load shared to carry a single traffic trunk. An LSP (or set of LSPs) that carries a traffic trunk is
sometimes referred to as a traffic engineered tunnel, or TE tunnel.
The routing of traffic trunks can occur via (RSVP-TE) signalling or via administrator action. In the latter case, the
resulting path is called an administratively specified explicit path. An administratively specified path can be completely
specified or partially specified.
Highlighting the interdependence between QoS and Traffic Engineering, RFC 3564 [i.11] (Requirements for Support of
DiffServ-aware MPLS Traffic Engineering) specifies the requirements for the support of Traffic Engineering in
DiffServ-aware MPLS networks. RFC 4124 [i.15] (Protocol Extensions for Support of DiffServ-aware MPLS Traffic
Engineering) addresses these requirements and defines the required protocol extensions. This includes extensions to
routing protocols and also to RSVP-TE signalling beyond those already specified in RFC 3209 [i.9] (RSVP-TE:
Extensions to RSVP for LSP Tunnels). Further extensions to RSVP-TE are specified in RFC 4090 [i.14] (Fast Reroute
Extensions to RSVP-TE for LSP Tunnels) to establish backup LSP tunnels for local repair of LSP tunnels.
4.2.5 MPLS Encapsulation
The core operation in MPLS networks is the forwarding of LSPs, and this operation is performed by MPLS enabled IP
routers. Since non-MPLS capable IP routers cannot interpret the MPLS shim header, such routers cannot forward LSPs.
However, it is possible to tunnel LSPs across a non-MPLS enabled IP network. This is done by means of MPLS
encapsulation, as defined in RFC 4023 [i.13] (Encapsulating MPLS in IP or GRE).
RFC 4023 [i.13] specifies two IP-based encapsulations:
a) MPLS-in-IP; and
b) MPLS-in-GRE.
In both cases, the outer, encapsulating protocol is IP. In encapsulation method (a), the MPLS packet is encapsulated
with an (outer) IP header, so that the resulting IP datagram can be treated by IP routers in the usual way. In
encapsulation method (b), the MPLS packet is first encapsulated with a GRE header, and the resulting packet is then
encapsulated with an (outer) IP header.
ETSI
13 ETSI TS 102 856-1 V1.1.1 (2011-07)
4.2.6 MPLS VPNs
The problem of how to deliver VPN solutions over IP networks has long been debated by the IP community, including
the MPLS Working Group. With RFC 4364 [i.17] (BGP MPLS IP VPNs), a stable MPLS-based solution is now
available which in fact extends MPLS into a new application area. RFC 4364 i.17 describes a method by which a
service provider uses an IP backbone to provide MPLS IP VPNs for its customers, i.e. the VPN providers. This method
uses a peer model, in which the customer's edge (CE) routers send their routes to the service provider's edge (PE)
routers. The provider network uses MPLS to tunnel customer packets across the IP backbone, and the CE-PE interface
is typically running BGP (RFC 4271 [i.16]). Later, in RFC 4577 [i.18] (OSPF as the Provider/Customer Edge Protocol
for BGP/MPLS IP VPNs), OSPF was allowed instead of BGP to facilitate that interconnection for some customers.
4.3 Functional Requirements
When considering the integration of MPLS capabilities with BSM networks, the following high-level functional
requirements are identified:
1) The integrated MPLS/BSM functional architecture should support all of the features of MPLS.
2) There shall be no requirement for modification of MPLS protocols (MPLS control and data transport), i.e.
MPLS should be interworked with no adaptation.
3) Any modifications to the BSM architecture should be as small as possible.
4) The documents should define a standard method of QoS mapping in order that a BSM network can provide an
appropriate level of QoS differentiation for MPLS transport.
5 MPLS/BSM Functional Architecture
This clause defines scenarios for integrated MPLS/BSM functional architectures. The common theme in all these
scenarios is that a terrestrial MPLS-based IP network is interconnected with a BSM network, thus enabling MPLS-
based traffic to enter the BSM network. The different scenarios introduced below are characterised by different degrees
of interworking and integration of MPLS and BSM entities, ranging from full interworking through no interworking.
Depending on the degree of interworking, the character of the MPLS traffic (e.g. in terms of QoS and traffic
engineering treatment) can be preserved to a larger or smaller extent. The three BSM network types TSS (Transparent
Satellite Star), TSM (Transparent Satellite Mesh), and RSM (Regenerative Satellite Mesh) (see TR 101 984 [i.1]) are
considered.
The following MPLS/BSM scenarios are identified:
• Scenario A - Full interworking
- Scenario A1: all STs and the Hub contain an integrated LSR functionality; three variants are considered,
which differ in the type of underlying BSM network: (i) TSS, (ii) TSM, and (iii) RSM.
- Scenario A2: all STs, the Hub, and the (OBP) satellite contain an integrated LSR functionality; the BSM
network is of type RSM. (Scenario A2 will not be studied in detail.)
• Scenario B - Interworking using IP tunnels
- Scenario B1: using IP as the encapsulation protocol, MPLS packets are tunnelled across the unmodified
BSM network. (This applies to all types of BSM networks.)
• Scenario C - MPLS delivered by Layer-2 ST
Here, MPLS is transported via a satellite Layer 2 modem, i.e. the ST only contains a L2 bridge. This Scenario
has thus limited relevance to the MPLS operation. In particular, the assumed model of a Layer-2 modem (L2
transport of complete Ethernet frames) means that the MPLS header information is opaque at this ST lower
layer. It is also of no relevance for the BSM SI-SAP model because the SI-SAP U-plane specification defines a
Layer-3 modem (transport of L3 packets). Scenario C will thus not be analysed further in the present
document.
ETSI
14 ETSI TS 102 856-1 V1.1.1 (2011-07)
In addition to the basic functional and protocol architectures, this clause also specifies the basic concepts related to QoS
provisioning, traffic engineering and resiliency for each scenario. The capabilities of the integrated MPLS/BSM
functional elements for the different scenarios will be described in clause 6. Further details of scenario A (which is
considered the most complete and relevant case for BSM networks) are specified in TS 102 856-2 [11].
In all architecture diagrams in this clause, the following notation is used. Large light grey rectangles placed in the
background indicate the BSM network. White boxes denote BSM network entities. Any small (blue, shaded) boxes
attached to these entities indicate MPLS specific functionality integrated into that entity. Any blue lines emanating from
these combined entities indicate logical MPLS-enabled connectivity to the respective combined entity.
5.1 Scenario A: Full Interworking of MPLS
This clause introduces an integrated MPLS/BSM scenario whereby full interworking between the MPLS and BSM
networks is realised (Scenario A). From an MPLS network point of view, this means that the functional characteristics
of LSPs entering the BSM network do not differ from LSPs that run across terrestrial links. From a BSM network point
of view, full interworking implies that the BSM network supports the set of MPLS capabilities and features, including
the MPLS QoS, traffic engineering and resiliency capabilities as defined by the IETF.
Full interworking is achieved by adding the LSR functionality to BSM entities in such a way that (i) the combined
entity acts as an ordinary MPLS-enabled IP router inside the MPLS network, and (ii) the BSM-internal procedures are
performed as specified in the BSM standards, with the constraint that these procedures shall not interfere with MPLS
procedures. This entails substantial changes to the ST (or the Hub) as currently defined. These changes are outlined in
clause 6 and detailed in TS 102 856-2 [11]. In terms of the network architecture, Scenario A is thus characterised by
adding the full set of MPLS functionalities to all BSM network entities that shall support LSPs. Scenario variants exist
which differ only in the type of the underlying BSM network, as discussed in the following.
The following clauses specify, respectively, the network architecture, the protocol stack, and the QoS provisioning,
traffic engineering and resiliency mechanisms for the Scenario A variants.
5.1.1 Network Architecture
Figures 5.1 to 5.3 introduce Scenario A1, which is defined in terms of fully MPLS capable ST and Hub (respectively
GW) entities.
Figure 5.1 shows the architecture of Scenario A1 for the case when the BSM network is of type TSS. In this case, LSPs
inside the BSM network directly interconnect the combined LSR/ST only with the LSR/Hub functional entity; LSR/ST
to LSR/ST communication is only possible via a double hop through the LSR/Hub, which acts as an ordinary LSR at
the MPLS (2.5) layer. In terms of interconnection with the outside MPLS network, the combined LSR/ST and LSR/Hub
functional entities act as ordinary LSRs with respect to that network. Note that here the LSR/Hub is capable of acting
both as a BSM-network internal (MPLS-enabled) Hub, and as an (MPLS-enabled) gateway to the terrestrial MPLS
network.
ETSI
15 ETSI TS 102 856-1 V1.1.1 (2011-07)

MPLS
Network
BSM
Transparent
Network
Sat
(TSS type)
ST
Hub
ST
Figure 5.1: Scenario A1 with a TSS type of BSM network
Figure 5.2 shows the architecture of Scenario A1 for the case when the BSM network is of type TSM. As indicated in
the figure, the mesh capability allows for direct, single-hop LSPs between a pair of LSR/STs, thus bypassing the
LSR/Hub functional entity. For the connectivity with the terrestrial MPLS network via the LSR/Hub, the same
considerations as above apply. In fact, in terms of user traffic, the Hub is just a special type of ST, so that the LSR/Hub
and the LSR/ST are equivalent network entities for LSPs.

MPLS
Network
BSM
Transparent
Network
Sat
(TSM type)
ST
Hub
ST
Figure 5.2: Scenario A1 with a TSM type of BSM network
In Figure 5.3, the architecture of Scenario A1 is depicted for the case when the BSM network is of type RSM. In such a
network, no central Hub exists, and the connectivity to the terrestrial MPLS network is provided via a Gateway (GW),
enhanced by the LSR functionality. In terms of MPLS connectivity, the LSR/GW functional entity plays the same role
as the LSR/Hub in the TSM case, except that the GW does not connect a pair of STs (double hop); instead, for ST to ST
connectivity, a BSM network of type R
...