ETSI TS 102 294-2004 Satellite Earth Stations and Systems (SES) Broadband Satellite Multimedia (BSM) services and architectures IP Interworking via satellite Multicast functional a.pdf

1、 ETSI TS 102 294 V1.1.1 (2004-02)Technical Specification Satellite Earth Stations and Systems (SES);Broadband Satellite Multimedia (BSM)services and architectures;IP interworking via satellite;Multicast functional architectureETSI ETSI TS 102 294 V1.1.1 (2004-02) 2 Reference DTS/SES-00095 Keywords a

2、rchitecture, 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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of

3、 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).

4、 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

5、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 copyright and the foregoing restr

6、iction 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 currently being registered by ETSI for

7、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 294 V1.1.1 (2004-02) 3 Contents Intellectual Property Rights4 Foreword.4 Introduction 4 1 Scope 5 2 Void5 3 Definitions and abbreviations.5 3

8、.1 Definitions5 3.2 Abbreviations .5 4 BSM multicast framework .6 4.1 Basic concepts 6 4.2 Link to the generic BSM architecture.7 4.2.1 Multicast over different BSM topologies8 4.3 BSM multicast-specific protocol stack.9 4.4 Multicast services over the BSM10 5 Multicast protocols over the BSM11 5.1

9、Adaptation 11 5.2 Proxying .11 5.3 IGMP over BSM 11 5.4 BSM multicast routing .14 5.4.1 Sparse-mode protocols over BSM 14 5.4.2 Other multicast routing protocol adaptation .16 5.5 Multicast address resolution.16 5.6 Service discovery .16 6 Scenario16 Annex A (informative): SI-SAP multicast mapping f

10、or DVB networks17 Annex B (informative): BSM multicast options.18 Annex C (informative): Bibliography.19 History 22 ETSI ETSI TS 102 294 V1.1.1 (2004-02) 4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information per

11、taining 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 Secre

12、tariat. 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

13、 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 IETF IP multicast protocols, in particular th

14、eir signalling characteristics, are often not well suited to the specifics of BSMs, as discussed in TR 102 156. The present document defines the functional architecture that is going to be used to specify how and where IP multicast protocols need to be “adapted“ to be better suited to the BSM enviro

15、nment. This architecture relies heavily on the generic BSM Architecture Technical Specification TS 102 292; it does not use satellite specifics, is based on client server architectures and does not interfere with standard IP protocols and Internet operations. It applies the BSM architecture to a spe

16、cific application, multicast. Hence it provides both a test case for the architecture and a framework for the TSs that will specify the protocols ensuring multicast services can be provided efficiently over BSM networks. ETSI ETSI TS 102 294 V1.1.1 (2004-02) 5 1 Scope The present document presents a

17、 functional multicast services architecture bringing together the previous BSM TRs on Standardisation (see TR 101 984 and TR 101 985) and Multicasting (see TR 102 156) and the TS on BSM Functional Architecture (see TS 102 292). It also links in a common framework the current Work Items on Multicast

18、Protocols over the BSM. Finally, it provides a functional structure to the subsequent Multicast Technical Specifications (TSs) to be produced by the SES Technical Committee. The focus of the present document is on the IP version 4 (IPv4) protocols; this is consistent with the other protocol work per

19、formed in the BSM working group. 2 Void 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: adaptation: process of adapting standard protocols for better performance over a satellite (or other) subnetwork architecture:

20、abstract representation of a communications system BSM multicast session: instance of a multicast session that originates and terminates within BSM elements (STs, gateways) function: any discrete element that forms a defined part of an architecture multicast group: multicast IP address to which host

21、s may subscribe multicast session: specific instance of multicast communication proxy: function that intervenes between a source and destination and performs that function as an intermediary for the remote devices in each direction scenario: predicted sequence of events snooping: function associated

22、 with a layer 2 switch or bridge that intervenes on a given layer 3 protocol between a source and destination 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: 3GPP Third Generation Partnership Project BSM Broadband Satellite Multimedia CBT Core Based Tre

23、es CSF Client Server Function DHCP Dynamic Host Configuration Protocol DRM Digital Rights Management IETF Internet Engineering Task Force IGMP Internet Group Management Protocol INT Internet Notification Table IP Internet Protocol IPv4/v6 Internet Protocol version 4/6 LAN Local Area Network MLD Mult

24、icast Listener Discovery ETSI ETSI TS 102 294 V1.1.1 (2004-02) 6 MMT Multicast Mapping Table (DVB-RCS) PID Packet IDentifier PIM-SM Protocol Independent Multicast - Sparse Mode QoS Quality of Service RFC Request For Comments SD Satellite Dependent SDAF Satellite Dependent Adaptation Functions SI Sat

25、ellite Independent SIAF Satellite Independent Adaptation Function SI-C-SAP Satellite Independent - Control plane - Service Access Point SI-M-SAP Satellite Independent - Management plane - Service Access Point SI-SAP Satellite Independent - Service Access Point SI-U-SAP Satellite Independent - User p

26、lane - Service Access Point SLC Satellite Link Control SMAC Satellite Medium Access Control SPHY Satellite PHYsical SSM Source Specific Multicast ST Satellite Terminal USB Universal Serial Bus WG Working Group 4 BSM multicast framework The protocols that enable multicast over BSM are located in the

27、satellite independent part of the BSM stack. The mapping of these functions to layer 2 protocols, while essential for the operation of the BSM in multicast mode are beyond the scope of this architecture but will be addressed under other Work Items of the BSM working group. This architecture resides

28、within the Communication Services, which contains all the servers that will enable communication to and from the BSM and the Internet and where the BSM protocols are adapted to the outside world (see figure 1). 4.1 Basic concepts In addition to the definitions provided in clause 3.1 and the basic co

29、ncepts introduced in the Architecture TS 102 292 some concepts that are necessary to fully understand the BSM multicast services are further explained below: Adaptation: refers to the process of adapting standard protocols for better performance over, in the present document, a BSM satellite subnetw

30、ork. Adaptation, which should be transparent to the general Internet, involves, for example, changing timers, filtering traffic and reducing the transmission of messages over the satellite link to the protocol servers. Multicast proxying: refers to operations that are performed on behalf of other de

31、vices in order to improve performance or cost, for example. An IP layer proxy is a function that intervenes between a source and destination of IP packets that relate to a given IP protocol. For multicast group management an IGMP Proxy behaves as a single IGMP client on behalf of several downstream

32、hosts, and in the opposite sense as a local IGMP querier to these hosts on behalf of a remote querier. multicast session: specific instance of multicast communication by a multicast group defined by its transmission parameters, participants, and time of existence. In this context: - Applications ass

33、ociate a specific source address with a multicast session; the same destination address but with a different set of source will be viewed as a different group. - A group address may need to be interpreted by its scope in the sense that the same address could be used in different part of the network

34、independently an issue with BSM networks that cover access domains and multiple multicast offerings. snooping: function associated with a layer 2 switch or bridge that intervenes on a given layer 3 protocol between a source and destination. It learns about network behaviour from intercepted IP packe

35、ts and without explicit configuration as a network function (with IP address, etc.). ETSI ETSI TS 102 294 V1.1.1 (2004-02) 7 4.2 Link to the generic BSM architecture In the Architecture TS 102 292 the following interfaces are defined in figure 1: CSF-1: The interface between the IETF protocols and t

36、he Client function (internal to the IP layer). CSF-2: The interface between the peer IETF Client interworking functions. CSF-3: The interface between the Client function and the Server function(s). The multicast group management protocol is directly linked to the CSF-3 across the BSM even when using

37、 snooping or proxying because the protocol architecture is mostly at layer 3. Layer 2 operations related to reverse address resolution and packet replication or higher layer network management function are only described here as they relate to architectural scenarios. Communication Segment User serv

38、ices segment User services segment End System USB Or Ethernet IP SI SD (family) SD (family) USB Or Ethernet IP SI SD (family) End System CSF-2 CSF-1 CSF-1 Communications Services Segment SD (family) CSF -3 CSF-3 IP SI Figure 1: BSM architecture In terms of multicasting the BSM architecture can be us

39、ed to define main functions such as: multicast routing and group management; address resolution/translation; and security. These run over the CSF-3 interface and are located mainly above the SI-SAP. The generic BSM multicast architecture is shown in figure 2. ETSI ETSI TS 102 294 V1.1.1 (2004-02) 8

40、Source R R R H H R Protocol Adaptation Upstream Router ST Local Gateway Downstream Transit Router(s) Multicast Routing Protocol Source Source R R ST Local Gateway H H H BSM Coverage Figure 2: BSM generic multicast architecture In clause 4, the multicast architectures that are going to be the basis o

41、f the proposed TSs are introduced. For each of the recommended protocol, a TS specifying the manager or the “adaptation“ of the protocol and located in the appropriate server (in the appropriate domain) will be defined in relation with the BSM. Both BSM specific modules and IETF standard modules are

42、 illustrated for completeness. 4.2.1 Multicast over different BSM topologies Multicast protocols over the BSM may operate differently over the different BSM families. The use of double hops for transmitting multicast information should be avoided where possible, for example by adding adaptation of p

43、rotocols over meshed networks, but may be un-avoidable in some cases. The main difference between the mesh network and star network topologies is with packet forwarding and replication: in a star network the hub becomes de facto the virtual source of all multicast traffic. In this configuration all

44、external sources appear as sources at the hub and all clients first forward their packet to the hub for redistribution. In a mesh topology any ST can be the multicast source. Hence at the BSM level, two instances of multicast can happen: single source or origination multicast (via a gateway at the h

45、ub) - this is for star network topology where all BSM multicast sessions originate at the gateway (or a single ST); the actual “source“ can be anywhere; and multiple source or origination: any ST can be the root node of the BSM multicast session given it is connected to the IP multicast source or re

46、ndezvous point; any such ST that can transmit data to a particular multicast session; a destination ST is a leaf node of the multicast session and is an ST that receives data from a particular multicast session; this will necessitate double hops on the data path (via the hub) in all BSMs that do not

47、 have onboard processing. ETSI ETSI TS 102 294 V1.1.1 (2004-02) 9 4.3 BSM multicast-specific protocol stack Figure 3 presents the BSM protocol stack specific to multicast; it is taken directly from the BSM functional architecture (see TS 102 292). Figure 3 shows how the basic set of functions and SI

48、-SAP primitives for unicast Internet connectivity is complemented by multicast specific functions. They correspond to the recommendation of the multicast TR 102 156 for future work in BSM multicast, namely in the Satellite Independent layers: BSM Multicast Group Management; BSM routing; BSM Multicas

49、t Address Resolution; and Multicast Security. Because of the nature of the BSM, some of these functions, most notably for routing and group management, will necessitate adaptation for better performance with BSM delays and transmission/reception characteristics. Multicast, like unicast functions such as DHCP or web access, uses local proxies in the requesting hosts to reduce the control traffic load. In the BSM this reduction of traffic is important over the air interface and proxies will be used in addition to protocol adaptation. Proxies, ess