ETSI TS 102 674 V1.1.1 (2009-11)

ETSI TS 102 674 V1.1.1 (2009-11)
Technical Specification


Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM);
PIM-SM Adaptation

---------------------- Page: 1 ----------------------
2 ETSI TS 102 674 V1.1.1 (2009-11)



Reference
DTS/SES-00291
Keywords
broadband, interworking, IP, satellite
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

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 2009.
All rights reserved.

TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being 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

---------------------- Page: 2 ----------------------
3 ETSI TS 102 674 V1.1.1 (2009-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 PIM-SM Scenarios in BSM . 8
4.1 Source and Rendezvous Point Scenarios . 8
4.1.1 Source and RP in Core Network . 8
4.1.2 RP and Source in Premises Network . 9
4.1.3 Source in Premises Network, RP in Core Network . 9
4.1.4 PIM-SSM, Source in Core Network (or in CPN) . 10
4.1.5 Conclusion . 10
4.2 PIM Processing Options over the BSM . 11
4.2.1 Scenario 1: Native PIM-over-Satellite . 11
4.2.1.1 BSM Link Architecture Impacts . 12
4.2.1.1.1 Star Architecture . 12
4.2.1.1.2 Hybrid Star-Mesh (Transparent) . 12
4.2.1.1.3 Hybrid Star Mesh (Regenerative Satellite) . 13
4.2.1.1.4 Mesh Architecture . 13
4.2.1.2 Mesh Join Ambiguity and Assert Process . 14
4.2.2 Scenario 2: Adapted PIM-over-Satellite (S-PIM) . 14
4.2.3 Scenario 3: PIM Snooping/Proxying . 15
5 BSM PIM Adaptation (S-PIM) . 15
5.1 S-PIM over BSM Functional Architecture . 15
5.2 Overall S-PIM Processing . 16
5.2.1 Case1: S-PIM with normal egress-initiated set-up . 16
5.2.2 Case2: S-PIM with ingress-initiated set-up . 17
5.3 S-PIM Message Processing and Forwarding . 18
5.3.1 RP and BSR Processes (PIM Server, etc.) . 19
5.3.2 Other PIM Server functions . 19
5.3.3 S-PIM Prune Processing . 19
6 S-PIM Message Sequence Charts . 19
6.1 S-PIM (Case 1) . 19
6.2 S-PIM (Case 2) . 20
Annex A (informative): Configuration of PIM-SM over BSM . 22
A.1 S-PIM Layer 2 Forwarding . 22
A.2 Reduction of Hello messages . . 23
A.3 Reduction of periodic Join Messages . 23
A.4 Reduction of Overrun of Multicast Transmission on "Prune" failure . 23
A.5 Prune Message Impacts . 24
Annex B (informative): Bibliography . 25
History . 26
ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 102 674 V1.1.1 (2009-11)
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://webapp.etsi.org/IPR/home.asp).
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).
Introduction
PIM-SM is the mode of the PIM protocol most widely used in existing and proposed multicast routing applications
today. In the following discussion "PIM-SM" is understood to mean the messages and operation of this protocol.
The way in which PIM-SM may be carried over satellite is described herein. In particular, ways in which PIM-SM can
be adapted over satellite links are defined, which may lead to more efficient use of satellite resources.
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 102 674 V1.1.1 (2009-11)
1 Scope
The present document specifies the way in which PIM-SM multicast routing protocols may be used over satellite
systems. From the many possible scenarios for PIM-SM implementation over different network configurations, three
types of PIM scenarios are initially considered:
• Native PIM-over-Satellite;
• Adapted PIM-over-Satellite (S-PIM);
• PIM Snooping/Proxying.
In particular, an adaptation of the PIM-SM standard to a non-standard BSM-internal version of PIM (i.e. S-PIM) is
described. In addition, PIM-SM protocol configuration, and/or proxying needed to enable efficient operation over the
satellite system and the associated interworking with terrestrial networks is described.
The present document builds upon previous BSM documents referenced in annex B, and notably:
• TS 102 293 [4]: Multicast Group Management; IGMP adaptation.
• TS 102 294 [1]: BSM Multicast Functional Architecture.
• TS 102 461 [i.2]: Multicast Source Management.
The PIM-SM protocol [2] (including the PIM-SSM variant [3]) is the main subject of the present document since it is
most widely used in preference to other multicast routing protocols today.
PIM-SM over satellite is assumed to mean that PIM-SM relating to a given multicast flow is present at a BSM ingress
router and is processed by the BSM network in such a way that the PIM-SM relating to the same flow is also made
available to attached downstream networks at one or more BSM egress routers. It is also possible that PIM traverses the
BSM system but only IGMP is then available downstream from the BSM egress ST, but this configuration is considered
a minor variation as far as S-PIM is concerned and is not considered further here.
The PIM over BSM scenarios are outlined in [i.2] and in more detail in clause 4 below.
As PIM-SM is considered to be a control plane protocol, the main subject addressed by the present document function
is the "Multicast Control" function as outlined in [i.2], rather than multicast IP flows in the user plane.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
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.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TS 102 674 V1.1.1 (2009-11)
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TS 102 294: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM) services and architectures; IP interworking via satellite; Multicast functional architecture".
[2] IETF RFC 4601: "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)".
[3] IETF RFC 4607: "Source-Specific Multicast for IP".
[4] ETSI TS 102 293: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM) services and architectures; IP Interworking over satellite; Multicast group management;
IGMP adaptation".
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.2] ETSI TS 102 461: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Multicast Source Management".
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.
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
egress ST: ST at which an IP multicast flow (of user data) exits the BSM network
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.
ingress ST: ST at which an IP multicast flow (of user data) enters the BSM network
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 102 674 V1.1.1 (2009-11)
IP multicast: IP networking protocol that allows members of a specific host group to receive copies of the same IP
datagram, identified by a reserved multicast address as the IP destination address
IP multicast address: one of a range of IETF-defined addresses for multicast
NOTE: For IPv4 this corresponds to the range from 224.0.0.0 to 239.255.255.255.
IP host group: set of IP receivers for a given IP multicast group
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
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.)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASM Any-Source Multicast
BMAC BSM Multicast Access Control
BMS BSM Management System
BSM Broadband Satellite Multimedia
BSM_GID BSM Group IDentity
BSM_ID BSM IDentity
BSR BootStrap Router
CPN Customer Premises Network
C-RP Candidate-Rendezvous Point
EUG End User Group
FDMA Frequency Division Multiple Access
GID BSM Group ID address
GW GateWay
IETF Internet Engineering Task Force
IGMP Internet Group Message Protocol
INT Internet/MAC Notification Table
IntServ Integrated Services
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ISP Internet Service Provider
MAC Medium Access Control
MACC BSM Multicast Access Control Client
MACD Multicast Access Control-D
MACS BSM Multicast Access Control Server
MAM BSM Multicast Address Management
MAMC BSM Multicast Address Management Client
MAMS BSM Multicast Address Management Server
MAR Multicast Address Resolution
MBGP Multicast Border Gateway Protocol
MCM BSM Multicast Control Management
MCMC BSM Multicast Control Management Client
MCMS BSM Multicast Control Management Server
MER Multicast Edge Router
MGID Multicast Group Identification Number
MMT Multicast Mapping Table
MSDP Multicast Source Discovery Protocol
NCC Network Control Centre
NMC Network Management Centre
OBP On-Board Processing
OMCS On-demand multicast connection setup
OUI Organizationally Unique Identifier
PID Packet IDentifier
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 102 674 V1.1.1 (2009-11)
PIM Protocol Independent Multicast
PIM-ASM Protocol Independent Multicast - Any-Source Multicast
PIM-SM Protocol Independent Multicast - Sparse Mode
PIM-SSM Protocol Independent Multicast - Source Specific Multicast
QID Queue IDentifier
QoS Quality of Service
RP Rendezvous Point
RPF Reverse Path Forwarding
RSM-A Regenerative Satellite Mesh - A
SD Satellite Dependent
SDAF Satellite Dependent Adaptation Functions
SI Satellite Independent
SIAF Satellite Independent Adaptation Functions
SI-SAP Satellite Independent Service Access Point
S-PIM BSM Adaptation of PIM
SSM Source Specific Multicast
ST Satellite Terminal
UT User Terminal
VP Virtual Port
4 PIM-SM Scenarios in BSM
The scenarios described here represent the main ways in which PIM-SM can be employed and configured across a BSM
system, which together with its attached networks forms part of an overall IP network.
The two modes of operation of PIM-SM are Any-Source Multicast (ASM) and Specific-Source Multicast (SSM). For
example, Join messages in ASM specify only the Group address, G, (not the source address, S) as symbolised by the
couple (*, G), while Join messages in SSM specify (S, G). Join messages in ASM are forwarded up the tree towards the
Rendezvous Point router (RP), while in SSM they are forwarded to the Source.
ASM is often the default mode, and this mode can transition to the SSM mode during the multicast session.
The relative positions of source and RP for ASM mode play a role in the message flows across the BSM as described in
the following clauses.
4.1 Source and Rendezvous Point Scenarios
These scenarios describe ASM and SSM modes, and complement those described in [i.2].
4.1.1 Source and RP in Core Network
A typical scenario for BSM is where the BSM is used as an access network to the Internet and both the source and RP
are located in the core network.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 102 674 V1.1.1 (2009-11)
IP/Premises
ST/ BSM ST/ IP/Premises
Router/
network
Source network
Router RP Router Router
Receiver
Internet/Core
Internet/Core
Router
PIM ASM (*,G)
PIM SSM (S,G)
PIM Register

Figure 4.1: PIM-ASM mode, Source and RP in Core Network
The case of an RP located in the CPN with a source in the core is considered unrealistic, and is not discussed here.
4.1.2 RP and Source in Premises Network
In some cases a source may be located in, or attached to, the CPN. Any PIM messages from remote terrestrial network
routers would have to be forwarded over the satellite to the RP, leading to increased traffic over the BSM compared to
an RP located in the core network. The option for an RP located in the CPN may therefore be disabled for certain
sources or network configurations.
This scenario is, however, well suited to multicast trees solely within the satellite network.
IP/Premises
IP/Premises
network
network
ST/ BSM ST/
Receiver Source
Router Router Router RP Router
Internet/Core
Internet/Core
PIM ASM (*,G)
Router
PIM SSM (S,G)
PIM Register

Figure 4.2: PIM-ASM mode, RP and Source in Premises Network
4.1.3 Source in Premises Network, RP in Core Network
As indicated in the previous clause, this scenario avoids PIM messages from remote terrestrial network routers being
forwarded over the satellite. However, multicast data flows are forwarded by the source to the RP over the satellite
irrespectively of whether any receivers are interested in the source data. This may result in unnecessary capacity being
used.
PIM-SSM messages (instead of PIM-ASM) traverse the BSM from the RP to the source, or alternatively unicast
register-encapsulated multicast data is forwarded from the source to the RP.
Also it is not an optimal scenario for multicast confined to within the BSM to have an RP outside of the BSM, due to
the additional paths incurred.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 102 674 V1.1.1 (2009-11)
IP/Premises
IP/Premises
network
network
BSM
ST/ ST/
Receiver
Source
Router RP Router Router Router
Internet/Core
Internet/Core
PIM ASM (*,G)
Router
PIM SSM (S,G)
PIM Register

Figure 4.3: PIM-ASM mode, Source in Premises Network, RP in Core Network
4.1.4 PIM-SSM, Source in Core Network (or in CPN)
IP/Premises
BSM IP/Premises
ST/ ST/
Router/
network
network
Source
Router Router Router
Receiver
Internet/Core
Internet/Core
PIM SSM (S,G)

Figure 4.4: PIM-SSM, Source in Core Network
For SSM mode, only PIM-SSM messages traverse the BSM.
As far as the BSM is concerned, the case of a source located in the CPN is identical to this case in terms of PIM-SSM
message processing.
4.1.5 Conclusion
In the above scenarios, all BSM ST's are considered identical as is the case in a mesh network. In this case the BSM can
be considered symmetrical for PIM purposes, and the above scenarios can be reversed with respect to the BSM. Hence
the PIM messages can traverse the BSM identically in either direction.
In the case of a star BSM network including a hub station, the same considerations apply as above providing that ST's
and Hub Station have the same PIM functionality.
Both ASM and SSM mode messages should be similarly processed by the BSM without significant impact, as the main
difference between these messages is the explicit specification of the source address for forwarding Joins etc. instead of
the implicit RP address.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 102 674 V1.1.1 (2009-11)
4.2 PIM Processing Options over the BSM
Scenarios considered for PIM-SM processing within the BSM are:
1) The BSM ST's act as PIM routers to external and internal BSM system interfaces (i.e. Native PIM-over-
Satellite). The use of PIM-SM over the satellite implies that the ST PIM routers react dynamically and
transparently to requests from networks downstream from the BSM, and to other types of PIM messages from
both upstream and downstream networks. This also implies that connectionless IP routes are permanently
available across the satellite system, or can be set up within a short reaction time.
2) The BSM ST's act as PIM routers to external interfaces, and the PIM-SM protocol would appear externally to
transit the BSM system "transparently". Internally to the BSM an adaptation of PIM i.e. Adapted PIM-over-
Satellite (S-PIM), or an alternative protocol could be used.
3) No PIM routing is implemented in the BSM ST's, but PIM snooping or proxying may be implemented to
influence layer 2 switching, etc.
Since PIM is applied across the BSM network, the scenarios below are all considered to be of "Pull" type, in the
terminology of [i.2], and of either Star or Mesh link topology between ST's.
These scenarios are discussed further below.
4.2.1 Scenario 1: Native PIM-over-Satellite
In this scenario, standard PIM messages are assumed to be forwarded in their native form by STs as routers within BSM
networks. This clearly involves no adaptation of PIM in the sense of modification of the protocol compared to the
standard.
The way in which the BSM acts upon PIM messages may depend on the SISAP and lower layer protocols and examples
have been described in [i.2].
However, independently of such interactions, configuration of PIM within the bounds of allowed parameters may be
advantageous.
The impact of PIM messages is considered below.
The general categories of messages between PIM-SM routers are:
• Hello
• Join
• Prune
• PIM Assert
• PIM Register/Register Stop
• BSR messages
The PIM-SM protocol is relatively garrulous and requires overhead for regular message passing to maintain PIM router
state. This overhead may have unwanted impacts on a satellite system.
The Hello message is worthy of particular note, since it is sent when a multicast router starts up, and periodically
thereafter (at 30 s intervals by default), on each PIM-enabled interface. The Hello message allows a router to learn
about the neighbouring PIM routers on each interface, and perform other functions such as negotiating options. A router
must record the Hello information received from each PIM neighbour. The Hello message is sent to the
'ALL-PIM-ROUTERS' multicast group address.
The Hello message is therefore likely to generate most PIM signalling traffic in a satellite system in which typically
many egress routers are connected to each ingress router. Each message is at least 4 bytes long.
Also Join messages are typically sent regularly to keep alive the state. Each message is at least 7 bytes long.
Configuration of PIM-SM timers can be done to optimise performance over satellites and this is discussed in annex A.
ETSI

---------------------- Page: 11 ----------------------
12 ETSI TS 102 674 V1.1.1 (2009-11)
4.2.1.1 BSM Link Architecture Impacts
PIM requires bi-directional multicast forwarding, in that multicast packets must pass in both directions over satellite
links, because not only multicast user plane flows but also PIM control plane flows rely on multicast. This implies that
satellite L2 links in both directions (even if not inherently multicast) must be configured to support L3 IP multicast.
Therefore for PIM to function correctly, the BSM must be fully meshed between all ST's and Hubs, i.e. bidirectional L3
paths available between each BSM ST/router to all other neighbouring ST/routers.
4.2.1.1.1 Star Architecture
The Hub has multicast L2 links to STs in the forward direction, but the STs do not generally have direct multicast links
in the return direction to the Hub and all other STs. The return links can be made into multicast links effectively by
rebroadcast of all PIM multicast flows received by the Hub on its satellite interface onto the forward link(s) (as well as
onto other interfaces). This creates double-hop multicast links from STs.
Return Forward
Link N Link
ST
PIM and
Multicast user data
ST
satellite
Hub
ST
forwarding

Figure 4.5: Forwarding in Hub for bidirectional PIM multicast
This architecture would give rise to multiplication of PIM messages over the satellite, but this is consistent with PIM.
4.2.1.1.2 Hybrid Star-Mesh (Transparent)
A way of avoiding such double hop links could be to use a hybrid satellite architecture using multicast satellite return
links in several ways e.g.:
1) One dedicated L1 or L2 multicast satellite return link is available for all ST's. This could be accessed using
ALOHA, for example, in a non-guaranteed way, which would be acceptable for PIM messag
...