Proposed Solution: URD Host Signaling
The company in this proposed solution implemented URD because it wanted to immediately deploy SSM services with existing IP multicast receiver applications that did not support IGMPv3. The company did not want to upgrade any software on its end-user systems.
This section addresses the following issues pertaining to this URD Host Signaling scenario:
- Strategy
- Network Topology
- Benefits
- Ramifications
- How URD Host Signaling Works
Strategy
This proposed solution's strategy assumes that IP multicast using MSDP is already deployed in the ISP's autonomous system and that IP multicast connectivity exists between ISPs.
The following strategy deploys SSM with URD:
Determine an IP multicast address range to run SSM. The suggested default range is from 232.0.0.0 through 232.255.255.255.
Disable rendezvous point (RP) and MSDP peers from processing this SSM address range as ISM services.
Configure edge devices to process URD host reports.
Network Topology
Figure 6-2 shows the logical connections of the SSM network topology. As demonstrated in Figure 6-2, the IPTV server is the SSM source and is located within ISP2. (The URD web server also happens to be located within ISP2, but the URD web server could have been located in any of the ISPs. Because its location is not critical, the URD web server has been omitted from the diagram.) The IPTV client is the SSM/URD client. The SSM/URD client is located within the customer network ISP1AC1. The audio and video streams use the group addresses 232.0.2.1 and 232.0.2.2. Within this topology, please note that any existing RPs or MSDP peers have disabled processing of the SSM range.
)
Figure 6-2
Logical Connections of the Initial SSM Network Topology
Benefits
Deploying SSM in a network provides the following benefits:
IP multicast address management is not required
Denial-of-service attacks from unwanted sources are inhibited
Easy to install and manage
Ideal for Internet broadcast applications
The sections that follow address these benefits at greater length.
IP Multicast Address Management Is Not Required
In the ISM service, applications must acquire a unique IP multicast group address because traffic distribution is based only on the IP multicast group address used. If two applications with different sources and receivers use the same IP multicast group address, receivers of both applications will receive traffic from the senders of both applications. Even though the receivers, if programmed appropriately, can filter out the unwanted traffic, this situation would cause unacceptable levels of unwanted traffic.
Allocating a unique IP multicast group address for an application is still a problem. Most short-lived applications use mechanisms like Session Description Protocol (SDP) and Session Announcement Protocol (SAP) to obtain a random address, but this solution does not work well given the rising number of applications in the Internet. The best current solution for long-lived applications is GLOP Addressing, which is described in Chapter 1. GLOP Addressing strategy was originally meant to be a temporary solution until a coherent multicasting address allocation scheme was devised. The GLOP Addressing solution suffers from the restriction that each autonomous system is limited to only 255 usable IP multicast addresses. SSM does not rely on a unique group address because the combination of the source and group is always unique. If you use SSM, multicast addressing is no longer an issue for interdomain multicast.
In SSM, traffic from each source is forwarded between routers in the network independent of traffic from other sources, so different sources can reuse multicast group addresses in the SSM range.
Denial-of-Service Attacks from Unwanted Sources Are Inhibited
In SSM, multicast traffic from each individual source is transported across the network only if it was requested (through IGMPv3, IGMP v3lite, or URD memberships) from a receiver. In contrast, ISM forwards traffic from any active source sending a multicast group to all receivers requesting that multicast group. In Internet broadcast applications, this ISM behavior is undesirable because it allows unwanted sources to easily disturb the actual Internet broadcast source by sending traffic to the same multicast group. This denial-of-service attack depletes bandwidth at the receiver side with unwanted traffic and disrupts the reception of the Internet broadcast. In SSM, because traffic is transported across the network only when it is requested, simply sending traffic to a multicast group does not cause this type of denial-of-service attack.
Easy to Install and Manage
SSM is easy to install and provision in a network because it does not require the network to maintain which active sources are sending to multicast groups. This requirement exists in ISM (with IGMPv1, IGMPv2, or IGMPv3).
The current standard solutions for ISM service are PIM-SM and MSDP. Rendezvous point (RP) management in PIM-SM (including the necessity for Auto-RP or BSR) and MSDP are required only for the network to learn about active sources. This management is not necessary in SSM, making SSM easier to install and manage, and easier to operationally scale in deployment. Another factor that contributes to SSM's easy installation is that it can leverage preexisting PIM-SM networks and requires only the upgrade of last hop routers to support IGMPv3, IGMP v3lite, or URD.
Ideal for Internet Broadcast Applications
The three benefits previously described make SSM ideal for Internet broadcast-style applications for the following reasons:
The ability to provide Internet broadcast services through SSM without the need for unique IP multicast addresses allows content providers to easily offer their services (IP multicast address allocation has been a serious problem for content providers).
The prevention of denial-of-service attacks is an important factor for Internet broadcast services because, with their exposure to a large number of receivers, they are the most common targets for such attacks.
The ease of installation and operation of SSM makes it ideal for network operators, especially in those cases where content needs to be forwarded between multiple independent PIM domains (because there is no need to manage MSDP for SSM between PIM domains).
Ramifications
Deploying SSM in a network has the following ramifications:
Legacy applications within the SSM range restrictions
IGMP v3lite and URD require a Cisco last hop router
Address management restrictions
State maintenance limitations
The sections that follow address these ramifications at greater length.
Legacy Applications Within the SSM Range Restrictions
Existing applications in a network predating SSM will not work within the SSM range unless they are modified to support (S, G) channel subscriptions or are enabled through URD. Therefore, enabling SSM in a network might cause problems for existing applications if they use addresses within the designated SSM range. An example of this problem would be the failure of sources and receivers to communicate because the PIM-SM network would no longer use the RP to introduce sources and receivers. Receivers learn about sources through the RP in PIM-SM. SSM does not use this in-band mechanism. Applications using SSM address ranges must use an out-of-band method to notify receivers that the source is active.
IGMP v3lite and URD Require a Cisco Last Hop Router
The IETF is standardizing SSM and IGMPv3 solutions. However, Cisco developed IGMP v3lite and URD. For IGMP v3lite and URD to operate properly for a host, the last hop router toward that host must be a Cisco IOS router with IGMP v3lite or URD enabled.
NOTE
An application using the HSIL does not require a Cisco last hop router if the host has kernel support for IGMPv3, because the HSIL will use the kernel IGMPv3 instead of IGMP v3lite. IGMPv3 is standard in Windows XP and is also available for FreeBSD. IGMP v3lite is currently available for all Windows operating systems (Windows 95, 98, 2000, NT, ME, and XP).
Address Management Restrictions
Address management is still necessary to some degree when SSM is used with Layer 2 switching mechanisms. Cisco Group Management Protocol (CGMP), IGMP Snooping, and Router-Port Group Management Protocol (RGMP) currently support only group-specific filtering, not (S, G) channel-specific filtering. If different receivers in a switched network request different (S, G) channels that share the same group, they will not benefit from these existing mechanisms. Instead, both receivers will receive all (S, G) channel traffic and filter out the unwanted traffic on input. SSM's ability to reuse group addresses in the SSM range for many independent applications can lead to less-than-expected traffic filtering in a switched network. Follow the recommendations set forth in the IETF drafts for SSM to use random IP addresses out of the SSM range. This minimizes the chance for reuse of a single address within the SSM range between different applications. For example, even with SSM, an application service providing a set of television channels should use a different group for each television (S, G) channel. This setup guarantees that multiple receivers on different channels within the same application service never experience traffic aliasing in networks that include Layer 2 switches.
State Maintenance Limitations
In PIM-SSM, the last hop router will periodically send (S, G) join messages if appropriate (S, G) subscriptions are on the interfaces. As long as receivers send (S, G) subscriptions, the shortest path tree (SPT) state from the receivers to the source will be maintained, even if the source does not send traffic for longer periods of time than in normal PIM-SM (or even if the source has never been active).
This case differs from PIM-SM, where (S, G) state is maintained only if the source is sending traffic and receivers are joining the group. If a source stops sending traffic for more than 3 minutes in PIM-SM, the (S, G) state will be deleted and reestablished only after packets from the source arrive again through the RPT. Because no mechanism in PIM-SSM notifies a receiver that a source is active, the network must maintain the (S, G) state in PIM-SSM as long as receivers are requesting receipt of that channel.
How URD Host Signalling Works
URD operates by passing a special URL from the web browser to the last hop router. This URL is called a URD intercept URL. A URD intercept URL is encoded with the (S, G) channel subscription and has a format that allows the last hop router to easily intercept it. The router recognizes the URD intercept URL because it is on the well-known TCP port 465.
As soon as the last hop router intercepts an (S, G) channel subscription encoded in a URD intercept URL and sees an IGMP group membership report for the same multicast group from the receiver application, the last hop router will use PIM-SSM to join toward the (S, G) channel as long as the application maintains the membership for the multicast group G. The URD intercept URL is needed only initially to provide the last hop router with the address of the sources to join to.
A URD intercept URL has the following syntax:
webserver:465/path?group=group&source=source1&...source=sourceN&
The webserver string is the name or IP address to which the URL is targeted. This target need not be the IP address of an existing web server, except for situations where the web server wants to recognize that the last hop router failed to support the URD mechanism. The number 465 indicates the URD port. Port 465 is reserved for Cisco by the IANA for the URD mechanism. No other applications can use this port.
When a host's browser encounters a URD intercept URL, it tries to open a TCP connection to the web server on port 465. If the last hop router is enabled for URD on the interface where the router receives the TCP packets from the host, it will intercept all packets for TCP connections destined to port 465 independent of the actual destination address of the TCP connection (that is, independent of the address of the web server). Once intercepted, the last hop router will "speak" a simple subset of HTTP on this TCP connection, emulating a web server.
The only HTTP request that the last hop router will understand and reply to is the following GET request:
GET argument HTTP/1.0 argument = /path?group=group&source=source1&...source=sourceN&
When the router receives a GET request, it tries to parse the argument according to the preceding syntax to derive one or more (S, G) channel memberships. The path string of the argument is anything up to, but not including, the first question mark. The router ignores this string. The group and source1 through sourceN strings are the IP addresses or fully qualified domain names of the channels for which this argument is a subscription request. If the argument matches the syntax shown, the router interprets the argument to be subscriptions for the channels (source1, group) through (sourceN, group).
The router will accept the channel subscriptions if the following conditions are met:
The multicast group's IP address is within the SSM range.
The IP address of the host that originated the TCP connection is directly connected to the router.
If the channel subscription is accepted, the router will respond to the TCP connection with the following HTML page format:
HTTP/1.1 200 OK Server:cisco IOS Content-Type:text/html <html> <body> Retrieved URL string successfully </body> </html>
If an error condition occurs, the <body> part of the returned HTML page will carry an appropriate error message. The HTML page is a by-product of the URD mechanism. Depending on how the web pages carrying a URD intercept URL are designed, this returned text can be displayed to the user or be sized so that the actual returned HTML page is invisible.
The primary effect of the URD mechanism is that the router "remembers" received channel subscriptions and matches them against IGMP group membership reports received by the host. The router will remember a URD (S, G) channel subscription for up to three minutes without a matching IGMP group membership report. When the router sees that it has received both an IGMP group membership report for a multicast group G and a URD (S, G) channel subscription for the same group G, it will join the (S, G) channel through PIM-SSM. The router then continues to join to the (S, G) channel based on only the presence of a continuing IGMP membership from the host. One initial URD channel subscription is all that needs to be added through a web page to enable SSM with URD.
If the last hop router from the receiver host is not enabled for URD, it will not intercept the HTTP connection toward the web server on port 465. This situation results in a TCP connection to port 465 on the web server. If no further provisions on the Web server are taken, the user might see a notice (for example, "Connection refused") in the area of the web page reserved for displaying the URD intercept URL (if the web page was designed to show this output). You can also let the web server "listen" to requests on port 465 and install a Common Gateway Interface (CGI) script to allow the web server to know if a channel subscription failed (for example, to subsequently return more complex error descriptions to the user).
Because the router returns a Content-Type of text and HTML, the best way to include the URD intercept URL into a web page is to use a frame. By defining the size of the frame, you can also hide the URD intercept URL on the displayed page.
By default, URD is disabled on all interfaces. When URD is configured on an interface using the ip urd interface configuration command, it is active only for IP multicast addresses in the SSM range.