Configuration note IP Multicast, SSM and Cisco IP/TV version 3.4 v1.0 7/02 ------------------------------------------------------------------------------ Index Introduction 1. An overview of Source Specific Multicast in IP/TV 3.4 1.1 The three benefits of SSM 1.2 SSM channel subscriptions (IGMPv3 / IGMPv3lite) 1.3 Understanding and selecting SSM address ranges 2. Configuring Cisco IOS IP Multicast with SSM in your network 3. Advanced Topics 3.1 RTCP receiver reports support in IP/TV 3.2 IP Multicast / RTCP specific SDP support in IP/TV 3.3 IP Multicast and SSM in the presence of L2 switches A. References B. Contact Introduction This document is directed to the network and IP/TV administrator with a basic background of IP multicast, and how it is being used in IETF standards compliant application like IP/TV (RTP, RTCP, SAP, SDR). The purpose of this document is to explain enhancements made to the support of IP multicast in Cisco IP/TV version 3.4 and how to use them in your network. The main enhancement with respect to IP multicast is the support for "Source Specific Multicast" (SSM). There are several other enhancements in IP/TV 3.4 over 3.2 unrelated to IP multicast but they are not discussed here [CCOiptv]. This document will explain the benefits addition, to this, IP/TV also added support to suppress RTCP multicast viewer feedback which is explained in section 3.1. 1. Source Specific Multicast and IP/TV 3.4 Source Specific Multicast (SSM) is an extension to the ip multicast service model. In Cisco IP/TV it is first supported with version 3.4. The following chapter gives an overview about how the traditional ip multicast service and SSM differ, and what the advantages of SSM are. You can use both SSM and the traditional ip multicast service within your network or either one exclusively. How to configure this is described further below. 1.1 The three benefits of SSM In the traditional ip multicast service, the IP/TV viewer application or for that matter any multicast receiver application simply joined to the multicast group G to receive traffic from the IP/TV server or any compatible multicast source/server application. In effect, the receiver application is requesting to receive traffic from any source sending to group G. Because of this behavior the traditional ip multicast service is also called ASM - Any Source Multicast [ASM]. In SSM, the receiver application must explicitly join to both the ip multicast group G and the known source S. It will then only receive the traffic sent by S to G. This is also called subscribing to the SSM (S,G) channel [SSM]. Note: Do not confuse an SSM channel with the IP/TV concept of an IP/TV channel which is a form of organizing session. SSM was developed and is supported to solve three main issues and limitations of ASM: 1. Source based DoS attacks A receiver in ASM is subject to denial of service attacks by illegitimate sources. For example S is the IP address of a valid IP/TV server sending a program to group G. , An attacker with a different IP address S' may simply send large amounts of traffic to G, which will be forwarded to all receivers that want to only listen to the valid IP/TV server S. Even though the IP/TV viewers will filter traffic from such sources, that traffic will still have been forwarded through the network and may have even caused disruption of service due to link congestion. In ASM, this problem can only be solved through tight network access control on the edges or on the PIM Sparse-Mode Rendezvous Point, but it is always an additional administrative effort. In SSM, this kind of attack is impossible because the receivers (S,G) channel subscription request is in SSM propagated throughout the network, so traffic from an illegitimate source S' will in SSM not be forwarded. Note: one current exception to this rule exists if the illegitimate source S' is on the same ethernet as the receiver. See the chapter on L2 switches below. 2. Complexity The currently most scalable, reliable and resilient solution for the traditional IP multicast service is PIM Sparse-Mode together with static, AutoRP or BSR derived configuration of Rendezvous Points (RPs) and MSDP (Multicast Source Discovery Protocol) for interdomain IP multicast connectivity and/or so "anycast" redundancy of RPs. RPs, AutoRP, BSR and MSDP constitute 90% of the management and operational complexity of the ASM IP multicast service. They are not needed for SSM. The routing protocol needed for SSM is simply a subset of PIM Sparse-Mode, which is called PIM-SSM and which does not require any RPs or MSDP. In a network where all applications are capable of SSM it is thus not necessary to configure any RPs, AutoRP, BSSR or MSDP. An example of such a deployment is a network where only SSM capable or enabled applications like IP/TV 3.4 are used together with IP Multicast. Even if it is necessary to still maintain or even newly deploy the traditional IP multicast service, those applications like IP/TV that can rely on SSM will not be subject to the most common operational misconfiguration issues related to RPs, AutoRP, BSR or MSDP resulting in lower operational and maintenance costs for these applications in the network and higher availability. 3. Address allocation When a session is to be broadcasted across the Internet or in general between independently operated networks, address assignment to sessions becomes an issue. There are no large blocks of global ip multicast addresses that can be requested for permanent exclusive use by a program. In result, it is often difficult to ensure that no one else is using a particular global scope ip multicast address. Even when using administratively scoped IP multicast addresses (239.0.0.0...239.255.255.255), the address assignment collisions will happen if multiple regions that previously where separate are now joined. A typical example is a merger or acquisition of companies. In SSM, the effective address is that of an SSM (S,G) channel. The IP source address S of the source is part of this address and makes it thus unique against any possible collisions in which some other source S' is sending traffic to the same group G: (S,G) and (S',G) are in SSM always independently forwarded between routers. This is not only the behavior that prevents source based DoS attacks, but it also allows for each source S to independently determine which groups G it wants to send traffic to - without the need to coordinate this with other sources. Note: See the chapter on L2 switches below. 1.2 SSM channel subscriptions (IGMPv3 / IGMPv3lite) ASM relies on IGMP for hosts to signal IP multicast group membership to the directly connected router. Currently most host operating systems support IGMP version 2 [IGMPv2]. IGMP version 3 adds the ability for hosts not only to report the group(s) they want to join, but also the source(s) [IGMPv3]. SSM relies on hosts doing exactly this: Using IGMPv3 to report both group and source. IGMPv3 is an IETF standards track protocol and its use for SSM is also an IETF standards track solution. IGMPv3 is supported in Cisco IOS starting with version 12.0(15)S, 12.1(8)E, and 12.2 and routers from other vendors. On a host, IGMPv3 is an operating system feature that in Microsoft Windows is supported starting with Windows-XP. Previous versions of Microsoft Windows do only support IGMPv2. IGMPv3 is or will also be supported on other operating systems supporting IP/TV compatible receiver applications like the MBone tools (for example FreeBSD). To be able to support SSM with IP/TV (or other applications) on older Microsoft Windows platforms, Cisco has developed a transition solution called IGMPv3lite, which is bundled with IP/TV 3.4. IGMPv3lite allows all older versions of Microsoft Windows (98SE, NT, 2000, ME) to utilize SSM. IGMPv3lite is based on a simple library-level implementation of IGMPv3 called HSIL - "Host Side IGMP Library" which utilizes UDP encapsulated IGMPv3 messages to avoid the often problematic raw socket API on hosts. When installing IP/TV viewer or streamwatch applications on anything but Windows-XP systems, the HSIL will also be installed. This can easily be recognized by the small blue shaded "v3" logo icon in the lower right corner of your Windows desktop. The router connecting to the host must support and be configured for IGMPv3lite for it to be effective. Cisco IOS versions that support IGMPv3 also support IGMPv3lite. A sample configuration is shown below. In IP/TV only the viewer and the streamwatch client need to join to a multicast group or subscribe to an SSM channel. The content manager and server do not join/subscribe, so they do not need to use IGMPv3 or IGMPv3lite at all. The section on SDP describes how IP/TV viewer and streamwatch applications learn of SSM channel information. 1.3 Understanding and selecting SSM address ranges Co-existence and easy migration from ASM to SSM have been the mayor design criteria for SSM. In Cisco IOS (and other vendors router products), you can configure the IP multicast address ranges to be used with SSM as you can configure IP multicast address ranges for the different protocols that can be used for ASM - In Cisco IOS these are PIM Sparse-Mode (PIM-SM), Bidir-Mode (Bidir-PIM) and Dense-Mode (PIM-DM). SSM is simply a fourth alternative. To start using SSM within your network, you need to designate IP multicast address ranges to be used with SSM. IANA (Internet Assigned Number Authority) has designated the IP multicast address range 232.0.0.0...232.255.255.255 as the global scoped address range to be used for source specific protocols. Because of this assignment, this range is in the IP/TV content manager hard wired for SSM and referred to as the SSMGlobalScope range. If you want to use SSM for administratively scoped scheduled programs - for example across an enterprise network but not beyond, then you must select a sub-range of the 239.0.0.0/8 address range to be your administratively scoped SSM address range. You can configure this address range in the IP/TV content manager, it is called the SSMAdminScoped range. Note: You can NOT run administratively scoped SSM programs within the SSMGlobalScope address range because this would cause a conflict of access-control: If you select to configure a subrange of the 232.0.0.0/8 address range for your administratively scoped programs, then you would want to filter this subrange at your scopes boundary router but you can not do this, because scoping is only based on group-address ranges: If you enforce filtering, you will also filter out random external global scope SSM programs that you may want to receive. even if you only want to have global SSM connectivity in the future, it is best not to forego the option of being able to use it in the future without a change of address plans. Cisco recommends to use 239.232.0.0/16 as the administratively scoped SSM range. This is already preconfigured but not activated in the IP/TV version 3.4 content manage preferences. You may want to change this address range if it conflicts with your prior address plans. If you need multiple administratively scoped SSM address ranges, then you should best configure the addresses of individual scheduled programs explicitly because IP/TV 3.4 does not allow you to configure multiple such administrative scopes. 2. Configuring Cisco IOS IP Multicast with SSM in your network Enabling SSM service within a network is simple if Cisco IOS is being used. See [CCOv3] and [CCOssm] for background infomation. This section gives a quick overview on that process. If you are using routers from a different vendor, please check out your documentation on the exact syntax to use in support of SSM. Note that IGMPv3lite is currently a Cisco proprietary protocol. The best approach to enable SSM in Cisco IOS is to consistently configure all your routers for the following commands: ip multicast-routing [ distributed ] ! Distributed on Cisco-7500/12000 ip pim ssm range ssm-range [1] ip access-list standard ssm-range [2] permit 232.0.0.0 0.255.255.255 ! Global scope SSM range permit 239.232.0.0 0.0.255.255 ! Cisco Recommended admin scope SSM range interface FastEthernet 0/0 description Access interface connected to PCs or other hosts ip address ... ip pim sparse-mode [3] ip igmp version 3 [4] ip igmp v3lite [5] [1] configures the router to operate the addresses within the "ssm-range" as SSM. What this means is that the router will only accept (S,G) channel subscriptions in this range (via IGMPv3, IGMPv3lite or URD), and that it will use PIM-SSM for these address ranges (a subset of PIM Sparse-Mode). It also means that the router will reject any PIM-SM RP or MSDP operations on these addresse ranges. [2] is simply a standard access-list defining the address range(s) to be used for SSM. In this example, the ranges are defined to be the recommended default ranges for global scope SSM and admin scope SSM as described above. [3] is the command to enable IP multicast on the interface. SSM will work across interfaces configured for either "ip pim sparse-mode" or "ip pim sparse-dense" mode. If you only plan to use SSM and no other multicast modes, use [3], otherwise simply keep "sparse-mode" or "sparse-dense" mode as already configured on your routers. SSM will not work across an interface configured for "ip pim dense-mode" ! [4] and [5] enable IGMP version 3 and IGMP v3lite. You need to enable IGMP version 3 in support of SSM for systems that support native IGMPv3 like Windows XP with IP/TV. You need to enable IGMP v3lite in support of systems that do need to use IGMP v3lite like Windows 98 or 2000. It is not necessary to configure [4] or [5] on any interface where no hosts are connected to - like pure backbone interfaces - but it is also not wrong to configure it (it just saves a line in the config and can be useful to inhibit that hosts incorrectly connected to a backbone interface will be able to use SSM). If you are connecting to the Internet then your access router to the Internet should filter out any administratively scoped addresses as required via the "ip multicast boundary command": ip multicast-routing [ distributed ] ! Distributed on Cisco-7500/12000 ip pim ssm range ssm-range ip access-list standard ssm-range permit 232.0.0.0 0.255.255.255 permit 239.232.0.0 0.0.255.255 ip access-list scoped-groups [1] deny ip any host 224.0.1.39 ! AutoRP deny ip any host 224.0.1.40 ! AutoRP deny ip any 239.0.0.0 0.255.255.255 interface Serial0/0 description Connection to the ISP border router ip address ... ip pim sparse-mode ip pim bsr-border [2] ip multicast boundary scoped-groups [3] In this example configuration, interface Serial0/0 connects to an ISP border router. Because there are no hosts on this interface, we do not need to configure IGMPv3/v3lite (but it wouldn't hurt to do - it is simply not configured to keep the config as small as possible). [3] is the multicast boundary that will filter out all administratively scoped addresses, which includes the 239.232.0.0/16 range that we defined, but it will allow traffic for 232.0.0.0/8 through (global scope SSM) like it will also allow global scope ASM groups. Filtering the two AutoRP groups added in [1] will inhibit any unwanted AutoRP announcements from the ISP to leak into the enterprise - if you need to receive those AutoRP announcements, you do of course need to remove these two lines from the access-list. For BSR, the equivalent filtering is [2] - if you need to pass BSR information from/to your ISP, then remove this line. If you only plan to use SSM, then this most likely is everything you ever need to know about configuring IP multicast routing configuration. If not, then see this simply as an addition to the already existing configuration that you have or need for ASM IP multicast in your network. If you have an already existing network with PIM-SM and want to introduce SSM gradually, then you can easily start configuring SSM as described above on the access-router connecting to SSM receiver hosts. The RP routers or other transit routers do not need to be configured for SSM as long as they already run PIM Sparse-Mode SSM range on the groups of the SSM range: SSM is completely backward compatible with PIM-SM in transit-hosts ! What this also means is that you may use SSM across an ISP network (in the global scope SSM range !) even if that ISP is simply providing PIM-SM and is not even aware of SSM: PIM-SSM is simply a subset of PIM-SM - which is why it is fully backward compatible. 3. Advanced Topics 3.1 RTCP receiver reports support in IP/TV RTCP (Real Time Control Protocol) is part of the IETF standard RTP (Real Time Protocol). The receiver report element of RTCP are packets sent by the receivers of a scheduled program to report their presence. These reports can be received by the IP/TV streamwatch application for troubleshooting or receiver analysis/statistics. According to the IETF standard for RTP, these RTCP receiver reports are to be sent out as multicast packets so that all receivers can see each others reports. One reason for this is to allow receivers to learn how many other receivers are present. Each receiver will then appropriately throttle the rate at which it will send RTCP receiver reports so that the aggregate data rate of RTCP receiver reports is limited to 5% of the actual sources stream bandwidth. This Multicast RTCP mechanism has two crucial limitations: The first is that it puts a heavy or unbearable load on the IP multicast service in the network. The second is that it can not usefully work together with SSM. With Multicast RTCP, each IP/TV viewer client becomes an active IP multicast traffic source, sending few but periodic packets to the IP multicast groups of the scheduled program. With PIM Sparse-Mode being used in the network, this causes an individual forwarding state for each receiver in the network. Especially with low-end and hardware accelerated IP multicast routers, the amount of state is often limited and RTCP receiver reports may overrun those routers abilities. In SSM, a receiver needs to explicitly subscribe to each active source, which makes Multicast RTCP receiver reports even more unpractical, because there is no mechanism for receivers to learn about the presence of other receivers - before they receive RTCP packets from them. To solve these issues, IP/TV supports Unicast RTCP receiver reports. In this variant, IP/TV viewers and streamwatch applications send their RTCP receiver reports as unicast packets to the IP/TV server for this scheduled program, which in turn multicasts them back to the IP multicast groups or channels used by the session. With this mechanism the IP/TV server is the only source for IP multicast traffic but it also allows for all all receiver applications and especially the streamwatch client to still receive those reports. Unicast RTCP is controlled via the variable AllowUnicastRTCP=1 in "\WINDOWS\iptv.ini". It will be used if it is set to 1 on both the IP/TV viewer/streamwatch and IP/TV server systems. Unicast RTCP and this option are supported beginning with IP/TV 3.1, but this variable (and as such Unicast RTCP) are enabled by default only starting with IP/TV 3.2. Unicast RTCP is backward compatible with systems that do not support it. If an IP/TV viewer receives a scheduled program not served by an IP/TV server, it will automatically use Multicast RTCP. Receiver clients that do not support Unicast RTCP can still receive all sessions announced by an IP/TV content manager, but they will simply continue to use Multicast RTCP. If ASM is being used then these reports will be seen by other receivers an possible streamwatch applications being run. When SSM is being used, then these reports will not be forwarded - in effect, you currently will not be able to account for non-IP/TV receiver clients via streamwatch if SSM is being used. There are efforts in the IETF to standardise a Unicast RTCP mechanisms. Beside Unicast RTCP which as described is already enabled by default and should never be disabled, the IP/TV content manager also supports two configuration options to actually suppress that receiver clients start sending RTCP receiver reports. To reduce the amount of traffic in the network caused by RTCP receiver reports, you should always enable these options (or either one of them) if you do not need the feedback. "Suppress Viewer RTCP Feedback (for large sessions)" Enable this option if you are not interested in RTCP feedback at all. It is only known to work for IP/TV receiver clients though. This option if enabled inserts a field in the SDP session description (see below) that will cause receivers to reduce their bandwidth for RTCP receiver reports to 0. Receiver clients that recognize this option will not generate any RTCP receiver reports - unicast or multicast. This option is recognized by IP/TV viewer clients starting with version 3.0. This option is not supported by third party application like the MBone tools though - these application will ignore the option in the SDP session description file and simply continue to send their receiver reports. This option is currently an IETF draft [RTCPbw]. "Suppress Viewer Multicast RTCP Feedback (for large sessions)" Enable this option if you want to protect the network against multicast RTCP feedback. You will still get Unicast RTCP feedback from IP/TV receivers. This option was added in IP/TV version 3.4. It must be used only if both IP/TV content manager and IP/TV server are running version 3.4 or newer. When this option is configured, the SDP session description will indicate that the TTL (Time To Live) of the session media is 1, and in addition, another option indicates to the IP/TV server the true TTL of the session. In effect, all receiver clients (IP/TV viewer or third party) will send out their multicast RTCP receiver reports with a TTL of 1, which effectively limits them to the network directly connected to the receiver host - this option will work for all known receiver clients and it will effectively inhibit multicast RTCP receiver reports to cause IP multicast state issues in the network - even if third-party receiver applications are used. Setting this option has no effect on Unicast RTCP receiver reports from IP/TV receiver clients. It is recommended to always set this option after the IP/TV server(s) have been upgraded to 3.4 unless Multicast RTCP receiver reports from non-IP/TV receiver clients must be received. Note: If this options is incorrectly set for an IP/TV server prior to version 3.4 (or third-party server), then that server will start sending the scheduled program streams with a TTL of 1, so the scheduled program can not be received beyond the first hop network! 3.2 IP Multicast / RTCP specific SDP support in IP/TV Session information is passed to the IP/TV viewer and streamwatch applications in the form of an SDP (Session Description Protocol) file. The applications can learn SDP session information in a variety of ways: 1. Content manager or compatible applications (like sdr) can broadcast SDP information via IP multicast and SAP. 2. The viewer / streamwatch application will periodically download session information from the configured content manager addresses via HTTP. 3. The viewer can be started as a helper application. In this case, the hotlink to start it is an file of type SDP which not only indicates to the browser to start the IP/TV viewer, but also to pass the SDP file as an argument to the viewer. 4. The viewer can be started as a plugin to the browser. In this case the SDP filename is explicitly specified as one of the arguments to the plugin. While SDP information has been used since the first version of IP/TV, version 3.4 enhances it in support of SSM and RTCP. The following examples will detail the fields that relate to IP multicast and how this has been enhanced in version 3.4 of the content manager. You can use the following information to troubleshoot SDP information created by the content manager or to verify if SDP information that may have been created outside of the content manager will be appropriately understood by the IP/TV viewer and streamwatch client. To see the SDP information of a Scheduled Program in the IP/TV client, right-click on the Scheduled Programs line in the main window and select "Program Information". A new window will pop up. In this window, click on the "More >>>" button. A new button "Advanced" will pop up. Click on this butting. A third window will pop up. In that window select the "SDP" tab. This will display the raw session information. Example 1: Standard address fields (irrelevant field in the SDP files have been replaced by ...) ... a=tool:IP/TV Content Manager 3.2 ... m=video 52380 RTP/AVP 31 96 32 97 [1] c=IN IP4 239.232.254.43/63 [2] a=... a=x-iptv-svr:video 172.19.210.24 live [3] ... m=audio 26792 RTP/AVP 0 ... [4] c=IN IP4 239.232.213.43/63 [5] a=... a=x-iptv-svr:audio 172.19.210.24 live [6] These are the most basic lines of the SDP file relating to the IP Multicast addresses and RTCP. [2] and [5] are the standard lines describing the IP multicast addresses and the TTL of the Scheduled Program, [1] and [4] have the UDP port numbers used by RTP. In this example, the video stream uses 239.232.254.43 on port 52380 and the TTL for the session is 63, the audio stream uses 239.232.213.42 on port 26792 and the TTL is also 63. These lines can be found on any ip multicast SDP file, whether it was generated by an IP/TV content manager or not. [3] and [5] are IP/TV specific extensions, defining the IP address of the IP/TV server sourcing this scheduled program. If this option is present, the IP/TV viewer and streamwatch application will use Unicast RTCP towards this IP address (if Unicast RTCP is configured - see above). Example 2: SSM lines added a=tool:IP/TV Content Manager 3.4.14 ... m=video 52380 RTP/AVP 31 96 32 97 c=IN IP4 239.232.254.43/63 [1] a=... a=x-iptv-svr:video 172.19.210.24 live >>> a=incl:IN IP4 * 172.19.210.24 [2] ... m=audio 26792 RTP/AVP 0 ... c=IN IP4 239.232.213.43/63 [3] a=... a=x-iptv-svr:audio 172.19.210.24 live >>> a=incl:IN IP4 * 172.19.210.24 [4] This example differs from the first one only by lines [2] and [4]. These lines indicate to the IP/TV viewer and other clients that it should use IGMPv3 INCLUDE mode joins to (172.19.210.24, 239.232.254.43) ([2], [1] for video) and (172.19.210.24, 239.232.213.43) ([4], [3] for audio). These two lines are inserted by IP/TV content manager version 3.4 or later whenever a sessions scope is configured to be SSMGlobalScope or SSMAdminScoped. If generated by the IP/TV content manager, these lines will always contain the same IP source address as the "a=x-iptv-svr" lines which may seem redundant: While the latter one are Cisco IP/TV specific, lines [2] and [4] are part of an IETF standards track draft defining how to specify IGMPv3 style memberships in SDP descriptions and may thus also be generated by third party products in the future [SDPfilt]. Example 3: RTCP suppression options added ... >>> b=RR:0 [1] ... a=tool:IP/TV Content Manager 3.4.14 ... m=video 52380 RTP/AVP 31 96 32 97 >>> c=IN IP4 239.232.254.43/1 [2] >>> a=x-iptv-ttl:63 [3] a=... a=x-iptv-svr:video 172.19.210.24 live a=incl:IN IP4 * 172.19.210.24 ... m=audio 26792 RTP/AVP 0 ... >>> c=IN IP4 239.232.213.43/1 [4] >>> a=x-iptv-ttl:63 [5] a=... a=x-iptv-svr:audio 172.19.210.24 live a=incl:IN IP4 * 172.19.210.24 In this example, [1] shows the line added to indicate the "Suppress Viewer RTCP Feedback (for large sessions)" option if configured. [2],[3] and [4],[5] show how the "Suppress Viewer Multicast RTCP Feedback (for large sessions)" is implemented. The TTL in [2] and [4] is set to 1 so that all receiver applications will only send out their RTCP receiver reports with a TTL of one, and in [3] and [5] the actual TTL for the IP/TV server is indicated. See the section "How IP/TV supports RTCP receiver reports" for more details. 3.3 IP Multicast and SSM in the presence of L2 switches CGMP and IGMP Snooping are mechanisms supported by products acting as layer 2 switches to filter IP multicast traffic within a switched ethernet. CGMP [CGMP] is a Cisco proprietary solution, IGMP Snooping is available in switches from different vendors. CGMP and IGMP Snooping are not necessary for IP multicast to work within the ethernet, they simply provide filtering of unwanted IP multicast traffic, which makes them only necessary if the amount of IP multicast traffic within an ethernet becomes so high that non-participating hosts may want to be protected from it. Nevertheless, on many products IGMP Snooping is enabled by default because it is supposed to be completely transparent to all operations. Unfortunately, this is not always the case with the introduction of IGMPv3. This chapter will explain how different types of filtering in layer 2 switches effects forwarding of IP multicast traffic, and how it especially affects the mechanisms used for SSM. o CGMP Switches Filtering of IP multicast traffic in CGMP switches is almost completely controlled by the router side of CGMP, i.e.: the router that has "ip cgmp" configured. If this router has a version of IOS that supports IGMPv3, then CGMP will also work together with IGMPv3 and thus SSM is supported. CGMP will only filter IP multicast traffic on a per MAC-group basis. o Legacy IGMP Snooping switches (IGMPv1/v2 only) These switches are an issue for SSM, because they do not support IGMPv3 and if enabled, they will prohibit SSM to work. The problem is that IGMPv3 messages sent by the receiver hosts are new messages that are not recognized by an IGMP snooping switch that only supports IGMP version 1 or version 2. The switch will still flood these messages to the router ports, but it will not understand them and not start forwarding the requested traffic towards the receiver host. This does not only apply to SSM traffic, but to all IP multicast traffic when IGMPv3 is used by a host. The only immediate solution if SSM is needed is to disable IGMP Snooping on these switches. In general, if IP multicast traffic only consists of a few IP/TV video streams, then disabling IGMP Snooping is appropriate unless there are system connected to the ethernet only via 10Mbps or less (eg: wireless), or systems that may be connected with 100Mbps ethernet but where the ethernet controller in the system can not filter out unwanted IP multicast traffic in hardware. This latter problem was only typical for a few vendors ethernet cards that are older than 4 years now. If SSM is not required, then the alternative is to configure the router on that ethernet to only use IGMP version 2, and not IGMP version 3. In this case the hosts will send IGMP version 2 reports, and IGMP Snooping in the switch will work correctly. This of course will inhibit SSM for hosts that support IGMPv3 like Windows-XP systems. They will switch back to IGMP version 2 and will thus not be able to receive IP/TV SSM channels anymore. It will also inhibit other details of IGMPv3 like for example explicit tracking of membership reports as supported in Cisco IOS 12.0S and 12.2T [CCOet]. Note that in Cisco IOS routers, IGMP version 2 is still the default because of this issue, as it not only applies to SSM channels but all IGMP reports sent by hosts supporting IGMPv3. Please be aware of this issue before enabling IGMP version 3 if you have host systems supporting IGMPv3 like Windows-XP. o IGMP Snooping with basic IGMPv3 support With this, IGMPv3 is supported in IGMP Snooping, but traffic is still filtering only on a per MAC-group basis (either because of hardware or current software limitations). The Cisco Catalyst 5000 and 6x00 series switches do have basic IGMPv3 support in IGMP Snooping starting with Cisco IOS 12.1(8)E and in CatOS stating with version 6.1. o IGMP Snooping with full IGMPv3 support If a switch implements IGMP Snooping with full IGMPv3 support, then this means that it will filter ip multicast traffic not only per MAC-group basis but effectively per IP multicast (S,G) channel. Catalyst 6x00 switches running CatOS 7.3 or later will provide full IGMPv3 support in their IGMP Snooping implementation. A L2 switch that implements per MAC-group filtering, can only filter IP multicast traffic based on the destination MAC address it is sent to. The MAC address is determined by the low-order 23 bit of the IP multicast address. For example all groups 224.0.3.4,224.128.3.4,225.0.3.4,... 239.128.3.4 use the same MAC destination address. If one host is joined to one such group and another host on the same ethernet to another group in this list, then both hosts will receive traffic sent to both groups. In CGMP and most IGMP Snooping switches, this is a hardware limitation. SSM does not change this behavior. Traffic to different SSM channels (S1,G1) and (S2,G2) will be forwarded to the same ports as long as the IP multicast group addresses G1 and G2 map to the same MAC address. Because of this, it is prudent to still use group addresses that are different from each other at the MAC level for different IP/TV sessions. This will avoid possible unwanted IP multicast traffic towards hosts. In addition, this purely MAC-group filtering will also allow allow sources on the same network as the receiver to still run a source DoS based attack against these receivers. Such an attack will of course not be propagated beyond the first-hop router, so it is but a small issue compared to the situation in ASM. These two current limitations can only be avoided by moving IGMP Snooping in switches to fully support IGMPv3 in the future. IGMPv3lite and switches: If a host uses IGMPv3lite to subscribe to an (S,G) channel, then it will send IGMPv1 or IGMPv2 join messages for G and and in addition UDP encapsulated IGMPv3 messages to subscribe to (S,G). In a switched LAN with CGMP or IGMP Snooping switches, the UDP encapsulated IGMPv3 messages will be flooded to the router ports and the switches will forward traffic based on the IGMPv1 or IGMPv2 join messages. In result, IGMPv3lite will always work - even with legacy IGMP Snooping switches that only support IGMPv1/v2. There are restrictions on IGMPv3lite: It does currently not support explicit tracking or fast leave of groups and in IP/TV 3.4 it will not be used on hosts that can support IGMPv3 (eg: IGMPv3lite will not be used on Windows XP or later). A. References RFCs can be found on http://www.ietf.org. IETF drafts can also be found theree, but only for a period of 6 months after which they will either time out, be superceded by a never version of the draft or become an RFC. If you can not find a draft listed below on the IETF web page, please refer to the list of RFCs and search the same content via the title. If the draft simply timed out without having been renewed, you may find the exact referenced drafts on ftp://ftpeng.cisco.com/ipmulticast/drafts. [ASM] "Host extensions for IP multicasting", S.E. Deering, RFC1112 [CCOssm] "Source Specific Multicast with IGMPv3, IGMP v3lite, and URD", Cisco IOS Feature documentation, http://www.cisco.com/univercd/cc/td/doc/product/software/ ios120/120newft/120limit/120s/120s15/12s_ssm.htm [CCOet] "Explicit Tracking of Hosts, Groups and Channels for IGMP Version 3", Cisco IOS Feature documentation, http://www.cisco.com/univercd/cc/td/doc/product/software/ ios120/120newft/120limit/120s/120s19/12s_xtrk.htm [CCOiptv] IP/TV 3.4 documentation on CCO. http://www.cisco.com/univercd/cc/td/doc/product/webscale/ iptv/iptv34/index.htm [CCOv3] "IGMP Version 3", Cisco IOS Feature documentation, http://www.cisco.com/univercd/cc/td/doc/product/software/ ios120/120newft/120limit/120s/120s15/12s_igmp.htm [CGMP] "Cisco Group Management Protocol (CGMP)", D. Farinacci, A. Tweedly, Cisco protocol description, ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt [FtpSSM] ftp://ftpeng.cisco.com/ipmulticast/ssm/index.html This is the Cisco IOS Multicast engineering homepage for SSM. You can find pointers to all SSM related topics here, especially the full IGMPv3lite HSIL software. [IGMPv2] "Internet Group Management Protocol, Version 2", W. Fenner, RFC2236 [IGMPv3] "Internet Group Management Protocol, Version 3", B. Cain, ..., IETF draft-ietf-idmr-igmp-v3-11.txt [RTPCbw] "SDP Bandwidth Modifiers for RTCP Bandwidth", S.Casner, IETF draft-ietf-avt-rtcp-bw-05.txt [SDPfilt] "SDP Source-Filters", B. Quinn, R. Finalyson, IETF draft-ietf-mmusic-sdp-srcfilter-01.txt [SSM] "Source-Specific Multicast for IP", H. Holbrook, B. Cain, IETF draft-ietf-ssm-arch-00.txt B. Contact Please visit our website [FtpSSM] for more information on SSM. If you have questions or comments about this document or IP/TV with SSM in general, please send email to ssm-support@cisco.com. .