ETSI TS 102 464 V1.2.1 (2015-12)

Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia (BSM); Interworking with DiffServ QoS

RTS/SES-00357

General Information

• Status: Published
• Publication Date: 17-Dec-2015
• Technical Committee: SES SCN - Satellite Communications and Navigation
• Current Stage: 12 - Completion
• Due Date: 03-Dec-2015
• Completion Date: 18-Dec-2015

Standards Content (Sample)

TECHNICAL SPECIFICATION
Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM);
Interworking with DiffServ QoS

2 ETSI TS 102 464 V1.2.1 (2015-12)

Reference
RTS/SES-00357
Keywords
broadband, interworking, IP, 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
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (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:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
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 464 V1.2.1 (2015-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 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 . 10
4 Overview . 11
5 DiffServ BSM Functional Architecture. 12
5.0 Aim and Scope . 12
5.1 Overall BSM DiffServ Architecture . 12
5.2 ST DiffServ Architecture . 14
5.2.0 Overview . 14
5.2.1 DiffServ Functions . 15
5.2.1.0 Introduction . 15
5.2.1.1 User-Plane Functions . 15
5.2.1.2 Control-Plane Functions . 16
5.2.2 Detailed Functional Architecture . 17
5.2.2.0 U- and C-plane operations . 17
5.2.2.1 Ingress ST DiffServ Functions . 19
5.2.2.1.0 Detailed Functional Architecture . 19
5.2.2.1.1 RSVP . 20
5.2.2.1.2 NSIS . 21
5.2.2.2 Egress ST DiffServ Functions . 21
6 DiffServ QID Management . . 21
6.0 Aim and Scope . 21
6.1 Description . 21
6.2 QID Relationship to SD Resource Reservation . 22
6.2.0 QID-to-SD Mapping . 22
6.2.1 Static SD Resources . 23
6.2.1.0 Overview . 23
6.2.1.1 Static QIDs . 23
6.2.1.2 Dynamic QIDs . 23
6.2.2 Dynamic SD Resources . 24
6.2.2.0 Overview . 24
6.2.2.1 Static QIDs . 25
6.2.2.2 Dynamic QIDs . 25
6.2.3 Summary . 26
6.3 QID Relationship to SI layers. 26
6.3.0 DiffServ Per Hop Behaviours (PHBs) . 26
6.3.1 Best Effort . 27
6.3.2 Expedited Forwarding. 28
6.3.3 Assured Forwarding . 29
6.3.4 Class Selector . 30
6.3.5 Summary . 31
Annex A (informative): Relationship to the RSM-B Air Interface family (DVB-RCS) . 32
A.0 General . 32
ETSI
4 ETSI TS 102 464 V1.2.1 (2015-12)
A.1 SATLIFE satellite system summary . 32
A.2 SATLIFE QoS model . 33
A.3 RCST/NCC Model . 35
A.3.0 Overview . 35
A.3.1 User Plane . 35
A.3.2 Control Plane . 36
Annex B (informative): Relationship to the TSS-A Air Interface Family (DVB-RCS) . 37
Annex C (informative): DiffServ DSCPs . 38
Annex D (informative): Bibliography . 39
History . 40

ETSI
5 ETSI TS 102 464 V1.2.1 (2015-12)
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).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The BSM architecture is characterized by the separation between common Satellite-Independent (SI) protocol layers
and alternative lower Satellite-Dependent (SD) layers, which are connected through the Satellite Independent Service
Access Point (SI-SAP) [1]. The general issues concerning the architecture of BSM systems are described in ETSI
TR 101 984 [i.1], further specific requirements and functional models for Quality of Service (QoS) concerning
IP-over-satellite aspects are presented in ETSI TR 101 985 [i.2] and ETSI TR 102 157 [i.3].
In general the SI-SAP offers an agnostic interface to whichever SD layer is used. So QoS provision in the BSM
architecture has to face the issue of traversing the SI-SAP interface by means of standardized signalling, which is
expected to enable on one side maintaining compatibility with existing QoS functions required in the IP layers and
above, and on the other side communication to the lower layer entities deputed to QoS accomplishment.
At the IP layer, two principal techniques for QoS provision exist: DiffServ [7], and RSVP/IntServ [4], [5]. At the SD
layers more sophisticated QoS methods are closely linked to lower layer resource management and control, they
strongly depend on the satellite technology adopted and on the particular implementation.
For QoS provision in a BSM network the concept of QIDs (Queue Identifiers) is a key concept [2]. They represent
abstract queues, each with a defined class of service, for transfer of IP packets to the SD layers. The satellite dependent
lower layers are responsible for assigning satellite capacity and/or particular forwarding behaviour to these abstract
queues according to defined properties. The reader should in particular refer to ETSI TS 102 463 [i.14], for a detailed
description of QIDs and of the associated primitives.
ETSI
6 ETSI TS 102 464 V1.2.1 (2015-12)
1 Scope
The aim of the present document is to define an open specification for enabling QoS for IP-based multimedia satellite
systems, based on the DiffServ model. If IP packets entering the BSM network require a particular QoS treatment, they
have to be mapped onto QIDs. The choice of the QID to be used inside the BSM network is thus particularly important.
So the present document specifies the allocation of the QIDs and their mapping to IP QoS classes, when DiffServ is
used to provide QoS at IP layer. The present document assumes the QoS functional architecture described in ETSI
TS 102 462 [2].
The present document describes in detail how QIDs are defined, how they are allocated and handled by the BSM
network, and the requirements needed by sending and receiving Satellite Terminals (STs) in a BSM network to provide
QID management functionalities. The present document also defines the primitives that should be used across the
SI-SAP when allocating QIDs, when mapping DiffServ Code Points (DSCPs) and IP services to QIDs, when mapping
QIDs to SD queues.
Details on the QID mapping are presented with some examples. Some cases are presented to show the potential
evolution from a simple QoS solution with quasi-static QID allocation to more sophisticated services with dynamic
resource reservation.
The combination of DiffServ with multicast transmissions is out of scope of the present document, as well as the use of
Explicit Congestion Notification (ECN), which was linked to DiffServ only for historical reasons, as the ECN bits are
the two least significant bits of the IPv4 ToS octet. This is better explained in clause 4.
2 References
2.1 Normative 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.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 357: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Common Air interface specification; Satellite Independent Service Access Point (SI-SAP)
interface: Primitives".
[2] ETSI TS 102 462: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); QoS Functional Architecture".
[3] IETF RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to IP",
September 2001.
[4] IETF RFC 1633: "Integrated Services in the Internet Architecture: an Overview", June 1994.
[5] IETF RFC 2210: "The Use of RSVP with IETF Integrated Services", September 1997.
[6] IETF RFC 2474: "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", December 1998.
[7] IETF RFC 2475: "An Architecture for Differentiated Service", December 1998.
[8] IETF RFC 2597: "Assured Forwarding PHB Group", June 1999.
[9] IETF RFC 3246: "An Expedited Forwarding PHB (Per-Hop Behavior)", March 2002.
ETSI
7 ETSI TS 102 464 V1.2.1 (2015-12)
[10] IETF RFC 3247: "Supplemental Information for the New Definition of the EF PHB (Expedited
Forwarding Per-Hop Behavior)", March 2002.
[11] IETF RFC 3260: "New Terminology and Clarifications for Diffserv", April 2002.
2.2 Informative 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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] ETSI TR 101 985: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP over Satellite".
[i.3] ETSI TR 102 157: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP Interworking over satellite; Performance, Availability and Quality of Service".
[i.4] IETF RFC 2998: "A Framework for Integrated Services Operation over Diffserv Networks",
November 2000.
[i.5] IETF RFC 4080: "Next Steps in Signaling (NSIS): Framework", June 2005.
[i.6] Satellite Access Technologies: Leading Improvements For Europe.
NOTE: Available at http://www.satlife.org
[i.7] Wittig, Manfred; Casas, Jose-Maria. "A communications switchboard in the sky: AmerHis". ESA
Bulletin, No. 115. August 2003.
[i.8] S. Chacón, J-L. Casas, A. Cal, R. Rey, J. Prat, A. Rodriguez, J. de la Plaza, C. Nieto, F. Ruiz
Piñar. Multimedia Applications of the Integrated Broadcast Interaction System (IBIS). ESA
Workshop on Digital Signal Processing, Lisbon (Portugal), October 2001.
[i.9] ETSI TS 102 429-1: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Regenerative Satellite Mesh - B (RSM-B); DVB-S/DVB-RCS family for regenerative
satellites; Part 1: System Overview".
[i.10] "SatLabs System Recommentations v2.0", November 2006.
NOTE: Available at http://satlabs.org/.
[i.11] S. Floyd and V. Jacobson "Random Early Detection Gateways for Congestion Avoidance".
IEEE/ACM Transactions on Networking, Vol. 1, Issue 4, August 1993.
[i.12] ETSI TS 102 429-3: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Regenerative Satellite Mesh - B (RSM-B); DVB-S/DVB-RCS family for regenerative
satellites; Part 3: Connection control protocol".
[i.13] ETSI TS 102 402: "Satellite Earth Station and systems (SES); Broadband Satellite Multimedia;
Transparent Satellite Star - A (TSS-A); DVB-S/DVB-RCS for transparent satellites; Sub-family 1
(TSS-A1)".
[i.14] ETSI TS 102 463: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Interworking with IntServ QoS".
ETSI
8 ETSI TS 102 464 V1.2.1 (2015-12)
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.
bearer service: type of telecommunication service that provides the capability for the transmission of signals between
user-network interfaces
Behaviour Aggregate (BA): collection of packets with the same DS code point crossing a link in a particular direction
Best-Effort (BE) service: service that offers no QoS guarantees, just end-to-end connectivity
NOTE: When using queuing to prevent congestion BE queues are always the first ones to experience packet drop.
BSM Bearer service: telecommunication service that a BSM subnetwork provides between a pair of SI-SAPs in
different STs
Class of Service (COS): way to divide traffic into separate categories (classes) to provide appropriate QoS services to
each class within the network
classification: examination of an IP packet to determine the COS to which the packet should belong
code point: specific value of the DSCP portion of the DS field
NOTE: Recommended code points should map to specific standardised Per-Hop Behaviours (PHBs). Multiple
code points may map to the same PHB.
connection oriented: communication method in which communication proceeds through three well-defined phases:
connection establishment, data transfer, and connection release
connectionless: communication method that allows the transfer of information between users without the need for
connection establishment procedures
control plane: plane with a layered structure that performs the call control and connection control functions and deals
with the signalling necessary to set up, supervise and release calls and connections
data link layer: second layer of the OSI model it provides connectivity between segments of the network (bridging); in
addition the data link may perform session control and some configuration
delay variation (or delay jitter): difference in delay between successive packet arrivals (of the same flow) at the
egress of the network
Differentiated services (DiffServ): services based on statistical (aggregated flows) guarantees and resulting in "soft"
QoS
NOTE: Using packet markings (code points) and queuing policies it results in some traffic to be better treated or
given priority over other (use more bandwidth, experience less loss, etc.).
ETSI
9 ETSI TS 102 464 V1.2.1 (2015-12)
Differentiated Services Codepoint (DSCP): value which is encoded in the DS field, and which each DS node use to
select the PHB which is to be experienced by each packet it forwards
Differentiated Services field (DS field): six most significant bits of the (former) IPv4 TOS octet or the (former) IPv6
Traffic Class octet
DS domain: contiguous set of DS nodes which operate with a common service provisioning policy and set of PHB
groups implemented on each node
flow: flow of packets is the traffic associated with a given connection or connectionless stream having the same source
host, destination host, class of service, and session identification
Integrated services (IntServ): using RVSP this results in deterministic reservation of network resources and QoS for
specific traffic and/or for specific IP flows
marking: to set the class of service or DSCP of a packet
metering: process of measuring the temporal properties (e.g. rate) of a traffic stream selected by a classifier
NOTE: The instantaneous state of this process may be used to affect the operation of shaping, or dropping.
Network Control Centre (NCC): equipment at OSI Layer 2 that controls the access of terminals to a satellite network,
including element management and resource management functionality
Per-Hop Behaviour (PHB): externally observable forwarding treatment applied at a differentiated services-compliant
node to a behaviour aggregate
policing: process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a
corresponding meter enforcing a traffic profile
Quality of Service (QoS): ability to segment traffic or differentiate between traffic types in order for the network to
treat certain traffic differently from others. QoS encompasses both the service categorization and the overall
performance of the network for each category.
NOTE: It also refers to the capability of a network to provide better service to selected network traffic over
various technologies and IP-routed networks that may use any or all of the underlying technologies.
QoS Parameters: parameters that will be specified or monitored to ensure QoS
service levels: end-to-end QoS capabilities of the network which will enable it to deliver a service needed by a specific
mix of network traffic
NOTE: The services themselves may differ in their level of QoS.
Service Level Agreement (SLA): agreement between a Service Provider (SP) and its subscriber (or between an SP and
an access network operator), characterized by the choice of one data transfer capability and the allocation attribute
related to this transfer capability
NOTE: An SLA can also include elements related to traffic policy and availability. It is agreed upon at the
initiation of the contract and normally remains the same for all the contract duration.
Traffic Conditioning Agreement (TCA): agreement specifying classifier rules and any corresponding traffic profiles
and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the
classifier
NOTE: A TCA encompasses all of the traffic conditioning rules explicitly specified within an SLA along with all
of the rules implicit from the relevant service requirements and/or from a DS domain's service
provisioning policy.
transfer capability: capability of transfer of information through a network
NOTE: This term can be used to characterize a telecommunications service or bearer.
user plane: plane with a layered structure that provides user information transfer, along with associated controls
(e.g. flow control, recovery from errors, etc.)
ETSI
10 ETSI TS 102 464 V1.2.1 (2015-12)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AF Assured Forwarding
AF/BE Assured Forwarding – Best Effort
AQM Active Queue Management
BA Behavior Aggregate
BE Best Effort
BoD Bandwidth on Demand
BSM Broadband Satellite Multimedia
BSM_ID BSM IDentifier
BSMQRM BSM QID Resource Manager
C2P Connection Control Protocol
CBWFQ Class Based Weighted Fair Queuing
COPS Common Open Policy Service
CS Class Selector
DAMA Demand Assignment Multiple Access
DiffServ Differentiated Services (IETF)
DS DiffServ
DSCP DiffServ Code Point
DVB-RCS Digital Video Broadcasting with Return Channel via Satellite
DVB-S Digital Video Broadcasting - Satellite
ECN Explicit Congestion Notification
EF Expedited Forwarding
EXP/LU Experimental / Local Use
FCA Free Capacity Assignment
HP High Priority
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
IntServ Integrated Services (IETF)
IP Internet Protocol
L2 Layer 2
LP Low Priority
MAC Medium Access Control
MF MultiField
MPE Multi-Protocol Encapsulation
MPEG Moving Pictures Expert Group
MPEG2-TS MPEG2 - Transport Stream
MS Management Station
NCC Network Control Centre
NSIS Next Steps In Signalling
OSI Open Standards Institute
PHB Per-Hop Behavior
PID Packet IDentifier
QID Queue IDentifier
QIDSPEC QID Qos SPECifications
QoS Quality of Service
RBDC Rate Based Dynamic Capacity
RC Request Class
RCST DVB-RCS Terminal
RED Random Early Detection
RFC Request For Comments
RSGW Regenerative Satellite GateWays
RSM-B Regenerative Satellite Mesh-B
RSVP Resource ReserVation Protocol
SD Satellite Dependent
SDAF Satellite Dependent Adaptation Functions
SI Satellite Independent
SIAF Satellite Independent Adaptation Functions
SI-SAP Satellite Independent-Service Access Point
ETSI
11 ETSI TS 102 464 V1.2.1 (2015-12)
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SP Service Provider
ST Satellite Terminal
STQRM ST QID Resource Manager
TCA Traffic Conditioning Agreement
TCP Transmission Control Protocol
ToS Type of Service
TSS-A Transparent Satellite Star-A
UDP User Datagram Protocol
VBDC Volume Based Dynamic Capacity
VCI Virtual Circuit Identifier
VPI Virtual Path Identifier
WFQ Weighted Fair Queuing
WRED Weighted Random Early Detection
4 Overview
DiffServ is an IETF solution to provide "scalable service differentiation on the Internet" [7]. Its main idea is to
aggregate IP flows by means of IP-layer packet marking using the DSCP (DiffServ code point) field of the IP header,
and to provide the aggregate with the same QoS level.
So within DiffServ domains, QoS treatments are only provided based on the DSCP marked in each packet's IP header.
In order to obtain a particular level of service, it is necessary to mark packet headers with the correct DSCP when the
packets enter the DS (DiffServ) domain. The correct DSCP is determined by pre-defined policies and SLAs, or
optionally set dynamically by means of signalling protocols (such as NSIS, RSVP, etc.). The IP packets (or flows)
marked with the same DSCP constitute a Behavior Aggregate (BA), and they receive from a DiffServ node the same
level of service, i.e. the same Per-Hop Behavior (PHB).
If the BSM system belongs to a DiffServ domain, PHBs have to be translated into QoS treatments that the packets
receive from one particular ST when they are forwarded over the satellite. So DSCPs need to be carefully mapped to SD
classes of service. Since SD classes are system dependent, it is necessary to abstract from the lower layers and to
provide the SI layers with a common and agnostic interface. For this reason central to the DiffServ capability, and more
in general to the QoS capability of BSM systems, is the concept of QIDs (Queue Identifiers) as outlined in ETSI
TS 102 462 [2] and ETSI TS 102 463 [i.14]).
QIDs represent the abstract queues available at the SI-SAP, they should be seen as an association between IP queues
used by DiffServ and layer-2 (L2) queues. Each QID offers a defined class of service for transfer of IP packets to the
SD layers. Thus QID are abstract queues in the sense that they can be seen as a mapping between IP and SD queues, but
they have real properties in the sense that they represent to the SI layers the real properties of the SD queues.
The satellite dependent lower layers are responsible for assigning satellite capacity to these abstract queues according to
the specified queue properties. The QID is not limited to a capacity allocation class, it relates also to forwarding
behaviour with defined properties. All these QID properties have an impact into the properties of the IP DiffServ queues
which the QID is associated to.
The BSM system will most likely be only a portion of the overall path traversed by packets which require end-to-end
QoS. The transmission from an ST to the satellite and down to another ST (or hub) is considered, at IP layer, as one
single hop, or at maximum as two hops, in case of a BSM mesh network topology where routing is performed on-board
the satellite. In a BSM system the single IP hop is shared among many STs, and this makes the QoS problem
challenging.
The present document will analyze the way to provide QoS only inside the BSM system, i.e. over one single IP hop, by
means of the DiffServ paradigm, and the most appropriate way to handle the SD resources. So the provision of
end-to-end QoS is out of the scope of the present document. It is assumed that the QoS treatment expected by each
particular IP flow or packet from the BSM is known to the BSM system by means of external information or signalling
(e.g. SLA). The BSM system will take this information into account in the SD resource management.
The satellite hop remains one single IP hop also in case of broadcast or multicast. This is a very important aspect which
makes the use of DiffServ over BSM system very powerful, and very simple with respect to terrestrial QoS-aware
multicasting, where the service level has to be monitored over a multicast tree, and thus along different paths.
Nevertheless DiffServ-aware multicast transmissions are out of scope of the present document.
ETSI
12 ETSI TS 102 464 V1.2.1 (2015-12)
For the sake of clarity, the following IETF definitions shall apply to the present document [11]:
• the Differentiated Services field (DS field) is the six most significant bits of the (former) IPv4 TOS octet or the
(former) IPv6 Traffic Class octet;
• the Differentiated Services Codepoint (DSCP) is a value which is encoded in the DS field, and which each DS
node should use to select the PHB which is to be experienced by each packet it forwards.
Thus the two least significant bits of the IPv4 TOS octet and the IPv6 Traffic Class octet are not used by Diffserv. They
have been assigned for use of Explicit Congestion Notification (ECN) [3] and so their use is out of scope of the present
document. DSCP markings may be used in the future to modify (or signal alternative semantics) for the operation of
ECN.
5 DiffServ BSM Functional Architecture
5.0 Aim and Scope
This clause clarifies the entities and functionalities involved in the QoS management process, when the DiffServ
paradigm is adopted. This DiffServ functional architecture is compliant with the one presented in ETSI TS 102 462 [2].
5.1 Overall BSM DiffServ Architecture
A BSM system may constitute part of a DiffServ domain, compliant with the architecture presented in IETF
RFC 2475 [7]. The domain is referred to as the BSM DS domain. The domain may extend beyond the STs, but in
general the satellite will be the critical part of the domain for the management of the resources in case of QoS provision.
The STs are the edge nodes of the BSM system, but they might be or not be the edge nodes of the BSM DS domain.
Figure 1 details the architecture shown in ETSI TS 102 462 [2], and highlights four possible scenarios for the BSM DS
domain topology, which are relevant to this discussion:
• case (1): ST directly connected to a BSM DS host;
• case (2): ST connected to a BSM DS router via one or more hops;
• case (3): ST directly connected to an external DS router;
• case (4): ST directly connected to a non-DS router.
In each of these cases the ST might need to perform different DS functions both in the user and in the control plane, this
is intrinsically linked to the way DS works. In particular in a DS domain the edge routers perform a number of
important operations: traffic classification, packet marking, traffic policing, traffic shaping, and, optionally, admission
control and resource reservation (see ETSI TS 102 462 [2], clause 8.1, for a detailed explanation of these mechanisms).
On the other hand DS core nodes only apply the appropriate PHB to IP packets based on the marked DSCP: IP packets
are forwarded to the appropriate IP queue (this operation can be defined as DSCP classification). So depending on
whether an ST is at the edge of the BSM DS domain or not, it might need to perform these operations or not. This will
be discussed in detail for the four cases in clause 5.2.1.
ETSI
13 ETSI TS 102 464 V1.2.1 (2015-12)
non-DS
network
R
BSM DS
host
DS domain
network
R (1)
host
(2)
R
ST
ST
R
DS
BSM R
network
R
G
ST
R
DS
(3)
network
R
ST
(4)
R
R
non-DS
non-DS
Network
Network
R
Router
ST
Satellite Terminal
G
Gateway (or Hub Station)
Figure 1: Possible scenarios of the BSM DS domain topology
Figures 2 and 3 show, for the four possible cases, the details of the ST protocol stack and its connections to external
entities.
BSM DS domain
host
ST#1 (or Gateway) ST#2 (or Gateway) Router
Applications
IP IP interworking IP interworking IP interworking
SI-SAP
SI-SAP
SLC & SLC &
SMAC
SMAC SMAC
Link#1 Link#1 Link Link Link
SPHY SPHY SPHY
case (1)
BSM
case (2)
Figure 2: ST details with respect to its location in the BSM DS domain, cases (1) and (2)
ETSI
14 ETSI TS 102 464 V1.2.1 (2015-12)
external DS domain BSM DS domain non-DS domain
Router
ST#1 ST#2 Router
IP interworking IP interworking IP interworking IP interworking
SI-SAP SI-SAP
SLC & SLC &
SMAC SMAC SMAC
Link Link#1 Link#1 Link#2 Link#2 Link
SPHY SPHY SPHY
BSM
case (4)
case (3)
Figure 3: ST details with respect to its location in the BSM DS domain, cases (3) and (4)
In general it is assumed that the satellite gateway (or the hub station) will not be an edge node of the BSM DS domain,
but it will be connected to routers which perform the required DiffServ border functionalities. For this reason the
gateway can only be found in cases (1) or (2) in the place of the ST. The operations to be performed by the gateway in
these cases will be also analysed in the next clause 5.2.1.
5.2 ST DiffServ Architecture
5.2.0 Overview
The operations which might be performed by a DiffServ node are: traffic classification, packet marking, traffic policing,
traffic shaping, DSCP classification, and, optionally, admission control and resource reservation.
Traffic classification, packet marking, traffic policing, traffic shaping, and DSCP classification can be considered
user-plane mechanisms. The remaining functions (admission control and resource reservation) can be seen as
control-plane operations. The relationship of these functionalities to the general protocol architecture of a DiffServ ST
is shown in figure 4.
As it can be seen in the figure, all user-plane functions are located above the SI-SAP, they are functions which are
present in all IP DiffServ nodes. On the other hand the control-plane functions are distributed across the SI-SAP and
require interactions of SI and SD layers.
ETSI
15 ETSI TS 102 464 V1.2.1 (2015-12)
IP data
IP signalling
USER PLANE CONTROL PLANE
Traffic Classification
Packet Marking
IPIP IP
Traffic Policing
clclaasssisiffiierer Admission Control
Resource
Traffic Shaping
& q& quueueuiinngg
Manager
DSCP classification
SI-SAP
QIDQID
ST QID
Resource
Manager
SD
SD SD L2 Admission Control
Resource
ququeueuiinngg L2 Resource Reservation
Manager
Figure 4: DiffServ-aware ST functional relationship to protocol layers and planes
5.2.1 DiffServ Functions
5.2.1.0 Introduction
In this clause the functions required in a DiffServ-aware ST are analyzed for each of the four scenarios presented in
clause 5.1. It should be noted that an ST (or more likely a gateway) may have multiple terrestrial interfaces, beyond the
satellite interface to the BSM system. On each one of the terrestrial interfaces the connection may represent one of the
four mentioned cases. So there might be the need for a single ST (or a gateway) to handle multiple scenarios
simultaneously. Since the different interfaces can be treated independently, this is not a problem, this can be realized by
applying the appropriate behaviour in each case, according to the indications given in the two following clauses 5.2.1.1
and 5.2.1.2.
5.2.1.1 User-Plane Functions
In the case the ST is directly connected to a host inside the BSM DS domain (see case (1) in figure 2), it is assumed that
the host operating system correctly marks the DSCP in the transmitted packets. This operation is commonly called "host
marking", and it can be done according to static or dynamic rules. Thus in this case the ST relies on the host for the
operations of traffic classification and packet marking. On the other hand the ST normally cannot rely on the host for
the purpose of traffic policing, and traffic shaping (if needed), so these functions shall be performed by the ST itself.
Case (1) is plausible in some specific scenarios, and, for the sake of completeness, it is addressed in this clause, but in
common practice end hosts should not be trusted when setting DSCPs.
In case (2) the ST is connected to another device in the same DS domain, which is not a host or an end system (see
case (2) in figure 2). In this case it is assumed that one edge router of the BSM DS domain takes care of all mentioned
user-plane functions. This applies either if the edge router is connected to another DS network and if it is connected to a
non-DS one. Of course the edge router might not be directly connected to the ST. This router will be configured to
identify IP flows, based on multifield (MF) classification, according to pre-defined criteria, and to consequently mark
the IP headers. This can be also done either statically or dynamically.
When the ST is not performing the marking itself, but it is relying on a trusted entity for that (the edge router, case (2),
or the host, case (1)), it may check the mark and change it, when necessary, but this is not mandatory: traffic
classification and packet re-marking are optional in these two cases for the ST. On the other hand in case (2) the ST
shall completely rely on the edge entity for the operations of traffic policing and shaping.
ETSI
16 ETSI TS 102 464 V1.2.1 (2015-12)
In the cases the ST is at the border of the BSM DS domain (cases (3) and (4) in figure 3), it has to perform all the
user-plane operations that are normally applied by edge routers in a DS domain. The difference between scenario (3)
and (4) is the following: In case (3), packets are coming from another DS domain, so they are marked, but these
markings might have a different QoS meaning; in case (4) packets are not marked, as they come from a DS-unaware
network. So in case (3) re-marking has to be performed by the ST, and traffic classification might not be necessary;
...