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

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

DTS/SES-00307

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 2: Negotiation and management of MPLS labels and
MPLS signalling with attached networks

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

Reference
DTS/SES-00307
Keywords
broadband, IMS, internet, interworking, IP, MPLS,
multimedia, QoS, 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-2 V1.1.1 (2011-07)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 General background on MPLS and BSM . 9
4.1 MPLS labels allocation and distribution . 9
4.2 General QoS issues in MPLS . 10
4.3 MPLS/BSM architectural issues and relation to TS 102 856-1 . 11
4.4 Relevant BSM issues and organization of the present document . 12
4.5 Relevance of the present document for Scenarios B and C . 12
5 U-plane MPLS data transfer in BSM Systems . 13
5.1 SI-SAP as external interface . 14
5.2 SD transport of MPLS packets . 15
6 C-plane procedures for MPLS in BSM Systems . 16
6.1 Forwarding policies for MPLS signaling . 16
6.1.1 MPLS-signalling QID: IP_queue_label and QIDSPEC parameters . 16
6.1.2 MPLS-signalling QID: destination BSM_ID parameter . 16
6.1.3 MPLS-signalling QID: lease time parameter . 16
6.2 QoS and resource allocation . 17
6.2.1 DiffServ . 17
6.2.2 IntServ . 18
6.3 MPLS interfaces at SI-SAP . 19
6.3.1 MPLS outgoing interface at the ingress ST . 21
6.3.2 MPLS incoming interface at the egress ST . 22
7 M-plane procedures in support of MPLS . 22
Annex A (informative): Suggested update of SI-SAP U-plane primitives . 24
A.1 Use of the BSM_ID in the SI-SAP U-plane primitives . 25
History . 26

ETSI
4 ETSI TS 102 856-2 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 2 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, and for traffic engineering e.g. MPLS-TE. The present document defines the way in
which this technology may be implemented in next generation satellite networks based on the BSM model.
For general background on MPLS the reader is referred to TS 102 856-1 [13].
ETSI
5 ETSI TS 102 856-2 V1.1.1 (2011-07)
1 Scope
The BSM/MPLS technical specifications extend and complement the existing BSM functional architecture ([1] to [3])
and the SI-SAP interface [4] 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 switched routers).
In this general scope, TS 102 856-1 [13] clarifies the main architectural issues, including operational scenarios and
protocol stacks, and discusses how BSM-compliant STs can be designed and configured to address MPLS-specific
tasks.
The present document, clarifies the signalling issues related to the use of MPLS in BSM systems, with a particular focus
on the case when the LSR is completely integrated in an ST; in this case the ST still acts in a BSM-compliant manner
over the satellite, but it also behaves as a classical LSR on its terrestrial interface to external networks.
The setup of multicast MPLS paths is considered out of scope.
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 TR 101 984: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Services and architectures".
[3] ETSI TR 101 985: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP over Satellite".
[4] 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".
[5] ETSI TS 102 462: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); QoS Functional Architecture".
[6] ETSI TS 102 463: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Interworking with IntServ QoS".
[7] ETSI TS 102 464: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Interworking with DiffServ Qos".
[8] ETSI TS 102 672: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Management Functional Architecture".
ETSI
6 ETSI TS 102 856-2 V1.1.1 (2011-07)
[9] ETSI TS 102 673: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Performance Parameters".
[10] ETSI TS 102 675-1: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Part 1: Performance Management at the SI-SAP".
[11] ETSI TS 102 675-2: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Part 2: Performance Management Information Base".
[12] IEEE EtherType Field Public Assignment Announcement.
NOTE: Available at http://standards.ieee.org/regauth/ethertype/eth.txt.
[13] ETSI TS 102 856-1: "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.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 TS 102 602: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
Connection Control Protocol (C2P) for DVB-RCS; Specifications".
[i.2] IETF RFC 2210: "Use of RSVP with IETF Integrated Services".
[i.3] IETF RFC 2863: "The Interfaces Group MIB".
[i.4] IETF RFC 3031: "Multiprotocol Label Switching Architecture".
[i.5] IETF RFC 3035: "MPLS using LDP and ATM VC Switching".
[i.6] IETF RFC 3209: "RSVP-TE: Extensions to RSVP for LSP Tunnels".
[i.7] IETF RFC 3270: "MPLS Support of Differentiated Services".
[i.8] IETF RFC 3468: "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS
signalling protocols".
[i.9] IETF RFC 3564: "Requirements for Support of Differentiated Services-aware MPLS Traffic
Engineering".
[i.10] IETF RFC 363: "Traffic Engineering (TE) Extensions to OSPF Version 2".
[i.11] IETF RFC 3813: "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)
Management Information Base (MIB)".
[i.12] IETF RFC 3814: "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next
Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)".
[i.13] IETF RFC 4090: "Fast Reroute Extensions to RSVP-TE for LSP Tunnels".
[i.14] IETF RFC 4204: "Link Management Protocol (LMP)".
[i.15] IETF RFC 4875: "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
for Point-to-Multipoint TE Label Switched Paths (LSPs)".
[i.16] IETF RFC 5036: "LDP Specification".
[i.17] IETF RFC 5342: "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters".
[i.18] IETF RFC 5462: "MPLS Label Stack Entry - EXP Field renamed to Traffic Class Field".
[i.19] Internet Draft draft-ietf-mpls-ldp-p2mp-13: "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Paths", April 2011.
ETSI
7 ETSI TS 102 856-2 V1.1.1 (2011-07)
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)
BSM System (BSMS): system comprising a BSM Network together with a Network Management Centre (NMC) and
Network Control Centre (NCC)
NOTE: The BSM System also includes any additional elements that are required to provide the network services
to the subscribers and their users.
control plane: the plane that provides the control functions
NOTE: The control plane 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.
flow (of IP packets): traffic associated with a given connection-oriented, or connectionless, packet sequence having the
same 5-tuple of source address, destination address, Source Port, Destination Port, and Protocol type
forwarding: process of relaying a packet from source to destination through intermediate network segments and nodes
NOTE: The forwarding decision is based on information that is already available in the routing table. The
decision on how to construct that routing table is the routing decision.
management plane: the plane that provides the management functions
NOTE: The management plane provides two types of functions, namely Layer Management and plane
management functions:
� Plane management functions are functions related to a system as a whole and provides co-
ordination between all the planes. Plane management has no layered structure.
� Layer management functions are functions relating to resources and parameters residing in its
protocol entities. Layer management handles the operation and maintenance (OAM) of information
flows specific to the layer concerned.
network control centre: equipment at OSI Layer 2 that controls the access of terminals to a satellite network, including
element management and resource management functionality
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
8 ETSI TS 102 856-2 V1.1.1 (2011-07)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AF Assured Forwarding
ATM Asynchronous Transfer Mode
BA Behaviour Aggregate
BE Best Effort
BNMS BSM Network Management System
BSM Broadband Satellite Multimedia
BSMS BSM System
CL Controlled Load
CS Class Selector
DiffServ Differentiated services (IETF)
DSCP DiffServ Code Point
EF Expedited Forwarding
E-LSP Explicitly TC-encoded-PSC LSP
FEC Forwarding Equivalence Class
FRR Fast Re-route
FTN FEC-To-NHLFE
GS Guaranteed Service
IETF Internet Engineering Task Force
ILM Incoming Label Map
IntServ Integrated Services (IETF)
IP Internet Protocol
ISO International Organization for Standardization
L2 Layer 2 (of the ISO/OSI protocol stack)
L3 Layer 3
LDP Label Distribution Protocol
LER Label Edge Router
L-LSP Label-inferred-PSC LSP
LMP Link Management Protocol
LSP Label Switched Path
LSR Label Switch Router
MIB Management Information Base
MPLS Multi-Protocol Label Switching
NCC Network Control Centre
NHLFE Next Hop Label Forwarding Entry
NMC Network Management Centre
OSI Open Systems Interconnection
OSPF Open Shortest Path First
PDU Protocol Data Unit
PHB Per-Hop Behaviour
PSC PHB Scheduling Class
QID Queue Identifier
QoS Quality of Service
RFC Request for Comments
RSVP Resource Reservation Protocol
SDU Service Data Unit
SD Satellite Dependent
SDAF Satellite Dependent Adaptation Functions
SI Satellite Independent
SIAF Satellite Independent Adaptation Functions
SI-SAP Satellite Independent Service Access Point
ST Satellite Terminal
TC Traffic Class
TE Traffic Engineering
TTL Time To Live
VCI Virtual Circuit Identifier
VPI Virtual Path Identifier
VPN Virtual Private Network
ETSI
9 ETSI TS 102 856-2 V1.1.1 (2011-07)
VSN Virtual Satellite Network
4 General background on MPLS and BSM
4.1 MPLS labels allocation and distribution
MPLS adds a header (also called the "shim header") in front of IP packets, it can contain one or more "MPLS headers"
in a stack (also called the "label stack"). An MPLS header is 32 bits long and contains four fields:
• label value (20 bits),
• Traffic Class (TC) field (3 bits), for QoS priority, it was originally called EXP field (experimental),
• bottom-of-stack flag (1 bit), when it is set, it means that the current label is the last in the label stack,
• TTL (Time To Live) field (8 bits).
NOTE: The old EXP field was recently renamed to "Traffic Class field" ("TC field"), which will be used herein
(see [i.18], September 2009).
The label field is the key field in the "MPLS header". MPLS-labelled packets are switched based on a lookup in a label
table, instead of checking the IP routing table, this makes the packet forwarding faster and gives the possibility to create
connection-oriented paths, the so-called Label Switched Paths (LSPs), with predefined QoS levels; IP packets and IP
flows can be then mapped onto these paths. MPLS routers that perform routing based only on the label are called Label
Switch Routers (LSR). The entry and exit points of an MPLS network are called Label Edge Routers (LERs), which,
respectively, push an MPLS label onto an incoming packet and pop it off the outgoing packet. Labels can be stacked on
top of others, so that nested LSPs can be created. When operating on top of specific L2 technologies, the shim header
can also be avoided: MPLS can make use of existing ATM network or frame relay infrastructure, in these cases the
MPLS-labelled flows are mapped to ATM or frame relay virtual circuit identifiers.
The configuration of the LERs and of the LSRs is performed through label distribution protocols. LDP, Label
Distribution Protocol [i.16], was the first protocol designed by IETF for MPLS label distribution, and it remains the
simplest solution, but it provides no traffic engineering capabilities. LDP has the following main characteristics:
• At LDP start-up, labels automatically get advertised for each route in the routing table to all LDP peers and a
full set of LSPs is automatically created amongst all the interconnected nodes running LDP, independently of
whether they are needed or not; this, even if it affects only the signalling and not user data, may not be
efficient for satellite networks, as it may create unnecessary traffic over the satellite air interface.
• LDP provides limited QoS capabilities: only the TC-field bits can be used to incorporate "relative QoS", this
means that prioritization and queue scheduling can be employed, but it is difficult to enforce QoS guarantees.
Two traffic-engineering enabling protocols for labels distribution were designed later by IETF: CR-LDP and
RSVP-TE [i.6]. CR-LDP is no longer under maintenance by IETF (see [i.8]), so RSVP-TE, with its several recent
updates, should be preferred in BSM implementations of MPLS, for traffic engineering purposes.
Main characteristics of RSVP-TE are as follows:
• Label request and distribution.
• Explicit routing: label-switched tunnels can be created along explicitly specified routes.
• LSP setup and holding priorities: these priorities are used in deciding whether a session can pre-empt (setup
priority) or be pre-empted by (holding priority) another session.
• Resource reservation: RSVP-TE includes QoS information in the signalling messages to enable resource
allocation and LSP establishment to take place automatically:
- RSVP-TE signalling creates an LSP automatically, if the requested QoS parameters are met; the QoS
parameters can include destination and options such as bandwidth requirements, link attribute
requirements, backup and fast re-route etc.;
ETSI
10 ETSI TS 102 856-2 V1.1.1 (2011-07)
- The parameters for the LSP setup request have to be manually configured, which makes things complex
for networks with a high number of LSRs and with a full mesh LSPs (the number of LSPs to be setup
scales with the square of the LSRs);
- If the requested parameters are met and the LSP is setup, then QoS parameters are guaranteed ("hard
QoS", like IntServ);
- RSVP-TE also supports LSPs without resource reservation, which may be used to carry best effort IP
traffic.
• Resilience: LSPs can be configured for Fast Reroute (FRR) [i.13]; in this case, if there is a failure in the
network, the LSPs can bypass the failure in a very short time (in the order of tens of ms). FRR can be seen as
the packet-world's version of the automatic protection switching for optical networks (e.g. used in SONet to
overcome fibre cuts), since it makes perceive the MPLS packet layer as reliable as the circuit-switched
physical layers.
As LDP is less complex, it can be considered an efficient alternative to RSVP-TE for small-scale BSM networks and
low-complexity STs. Both signalling techniques are frequently used together in today's networks, even in a combined
fashion; also most of the equipment vendors support both protocols simultaneously. So, in BSM networks operating
according to Scenario A, depending on the providers' and operators' needs, both LDP and/or RSVP-TE may be
implemented in the STs.
Both protocols foresee extensions for the setup of multicast LSPs (RSVP-TE extensions have already been formalized
in an RFC [i.15], LDP extensions are in a quite advanced state, but still in an Internet draft form [i.19]). Although
multicast MPLS is considered out of the scope of the present document, multicast services are of great relevance for
satellite networks; so it is worth noting that most of the issues addressed in the present document would also apply in
case multicast LSPs are setup. The only difference is in the label distribution signalling that takes place at the LSP
setup, but this should in any case be done according to the selected label distribution protocol, and so it does not have
an impact on the BSM subnetwork and on the SI-SAP.
4.2 General QoS issues in MPLS
Providing QoS support in MPLS networks means that packets are forwarded via MPLS label swapping, but different
packet flows of different service classes are treated in different ways (see [i.7]). We will consider the most general case
in which an extended, hybrid (i.e. terrestrial IP and BSM) MPLS network is running RSVP-TE for enhanced QoS and
Traffic Engineering capabilities. The BSM STs in this hybrid network were upgraded to support the required LSR
capabilities (see Scenario A in TS 102 856-1 [13]) and DiffServ.
If we consider DiffServ for the QoS support, in [i.7] two solutions are proposed: E-LSP (Explicitly TC-encoded-PSC
LSP) and L-LSP (Label-Inferred-PSC LSP). Very basically the former one allows the Per-Hop Behaviour (PHB) to be
applied on a packet to be inferred from the TC field of the MPLS shim header, whereas the latter one uses the MPLS
label of the packet to communicate the PHB.
NOTE: A situation with a BSM ST connected on its terrestrial interface to an ATM or a frame relay network is
not considered a realistic scenario; so for BSM networks the TC field can be considered always available
(in fact the TC field is not present only when there is no shim header, so when MPLS is operating on top
of ATM or frame relay networks). For this reason the election of one of the two solutions, E-LSP or
L-LSP, for BSM networks does not seem a concern; in addition [i.9] recommends the support of both
solutions.
Figure 4.1 illustrates the behaviour of a DiffServ-enabled MPLS node (e.g. an ST) with a practical example; three
DiffServ classes are provided through a Weighted Round Robin (WRR) scheduler. When a new connection between a
source and a destination starts, an LSP is created using, for instance, RSVP-TE. We assumed in the picture that
RSVP-TE packets are considered with high priority, so as if they belong to class A. During the LSP establishment
process, an MPLS node receiving an RSVP-TE packet performs essentially three actions:
1) Determine the output link according to the routing table.
2) Retrieve information on which PHB the advertised label is to be bound.
3) Actualize the data related to the being-created LSP (in/out labels and in/out interfaces) in the label switching
table.
ETSI
WRR
11 ETSI TS 102 856-2 V1.1.1 (2011-07)
The RSVP-TE packet is then forwarded to the next node (or next ST) to continue creating the LSP. Later, when MPLS
data packets arrive, the information stored in the label forwarding table will be used for switching/forwarding purposes.
In the present example, three different queues are defined in each output link of the MPLS network to support the three
desired traffic classes, PHBs are implemented with a WRR scheduler, which is used to select the sequence of packets to
be served among the different queues.
MPLS Node
Label Switching Table
IN Int./Label OUT Int./Label
WRR
Class A
Routing Table
Out. 1
@IP 1
Out. 1
Input Link Class B
Out. 2
@IP 2
Output Link
Class C
Out. 2
Service Class.
RSVP-TE message
to setup an LSP for
Class-C data packets
LSP for Class-C
data packets
Figure 4.1: Functional diagram of a node with MPLS capabilities
4.3 MPLS/BSM architectural issues and relation to
TS 102 856-1
The main fact that should be considered to understand the issues in the integration of MPLS in BSM networks is that
the SI-SAP is an interface between layer-3 (L3) and layer-2 (L2), on the other hand MPLS packets reaching an ST have
to be switched "below" IP, based on their label, so IP headers are not processed (MPLS is normally considered
layer-2.5).
TS 102 856-1 [13] discusses how this general issue can be addressed. Basically there the following three approaches are
presented:
• an LSR is fully integrated with the ST (scenario A);
• an LSR is externally attached to an ST (so the LSR is not considered part of the MPLS/BSM network) and the
ST can operate in two ways:
- MPLS packets are tunnelled over IP across an unmodified BSM network (scenario B),
- MPLS is transported via a satellite L2 modem, i.e. the ST only contains a L2 bridge (scenario C).
The present document focuses on scenario A (LSR fully integrated with the ST), since it is considered the most
complete and relevant case for BSM networks, whereas, as better explained in TS 102 856-1 [13], Scenario B and C are
of little or no relevance.
ETSI
u
Outp t
inK
L
s
Cla s B
Class A
Class C
... ......
Service Class.
12 ETSI TS 102 856-2 V1.1.1 (2011-07)
4.4 Relevant BSM issues and organization of the present
document
The BSM architecture has been so far designed to transport L3 Protocol Data Units (PDUs), namely IP packets (see [4],
clause 6.2.1.2), and thus the signaling and the procedures in the Control and Management planes have been designed
accordingly. The use of MPLS in BSM networks introduces the need of transporting different types of PDU and to
foresee the handling of additional signaling on the Control and the Management planes. The present clause gives a short
overview of the issues identified on the three planes (User, Control, and Management plane), when integrating an LSR
in a BSM-compliant ST.
On the U-plane, the Service Data Unit (SDU) at the SI-SAP can also be an IP packet encapsulated with a MPLS shim
header, which is 32 bits long. The U-plane also has to transfer MPLS-based signalling, but this has no major effects
since signaling protocols like LDP and RSVP-TE run on top of IP. These issues will be considered in clause 5.
As already mentioned, the current BSM C-plane only considers treatment of IP packets. There are at least three areas
which need to be considered (they will be addressed in clause 6):
• Forwarding policies for MPLS signaling: RSVP-TE (or LDP) packets will be sent to every MPLS-enabled ST
in order to setup LSPs; these packets need to be treated with higher priority than normal data-plane IP packets,
so proper forwarding policies for this type of signaling have to be available and ready in the ST at LSP setup.
• QoS and resource allocation: LSPs have to be mapped onto SD resources, this needs to be performed,
according to BSM philosophy, by means of QIDs (see [5] to [7]) and it can be done in different ways
according to the possible situations.
• MPLS interfaces at SI-SAP: in order to transfer a PDU through the SI-SAP, an ST normally associates the IP
destination address of the IP packet to be transmitted over the satellite interface with a BSM_ID (this includes
an SI-SAP address resolution procedure [4]); in an MPLS-enhanced ST it would be preferable not to inspect
the IP header when an MPLS-labeled packet has to be sent (the purpose of having MPLS is in fact in saving
the IP-layer processing), but to derive the destination BSM_ID from the (top-most) MPLS label rather than
from the IP-address.
Clause 7 will address the remaining M-Plane issues. Performance monitoring procedures and performance parameters
for BSM networks have already been defined in a set of technical specifications (see [8] to [11]). When running an LSP
over a satellite interface, it is important to monitor the link attributes in order to guarantee the provision of the QoS
levels agreed at the LSP setup (the link transmission rate may change, e.g. due to degradation of the weather
conditions); so the BSM Network Management System (BNMS) needs to make use of the tools provided for
Performance Management at the SI-SAP in the mentioned technical specifications.
4.5 Relevance of the present document for Scenarios B and C
Scenarios B and C were introduced in TS 102 856-1 [13].
In Scenario B, the BSM network is processing only IP packets. The QoS requirements linked to the encapsulated MPLS
packet have to be mapped onto the encapsulating IP header, so that the BSM entities can process and forward these IP
datagrams following exactly the same procedures as with native IP datagrams that contain no encapsulated MPLS
packets. The issues discussed in the present document in clauses 5 and 6 (U- and C-plane) are not applicable to this
scenario, but the issues discussed in clause 7 (M-plane) remain valid also for this scenario.
In Scenario C the ST acts as a L2 bridge between its terrestrial interface and its satellite interface; so MPLS runs on top
of the satellite link, as if it is the prolongation of the terrestrial L2 interfaces of the ingress and egress STs. The ingress
and egress STs do not have LER/LSR functionalities, and so they do not perform any label swapping, pushing or
popping and do not handle any MPLS signalling, the LSP configuration for the satellite link has to be performed
manually before the LSP is setup. All the issues discussed in the present document are not applicable to this scenario,
also because for this type of STs the SI-SAP interface cannot be defined.
ETSI
13 ETSI TS 102 856-2 V1.1.1 (2011-07)
5 U-plane MPLS data transfer in BSM Systems
In an ST the SI-SAP provides to the higher layers a data transfer service, which is used to transfer PDUs from the
Satellite-Independent (SI) layers down to the Satellite-Dependent (SD) layers at the ingress ST, and from the SD layers
to the SI layers at the egress ST. This is done by taking the SI PDU as a Service Data Unit (SDU) and encapsulating it
into a U-plane data transfer primitives: The SI-U-UNITDATA-req primitive is invoked at the sender, the SDU
encapsulated in the primitive and passed down to the SD layers; at the peer ST, the SD layers deliver the SDU to the
upper layers using a data transport SI-U-UNITDATA-ind primitive, the SDU is extracted and passed as a PDU to the SI
layers.
In an MPLS-enable ST, each SDU at the SI-SAP shall contain a complete IP datagram plus all its MPLS headers.
So far the possible SDUs which are accepted by an SI-SAP are only L3 PDU, so basically IP packets: "each SDU shall
contain a complete IP datagram" (from [4], clause 6.2.1.2). In fact, introducing MPLS, means allowing other kinds of
PDUs to be accepted as SDU by the SI-SAP, in particular allowing IP packets encapsulated in one MPLS shim header
(or encapsulated in more nested MPLS shim headers). This only changes the definition of the format of the data
transferred at the SI-SAP. The lower layers (below the SI-SAP) are not affected, and may behave as usual, e.g. may
segment the IP packet as required for transmission over the air interface.
The SDU that is delivered at the egress ST shall be identical to the SDU that was submitted by the ingress ST. This
means that the SDU delivered at the destination ST can be directly submitted to the destination IP layer or to the MPLS
layer with no additional processing, reassembly or similar. Anyway the egress SI-SAP needs to know whether the SDU
has to be delivered to the IP layer or to the MPLS layer. Thus, at the egress SI-SAP, it is important to be able to
distinguish plain IP packets from MPLS packets. This can be done by inspecting the SDU_Type field in the -ind
primitive.
In this respect it is worth to note that an MPLS-enabled ST will always need to process traffic that is a mixture of IP and
MPLS packets. In fact if it is a LER, it will receive IP packets and may have to push an MPLS label in front of them
before forwarding over the satellite interface (or similarly to pop an MPLS label from a packet received on the satellite
interface before forwarding to the terrestrial interface). If the ST is a simple LSR, so it is not performing label pushing
or popping, it will have in any case to handle label distribution protocols, which are plain IP packets. In addition to that
there might always be traffic which is not mapped onto LSPs, and so has to be forwarded by classical IP routing. Figure
5.1 shows the details on the packet processing at the interface between the L3 and the L2 and the interaction between
SI-SAP, the IP layer and the MPLS layer, and how packets are forwarded to one or the other. The arrows numbered in
the diagram can be explained as follows:
(a) This Service Access Point (SAP) represents both the SI-SAP in the egress ST and the terrestrial L2 SAP in the
ingress ST; it selects the L3 module (IP or MPLS) to which the incoming packet has to be passed by looking at
the SDU type: if the field indicates MPLS, the SDU is forwarded to the MPLS layer, otherwise to the IP layer.
At the egress ST this selection could also be made based on the source BSM_ID, so on an L2 address identifier
of the ingress ST (see also note 1).
NOTE 1: In many BSM implementations, not only related to MPLS, it may be important at the egress SI-SAP to be
able to identify the ingress ST, e.g. a common situation could be a receiving hub which needs to identify
the transmitting ST; this would be equivalent to a terrestrial router, which is always able to identify the
incoming interface since they are physically separated. The L2 source address information is always
available at the SD layers of the egress ST (e.g. the hub can derive it from the scheduling plan), so it is
considered wise to pass this information to the SI layers through an SI-SAP primitive; this can be done
with the BSM_ID field in the U-plane primitive, as explained in annex A.
(b) This selection point represents IP classification and routing:
(b.1) this path represents the routing of plain IP packets, which do not need to go through the MPLS module,
but can be sent directly over the SI-SAP (in the ingress ST) or to the outgoing terrestrial interface (in the
egress ST);
(b.2) this path represents IP packets that need to enter into an MPLS path (a LSP), thus they need to get a new
MPLS label; thus this path represents the label pushing operation in an ingress ST that acts as a LER; it
is not present in an egress ST because it is assumed (in the diagram) that an egress ST cannot be the entry
point of an MPLS network.
NOTE 2: Of course the case of an egress ST that is the entry point of a terrestrial MPLS is also a possible scenario,
but this case is not considered relevant here.
ETSI
14 ETSI TS 102 856-2 V1.1.1 (2011-07)
(c) The selection point c) represents MPLS label switching:
(c.1) this is the classical label swapping path, an incoming MPLS packet is inspected, its next hop is derived
from the label and the label is swapped before forwarding;
(c.2) this path represents the label popping operation: MPLS packets which are at the end of an LSP are taken
away the MPLS label and forwarded as plain IP packets; it is not present in an ingress ST because it is
assumed (in the diagram) that an ingress ST cannot be the exit point of an MPLS network.
NOTE 3: Of course the case of an ingress ST that is the exit point of a terrestrial MPLS is also a possible scenario,
but this case is not considered relevant here.
Ingress ST Egress ST
IP IP
(b.1)
(b.1)
(c.2)
(b.2)
MPLS MPLS
(c.1) (c.1)
SI-SAP SI-SAP
(a) (a)
terrestrial satellite satellite terrestrial
L2/L1 L2/L1 L2/L1 L2/L1
Satellite Network
Figure 5.1: Details on the L3-L2 interface in an MPLS-enabled ingress ST (left) and
in an MPLS-enabled egress ST (right)
What happens in the ingress ST after (c.1) or (b) is not relevant here; separate QIDs for MPLS and IP can be used, or
the same QID can be used for both. QIDs have anyway only meaning locally at the ingress ST and opening more QIDs
does not imply additional use of resources on the satellite interface. For this reason the management of the QIDs at this
point is left to the implementers, but there is anyway merit in having separate QIDs, in order to guarantee proper
monitoring of the LSP QIDs.
5.1 SI-SAP as external interface
An external MPLS router (LSR/LER) may need to be connected to an SD-only capable ST through a physical SI-SAP
interface over which the primitives will be exchanged. Even if physically separated, the MPLS router and the SD-only
ST represent logically a fully integrated MPLS-enabled ST, so this situation falls in the same scenario A (according to
the classification given in Part 1). In this case the SI-SAP interface can be of great help to allow a clean separation of
the two hardware modules: The SIAF can be implemented in the MPLS router and the SDAF in the SD-only ST.
Figure 5.2 represents the protocol stack in this case.
ETSI
15 ETSI TS 102 856-2 V1.1.1 (2011-07)
SI-SAP-enabled
MPLS router
(LSR/LER)
IP
SD-only capable
Satellite
Satellite
Independent
MPLS
Terminal
SIAF
SDAF
SI-SAP
SLC
Terrestrial L2 LAN L2 LAN L2
conventional
L2-L1 SMAC
stacks
Terrestrial L1 LAN L1
LAN L1 SPHY
SI-SAP over LAN
MPLS Network Satellite Network

Figure 5.2: Details on the L3-L2 interface in an MPLS-enabled ingress ST (left) and
in an MPLS-enabled egress ST (right)
5.2 SD transport of MPLS packets
There are two possible ways of handling MPLS packets at SD layers:
• encapsulate the MPLS packet in the SD link layer protocol;
• strip off the MPLS header and map in onto an SD identifier.
The former method allows "transport" of the MPLS label transparently, and is the most flexible way; the method always
works also in case of multiple nested MPLS labels.
Concerning the latter method, it is noted that on the SD air interfaces MPLS labels may be omitted in some cases, they
will be remapped to SD connection identifiers. This can be done to save the 4 bytes of the MPLS header in the SDU. In
fact in terrestrial networks this is sometime done, MPLS over ATM indeed uses the contents of the VCI field or the
combined contents of the VPI and VCI fields to encode the (top) MPLS label.
Several existing satellite L2 protocols (e.g. C2P [i.1]), give the possibility to define SD channel identifier that could be
used for this purpose (as LSP identifiers); also especially relevant is the widely spread link-layer concept of VSN
(Virtual Satellite Network), which can be exploited for that, or for MPLS VPNs. Anyway some issues are highlighted
here, which discourage from adopting this solution:
• in case of stacked labels only the top label can be mapped onto an SD identifier;
• the size of the SD identifier
...