1、 ETSI TS 102 293 V1.1.1 (2004-02)Technical Specification Satellite Earth Stations and Systems (SES);Broadband Satellite Multimedia (BSM)services and architectures;IP Interworking over satellite;Multicast group management;IGMP adaptationETSI ETSI TS 102 293 V1.1.1 (2004-02) 2 Reference DTS/SES-00088
2、Keywords broadband, interworking, IP, multimedia, 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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Impo
3、rtant 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 th
4、e 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. Info
5、rmation 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, send your comment to: editoretsi.org Copyright Notification No part may be reproduced except as authorized by written permission. The
6、copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2004. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks curren
7、tly being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 293 V1.1.1 (2004-02) 3 Contents Intellectual Property Rights5 Foreword.5 Introduction 5 1 Scope 6 2 Referenc
8、es 6 3 Definitions and abbreviations.6 3.1 Definitions6 3.2 Abbreviations .7 4 Overview and summary7 4.1 Background 7 4.2 Need for IGMP adaptation .7 4.3 IGMP modes 8 4.4 Advantages of S-IGMP solution 8 4.5 Influence of IGMP proxies, etc. .8 5 Applicability and assumptions .8 5.1 Use of IGMP in BSM
9、multicast architectures 8 5.2 IGMP modes and multicast routing protocol options.9 5.3 IGMP network architecture applicable to BSM .10 5.4 IGMP-specific BSM functional model.10 5.5 IGMP issues in a satellite system .11 5.6 IGMP messages11 6 S-IGMP specification.12 6.1 General .12 6.2 S-IGMP client 12
10、 6.3 S-IGMP router (querier).13 6.3.1 Overall querier state diagram13 6.3.2 Router state diagram in querier mode.14 6.3.2.1 Parameter definitions 15 6.3.3 Detailed S-IGMP specifications .15 6.3.3.1 Additional state “reports reception disable“15 6.3.3.2 Modified timer value.15 6.3.3.2.1 Query respons
11、e interval.15 6.3.3.3 Modified actions .15 6.3.3.3.1 “Start timer*“ action 15 6.3.3.3.2 “Start retransmit timer“ action.15 6.3.3.4 Additional actions .16 6.3.3.4.1 “Resend report“ .16 6.3.3.4.2 “Send group specific query (max eff)“ 16 6.3.3.4.3 “Send group specific query(0,1)“ 17 6.3.3.4.4 “N member
12、 +“17 6.3.3.4.5 “N Member -“ 17 6.3.3.4.6 “N Member 0“ .17 6.3.3.4.7 “Start disable_timer“17 Annex A (informative): Description of S-IGMP18 A.1 Outline of IGMP.18 A.1.1 Dynamic vs. static routing18 A.2 IGMP issues in a satellite system.18 A.2.1 IGMP message flooding.19 A.2.1.1 Numerical examples of
13、adaptation impact19 A.2.1.2 Impact of limiting the retransmitted report burst 20 ETSI ETSI TS 102 293 V1.1.1 (2004-02) 4 A.2.2 Latency of stopping multicast transmission .21 A.2.2.1 Adaptation solution for latency.21 A.2.2.1.1 Max_Response_Time tuning.21 A.2.2.1.2 Rexmt tuning.21 Annex B (informativ
14、e): Description of scenarios for alternative versions of IGMP 22 B.1 IGMP querier interface modes and options22 Annex C (informative): Bibliography.23 History 24 ETSI ETSI TS 102 293 V1.1.1 (2004-02) 5 Intellectual Property Rights IPRs essential or potentially essential to the present document may h
15、ave 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 stan
16、dards“, 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 ot
17、her 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
18、 The general Service and Architecture aspects for Broadband Satellite Multimedia (BSM) systems are described in TR 101 984, IP-over-satellite aspects are described in TR 101 985 and functional models are defined for Quality of Service (QoS), Addressing, Routing and Multicasting. TR 102 156 develop t
19、he requirements for multicasting in further detail. The present document continues this theme by addressing an efficient solution for IPv4 multicast group management over BSM systems based on the definitions in the TR 101 984, TR 101 985 and TR 102 156. The specification of IGMP adaptation herein is
20、 based on results of the GEOCAST project of the ECs IST Programme. The IP multicast-over-satellite scenario described herein is also under consideration for the Amerhis project. ETSI ETSI TS 102 293 V1.1.1 (2004-02) 6 1 Scope The Internet Group Management Protocol (IGMP) is an integral part of IP an
21、d is required to be implemented by all hosts wishing to receive IP multicasts. The present document specifies modifications to IGMP which improve its performance when applied over satellite links. These modifications are internal to IGMP and do not affect the systems interoperability with IP. The mo
22、difications concern particularly the so-called “IGMPv2 mode“ (described in RFC 2236 2) which falls under the umbrella of IGMPv3 (RFC 3376 1). IGMPv3 offers automatic backwards reversion capability with the alternative IGMP modes. The adapted mode of IGMP is termed S-IGMP. This solution is suitable f
23、or multicast groups on geostationary satellite systems with two-way links. It is suitable for systems based on Any-Source Multicast (e.g. star networks) and especially for those which do not automatically retransmit IP multicast packets on return links to all group members. It is also beneficial to
24、systems which do have this ability for full subnet multicast. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication and/or edition number or versi
25、on number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. 1 IETF RFC
26、3376: “Internet Group Management Protocol version 3“ (IGMPv3). 2 IETF RFC 2236: “Internet Group Management Protocol version 2“ (IGMPv2). 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: multicast group: multicast IP
27、address to which hosts may subscribe proxy: function that intervenes between a source and destination and performs that function as an intermediary for the remote devices in each direction NOTE: For multicast group management an IGMP Proxy behaves as a single IGMP client on behalf of several downstr
28、eam hosts, and in the opposite direction as a local IGMP querier to these hosts on behalf of a remote querier. snooping: function associated with a layer 2 switch or bridge that intervenes on a given layer 3 protocol between a source and destination by learning about network behaviour from intercept
29、ed IP packets and without explicit configuration as a network function (with IP address, etc.) ETSI ETSI TS 102 293 V1.1.1 (2004-02) 7 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ASM Any-Source Multicast BSM Broadband Satellite Multimedia GES Ground
30、 Earth Station IETF Internet Engineering Task Force IGMP Internet Group Management Protocol IP Internet Protocol IPv4/v6 Internet Protocol version 4/6 LAN Local Area Network PIM Protocol Independent Multicast QoS Quality of Service RFC Request For Comments SDAF Satellite Dependent Adaptation Functio
31、n SI Satellite Independent SIAF Satellite Independent Adaptation Function SSM Source-Specific Multicast ST Satellite Terminal STF Special Task Force UES User Earth Station 4 Overview and summary 4.1 Background Clause 4 provides a general description of the background and choices for IGMP adaptation.
32、 The BSM system is intended to interwork seamlessly with IP networks. In the case of IP multicast, group management protocols for local hosts on the satellite segment need to be interfaced with the relevant routing protocols on the external part of the network, to ensure dynamic configuration of mul
33、ticast routes. The present document defines how IGMP needs to be adapted to suit the BSM environment, whilst maintaining the same external interface and behaviour towards IP. The adapted mode of IGMP will be termed S-IGMP. The BSM network and protocol architecture relies on the generic BSM architect
34、ures in TR 101 985. The background to BSM IP multicast interworking is described in TR 102 156. Applicable BSM IGMP multicast architectures are described in TS 102 294. 4.2 Need for IGMP adaptation IGMP is used as the basis for IP multicast forwarding across a local network attached to a multicast r
35、outer. IGMP is intended particularly for LANs with a shared (broadcast) medium, where every host can listen to IGMP reports sent by others, and where there is low delay. As satellite multicast groups become very large and dynamic, serious scalability consequences can arise. This is particularly true
36、 of typical satellite configurations where, even with two-way communications, the broadcast property generally exists only in the forward link; terminals cannot listen to direct or retransmitted reports from other terminals to suppress redundant reports. The IGMP querier located at the gateway route
37、r may then receive thousands of reports from the STs (hence the name “IGMP flooding“) leading to a waste of bandwidth as well as high processing power demand at the querier. Another problem is significant waste of traffic resources due to latency in stopping multicast group transmissions when member
38、s have left. The delay introduced in hosts reports to improve report suppression further degrades this latency. A mechanism to adjust the host delay for optimal latency without significantly affecting report suppression is defined. A more detailed explanation of the need for and choices of adaptatio
39、n is given in clause A.1. ETSI ETSI TS 102 293 V1.1.1 (2004-02) 8 4.3 IGMP modes IGMPv3 (RFC 3376 1) is the currently avalaible version of the protocol, but it can be configured, or can reconfigure itself automatically depending on its IGMP client versions for each group and interface, to operate in
40、 one of: 1) IGMPv3 native mode: - intended for interoperability with any-source multicast (ASM), with extensions for source-specific multicast routing protocols (e.g. PIM-SSM); - has scalability problems over large satellite multicast groups. 2) IGMPv2 mode: - intended for interoperability with a wi
41、de range of ASM routing protocols (e.g. PIM-SM). 3) IGMPv1 (RFC 1112) mode, for legacy applications. S-IGMP described herein concerns modifications to IGMPv2, or equivalently to the “IGMPv2 mode“ of IGMPv3. This version is chosen because it: is the most efficient IGMP mode in terms of signalling tra
42、ffic (allows report suppression); needs a minimum of adaptation for satellite use compared to IGMPv3 mode. 4.4 Advantages of S-IGMP solution The S-IGMP solution defined herein is designed for high performance and scalability consistent with: 1) High reuse of existing IGMP functions: - the IGMP clien
43、t functions are unchanged (existing IGMPv2 end-hosts and proxies, or this mode in IGMPv3 clients can be used); - the IGMP packets on the satellite link are fully consistent with IGMPv3 (RFC 3376 1). 2) Low implementation complexity: - only the IGMP querier function (in the router) is modified. A key
44、 feature of the adaptation is that the reuse of the existing IGMP packet format and standard IGMPv2 clients simplifies deployment of STs and user equipment. Only the behaviour of the querier is modified. Any adaptation of IGMPv3 mode with similar performance would require modified clients as well as
45、 queriers. 4.5 Influence of IGMP proxies, etc. Like many other IP functions, IGMP is often handled through proxy servers (or similar intermediaries) when a single interface to a local subnetwork is needed. Such IGMP proxies are common in the marketplace and require no modification if they are used a
46、t the client side of S-IGMP. (If they are used at the querier side of S-IGMP then they must implement S-IGMP instead of the source router). The present document does not therefore define the functions of such proxies (or snooping switches), but it describes their use in network architectures. 5 Appl
47、icability and assumptions 5.1 Use of IGMP in BSM multicast architectures A common scenario for IP multicast over satellites is the so-called “edge“ multicast network, in which only single hosts or small networks of hosts (i.e. “stub“ networks with no transit traffic) are attached to the remote STs a
48、nd are provided with multicast services via satellite from the Internet or from sources situated in other networks. ETSI ETSI TS 102 293 V1.1.1 (2004-02) 9 In this scenario a multicast router situated on one side of a satellite system needs to forward IP multicast packets to the remote IP hosts (or
49、multicast “receivers“). At the IP network level, this situation is very similar to the terrestrial multicast case concerning the multicast routers forwarding on an interface to its locally attached hosts. RUpstreamRouterSatelliteCoverageHHHRRRDownstreamTransit Router(s)Local “Gateway“RouterIGMPPROTOCOLMulticastRoutingProtocolSourceLocal hostsor networksPotential routesRHHostRouterFigure 1: Typical BSM edge IP multicast network scenario The “gateway“ multicast router may in general have one or more interfaces, as indicated, to local hosts as well as t
