Home > Articles > Networking > Network Design & Architecture

  • Print
  • + Share This
This chapter is from the book

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-2Figure 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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020