Table Of Contents
Guidelines for Enterprise IP Multicast Address Allocation
Multicast Address Fundamentals
Layer 3 IP Multicast Addresses
Layer 2 Multicast MAC Address Mapping
Performance Impact of Address Mapping
IANA Assigned Multicast Address Blocks
Layer 2 Flooding of Link-Local Multicast
Static Address Allocation Methods
Addresses Allocation Considerations
Allocation Based on Application Scope
Allocation Based on Multicast Application Rates
Allocation Based on Type of Multicast Protocol
Administratively Scoped IP Multicast
RFC 2365—Administratively Scoped Addresses
Administrative Scoped Zones Example
Extending the Administrative Scope Model
Deploying Administrative Scoping
Controlling IP Multicast Traffic
Controlling Rendezvous Point Information Distribution
Hard-Coded Multicast Address Applications
White Paper
Guidelines for Enterprise IP Multicast Address Allocation
Introduction
With the growing popularity of IP multicast applications, many customers are considering deploying or have already deployed IP multicast in their networks. A prerequisite of successful IP multicast deployment is designing and documenting an appropriate multicast addressing scheme.
Some of the common problems that customers face during the IP multicast deployment are:
•
Keeping administration and troubleshooting of IP multicast as simple as possible
•
•
•
•
•
•
•
•
The key to solving or simplifying many of these issues is a solid addressing policy. Without a correctly planned and scoped IP multicast addressing scheme, customers will face more complex configurations, which significantly decrease the control of IP multicast over the network and increase administration and support overhead.
The objective of this document is to provide Cisco Systems® customers with several methodologies of allocating IP multicast group addresses. With this knowledge, the appropriate scheme or combinations of schemes can be chosen to fit specific customer requirements. It is assumed the reader is familiar with IP multicast terminology.
References
•
http://search.ietf.org/internet-drafts/draft-ietf-mboned-iana-ipv4-mcast-guidelines-04.txt
•
http://www.ietf.org/rfc/rfc2365.txt
•
•
•
http://www.ietf.org/rfc/rfc2730.txt
•
http://www.ietf.org/rfc/rfc2908.txt
•
•
http://www.ietf.org/rfc/rfc2776.txt
•
•
•
•
Multicast Address Fundamentals
By its nature, IP Multicast forwarding is different from IP Unicast and has additional addressing requirements to consider.
•
•
•
•
•
•
Layer 3 IP Multicast Addresses
IP multicast addresses have been assigned to the old Class "D" address space by the Internet Assigned Number Authority (IANA). Addresses in this space are denoted with a binary "1110" prefix in the first four bits of the first octet, as shown in Figure 1. This results in IP multicast addresses spanning a range from 224.0.0.0 through 239.255.255.255.
Figure 1
IP Multicast Address Format
Layer 2 Multicast Addressing
The IEEE 802.2 specification makes provisions for the transmission of broadcast and multicast packets. As shown in Figure 2, Bit 0 of Octet 0 in an IEEE MAC address indicates whether the destination address is a broadcast/multicast address or a unicast address.
Figure 2
Ethernet MAC Address Format
If this bit is set, the MAC frame is destined either for an arbitrary group of hosts or all hosts on the network (if the MAC destination address is the broadcast address 0xFFFF.FFFF.FFFF). IP multicasting at Layer 2 uses this capability to transmit IP multicast packets to a group of hosts on a LAN segment.
Layer 2 Multicast MAC Address Mapping
All IP multicast frames all MAC layer addresses beginning with the 24-bit prefix of 0x0100.5Exx.xxxx. With only half of these MAC addresses available for use by IP Multicast, 23 bits of MAC address space is available for mapping Layer 3 IP multicast addresses into Layer 2 MAC addresses. All Layer 3 IP multicast addresses have the first four of the 32 bits set to 0x1110, leaving 28 bits of meaningful IP multicast address information. These 28 bits must map into only 23 bits of the available MAC address. This mapping is shown graphically in Figure 3.
Figure 3
IP Multicast to Ethernet/FDDI MAC Address Mapping
Performance Impact of Address Mapping
Because all 28 bits of the Layer 3 IP multicast address information cannot be mapped into the available 23 bits of MAC address space, five bits of address information are lost in the mapping process. This results in a 32:1 address ambiguity when a Layer 3 IP multicast address is mapped to a Layer 2 IEEE MAC address. This means that each IEEE IP multicast MAC address can represent 32 IP multicast addresses as shown in Figure 4.
This 32:1 address ambiguity has the potential to cause problems. For example, a host that wishes to receive multicast group 224.1.1.1 will program the hardware registers in the network interface card to interrupt the CPU when a frame with a destination multicast MAC address of 0x0100.5E00.0101 is received. Unfortunately, this same multicast MAC address is also used for 31 other IP multicast groups. If any of these 31 other groups are also active on the local LAN, the host CPU will receive interrupts when a frame is received for any of these other groups. The CPU must examine the IP portion of each of these received frames to determine if it is the desired group; for instance, 224.1.1.1. This can affect the host's available CPU power if the amount of "spurious" group traffic is high enough.
Figure 4
MAC Address Ambiguities
In addition to having a possible negative impact on host CPU power, this ambiguity can also cause problems when trying to constrain multicast flooding in Layer 2 LAN switches based solely on these multicast MAC addresses
IANA Assigned Multicast Address Blocks
The IETF has provided the IANA with guidance on how IP Multicast address space should be allocated in RFC 3171bis, "IANA Guidelines for IPv4 Multicast Address Assignments." Table 1 lists the current assignments blocks documented in RFC 3171bis.
Of these address blocks, the IANA assigns addresses in the Local Network Control, Internetwork Control and Ad hoc blocks based on the guidelines also supplied by the IETF in RFC 3171bis. These guidelines call for Expert Review, Internet Engineering Steering Group (IESG) approval, or a Standards Action process before the IANA assigns addresses in these spaces.
Local Network Control Block
The range of 224.0.0.0 through 224.0.0.255 is considered the Local Network Control Block—more commonly known as the Link-Local Block—and is used by network protocols on a local subnet segment. Packets with an address in this range are local in scope and always should be transmitted with a Time To Live (TTL) of 1 so that they go no farther than the local subnet.
Table 2 is a list of the Link-Local multicast addresses taken directly from the IANA database at the time this paper was written. The table lists the reserved multicast addresses, the network protocol function to which it has been assigned, and the person who requested the address or the RFC associated with the protocol.
The OSPF routing protocol is a good example where Local Network Control multicast addresses are employed by a protocol. If you use OSPF in your network, you may have seen packets addressed to the 224.0.0.5 and 224.0.0.6 multicast address on your networks. These addresses permit OSPF routers to communicate important OSPF data to All OSPF Routers or All OSPF Designated Routers, respectively.
The assignments in the Link-Local block already have taken nearly one-third of this very limited resource and care must be taken to insure that this critical IPv4 resource does not become exhausted. To avoid this, it may soon become necessary for the IANA to begin periodic reviews of these allocations and to reclaim some of these allocations that are no longer actively being used.
Layer 2 Flooding of Link-Local Multicast
IGMP Snooping normally is used by Layer 2 switches to constrain multicast traffic only to those ports that have hosts attached and that have signaled their desire to join the multicast group by sending IGMP Membership Reports. However, it is important to note that most Layer 2 switches flood all multicast traffic that falls within the MAC address range of 0x0100.5E00.00xx (which corresponds to Layer 3 addresses in the Link-Local block) to all ports on the switch even if IGMP Snooping is enabled. This is true for the current suite of Cisco switches. The reason that this Link-Local multicast traffic is always flooded is that IGMP Membership Reports normally are never sent for multicast traffic in the Link-Local block. For example, routers do not send IGMP Membership Reports for the ALL-OSPF-ROUTERS group (224.0.0.5) when OSPF is enabled. Therefore, if Layer 2 switches were to constrain (that is, not flood) Link-Local packets in the 224.0.0.0/24 (0x0100.5E00.00xx) range to only those ports where IGMP Membership reports were received, Link-Local protocols such as OSPF would break.
The impact of this Link-Local flooding in combination with the 32:1 ambiguity that arises when Layer 3 multicast addresses are mapped to Layer 2 MAC addresses means that there are several multicast group ranges besides the 224.0.0.0/24 that will map to the 0x0100.5E00.00xx MAC address range and hence also will be flooded by most Layer 2 switches. It is recommended that multicast addresses that map to the 0x0100.5E00.00xx MAC address range be avoided. Table 3 lists all multicast address ranges that should not be used if Layer 2 flooding is to be avoided.
Inter-Network Control Block
The range of 224.0.1.0 through 224.0.1.255 is the Inter-Network Control Block. These addresses are similar to the Local Network Control Block except that they are used by network protocols when control messages need to be multicast beyond the local network segment.
Table 4 is a partial listing of the first 50 multicast addresses in the Inter-Network Control Block that have been assigned by the IANA. The table lists the address, the network protocol function to which it has been assigned, and the person who requested the address or the RFC associated with the protocol.
The Cisco Auto-RP protocol is a good example of Inter-Network Control multicast. Inter-Network Control multicast addresses 224.0.1.39 and 224.0.1.40 are assigned as the Cisco Announce and Cisco Discovery multicast groups, respectively. The Auto-RP mechanism uses these two multicast groups to communicate Rendezvous Point information through a PIM Sparse Mode (PIM-SM) domain.
At the time that this paper was written, address assignments in the Inter-Network Control Block have already used more than two-thirds of this limited resource. Many of these assignments may be for something other than what this address space was intended for or for protocols that have not (or possibly will not) see the light of day.
Ad Hoc Multicast Block
The multicast group range of 224.0.2.0 through 224.0.255.255 is the Ad Hoc Multicast Block. Historically, addresses in this range have been assigned to applications that do not clearly fall into the Local Network Control and Inter-Network Control categories. In general, the guidelines provided in RFC 3171bis for the assignment of addresses in this range state that the IANA should assign addresses in this range only under special circumstances. Even then, the assignment must undergo a strict Expert Review, IESG Approval, or Standards Action process before addresses are assigned.
Table 5 is a list of assignments in the Ad Hoc block at the time that this paper was written. Much of the address space in the Ad Hoc block was assigned by the IANA prior to receiving clear guidelines from the IETF, because most of the assignments in Table 5 clearly intend to reserve address space to source future commercial content. These sorts of commercial content address reservations are highly discouraged and are considered as address hoarding by the multicast community. This is especially true because most organizations can use GLOP addressing to source their commercial content to the Internet. Furthermore, some of these assignments are intended for multicast traffic that never will be transmitted to the Internet and do not need global multicast address space.
Finally, organizations that reserve large blocks of this address space to source commercial content should be aware that RFC 3171bis recommends an annual review of all assigned addresses and, when possible, reclaim improperly assigned addresses. It is hoped that the IANA soon will review these assignments and return most of this address space to "unassigned" status.
SDP/SAP Multicast Block
The multicast group range of 224.2.0.0 through 224.2.255.255 (224.2/16) is the SDP/SAP Multicast Block, which is reserved for applications that send and receive multimedia session announcements using the SAP described in RFC 2974. An example of an application that uses SAP is the Session Directory tool (SDR), which transmits global scope SAP announcements on groups 224.2.127.254 and 224.2.127.255.
SSM Block
The multicast group range of 232.0.0.0 through 232.255.255.255 (232/8) is reserved for SSM. SSM is a new extension to PIM Sparse mode that eliminates the need for the Rendezvous Point and the Shared Tree and uses only the Shortest-Path Tree to the desired sources.
A key premise of SSM is that it is the responsibility of the host application program to determine the active source IP address and group multicast address of the desired multicast flow. Using IGMPv3, the host then signals the router with exactly which specific source (hence the name SSM) and group that it wishes to receive. Because PIM-SSM does not use a Rendezvous Point or a Shared Tree in the 232/8 range, a host will receive traffic only from sources that it has specifically requested. This eliminates interference or denial of service (DoS) attacks from unwanted sources sending to the same multicast group. Furthermore, the lack of Shared Trees in the SSM range means that two different sources in the Internet can source traffic to the same group address in the 232/8 range and not worry about having a group address conflict. The reason that there is no conflict is that the hosts join only the Shortest-Path Tree of the desired source. Therefore, one host can receive Stock Quotes from (S1, 232.1.1.1) while at the same time another host can watch live video from (S2, 232.1.1.1) because separate Shortest-Path Trees are being used and no common Shared Tree exists that might accidentally deliver the unwanted source.
GLOP Multicast Block
This block of addresses has been assigned by the IANA as an experimental, statically assigned range of multicast addresses intended for use by Content Providers, ISPs, or anyone wishing to source content into the global Internet. This allocation methodology, called GLOP addressing, which is defined in RFC 2770, uses the multicast group range of 233.0.0.0 through 233.255.255.255 (233/8) and provides each Autonomous System with a block of 255 statically assigned multicast addresses. Content providers who wish to transmit multicast traffic to their customers in the Internet and that have an assigned Autonomous System Number (ASN) can use multicast addresses from their block of 255 static GLOP addresses to transmit content. If the content provider does not have its own assigned ASN, usually it can lease static GLOP addresses from their Internet Service Provider.
Administratively Scoped Block
In addition to the multicast address ranges previously described, the IANA has reserved the range of 239.0.0.0-239.255.255.255 as Administratively Scoped addresses for use in private multicast domains. These addresses are similar in nature to the reserved IP unicast ranges (such as 10.0.0.0/8) defined in RFC 1918 and will not be assigned by the IANA to any other group or protocol. This means that network administrators are free to use multicast addresses in this range inside of their domain without fear of conflicting with others elsewhere in the Internet. However, administratively scoped addresses should not be used when sourcing IP Multicast traffic to the Internet. This is because it has become a common practice to block multicast traffic in these ranges from entering or leaving an Autonomous Domain.
The use of administratively scoped addresses also helps to conserve the limited multicast address space because they can be reused in different regions of the network. Network administrators should configure their multicast routers to insure that multicast traffic in the Administratively Scoped address range does not cross into or out of their multicast domain.
It is becoming common practice for Enterprise network administrators to further subdivide this address range into smaller geographical Administrative Scopes within the Enterprise network to limit the "scope" of particular multicast applications. This is used to prevent high-rate multicast traffic from leaving a campus (where bandwidth is plentiful) and congesting the WAN links. (The topic of Administrative Scoping is addressed in more detail in the section on " Administratively Scoped IP Multicast")
Address Allocation
Currently, the problem of allocating multicast addresses partially depends on whether the address is to be used strictly within an Enterprise or whether the address is to be used for global Internet multicasting. In the latter case, the Enterprise must allocate a global multicast address that does not conflict with someone else in the Internet. On the other hand, if the multicast is intended to remain inside of the Enterprise, an address may be allocated from the Administratively Scoped address range (239/8) without fear of conflict with other sources in the Internet. In fact, the normal procedure is for the Enterprise network to have "multicast boundaries" configured at the borders of the network so that traffic in the 239/8 address range can neither enter nor leave the Enterprise network.
The actual allocation of multicast addresses can be accomplished in the following ways:
•
•
•
By further categorizing these methods by Global and Enterprise multicast, we can develop the matrix of protocols and methodologies (shown in Table 6) that are currently applicable today.
Each of these methodologies and/or protocols are discussed in more detail in the following sections.
Static Address Allocation Methods
Statically allocated addresses are addresses that are assigned by a controlling authority for use by protocols or applications that require well-known multicast addresses.
Global IANA Assignment
Static multicast addresses that have been assigned by the IANA are considered to be permanent in nature and globally valid; therefore, they are valid everywhere and in all networks. This permits applications and hardware devices to have these addresses "hard-coded" into their software or microcode.
One example of a static multicast addresses that has been permanently assigned by the IANA is the Local Network Control multicast address 224.0.0.5, which is the "All OSPF Routers" multicast group address. Another example is multicast address 224.0.1.1, which is an Inter-Network Control multicast address that is permanently assigned by the IANA for use by the Network Time Protocol.
Enterprise Internal Assignment
Static address allocation methods are used by Enterprise network administrators to allocate specific addresses or address ranges from the Administratively Scoped address range, 239.0.0.0-239.255.255.255. In this case, the network administrator assumes the duties of the "Controlling Authority" for address assignment within the Enterprise.
GLOP Addressing
In the late 1990s when native multicast was beginning to be deployed in the Internet, several Content Providers planned to begin multicasting some of their audio and video content. Unfortunately, the state of dynamic address allocation at that time was such that no good solutions were available that permitted the Content Providers to uniquely allocate addresses. To work around this problem, an experimental form of static address allocation was proposed by the IETF. This allocation methodology, called GLOP addressing, which is defined in RFC 2770, uses the multicast group range of 233.0.0.0 through 233.255.255.255 (233/8). This block was assigned by the IANA and is an experimental, statically assigned range of multicast addresses intended for use by Content Providers, ISPs, or anyone wishing to source content into the global Internet.
Note:
GLOP addresses (as shown in Figure 5) are constructed as follows: the high order octet is always 233 (decimal), followed by the next two octets which contain the 16-bit ASN of the Content Provider or ISP that is sourcing the multicast traffic.
Figure 5
GLOP Address Format
The advantage of this allocation mechanism is that for each registered Autonomous System that an entity owns, it automatically has a /24 worth of statically allocated multicast address space. No registration process is necessary because the allocation already is based on registered ASNs.
As an example of GLOP addressing, assume that Company XYZ wants to source various live video and audio multicast streams to the global Internet as part of their service offering. If Company XYZ has a registered ASN of 2109, they would be able to source this traffic using multicast addresses in the range of 233.8.61.0-233.8.61.255. (The decimal ASN 2109 converts to binary 100000111101 which, in turn, converts to 8.61 in dotted decimal format.)
It also might be the case that Company XYZ does not have a registered ASN. In that case, they could "lease" some GLOP address space from their ISP, who would allocate the leased addresses from their pool of statically assigned GLOP addresses based on their registered ASNs.
Extended GLOP Multicast Addresses
When GLOP addressing was initially introduced, several Content Providers immediately began to take advantage of this allocation method and started sourcing numerous streams of multicast video and audio into the global Internet. Unfortunately, some of these Content Providers quickly ran out of multicast addresses, as many had only a single registered ASN. As a result, they began to look for additional addresses that could be statically allocated to them for their multicast content streams.
RFC 2770, "GLOP Addressing in 233/8," explains that the GLOP address space consisting of private ASNs (64512 through 65545) in the middle two octets are reserved for future allocation. This effectively resulted in the address range of 233.252.0.0-233.255.255.255 (that is, four /16 blocks) being reserved. Given the need for more address space by some of the Content Providers, this space was a prime candidate for allocation of additional space to meet their needs. The problem was how to allocate it.
In June 2001, an "Informational" RFC was published (RFC 3138) that defined "Extended Assignments in 233/8" and referred to addresses in this range as Extended GLOP (EGLOP) address space. This RFC also states that a Regional Registry, such as the IANA, should control the assignment of address blocks from the EGLOP address space. Furthermore, applications for address space from this range must demonstrate that the request cannot be satisfied by other address means such as GLOP addressing, Administratively Scoped addressing, or SSM.
Scope Relative Address Allocation
Scope Relative multicast addresses (shown in Table 7) are static multicast addresses assigned by the IANA. These addresses are associated with Administratively Scoped multicast ranges and are used by protocols that require well-known addresses within the scope to perform their normal function. However, because the multicast addresses configured by a network administrator for an Administratively Scoped range can vary depending on network needs, Scope Relative addresses use offset address assignments. To facilitate this offset assignment approach, RFC 2365 ("Administratively Scoped IP Multicast") reserves a block consisting of the highest 256 multicast addresses in every administratively scoped range for Scope Relative addressing.
Figure 6 lists the Scope Relative addresses that currently are assigned by the IANA. These addresses consist of a relative offset from the end of the reserved Scope Relative address block. A relative offset assignment of zero would correspond to the last address in the reserved Scope Relative address block, or x.x.x.255. Likewise, a relative offset of one would correspond to address x.x.x.254 in the reserved Scope Relative address block.
Figure 6
Scope Relative Addressing
Figure 6 shows an example of Scope Relative addresses in use in the Site-Local zone consisting of the multicast address range of 239.255.0.0/16. Per RFC 2365, the subrange of 239.255.255.0/24 is reserved for Scope Relative multicast within the Site-Local zone. Because Scope Relative addresses are offset from the end of this range, Figure 6 shows that address 239.255.255.255 would be assigned for "SAP Session Announcements" and 239.255.255.254 would be assigned for use by the "MADCAP" protocol inside the Site-Local zone.
Dynamic Address Allocation
SDR—Session Directory
SDR is a multicast application that does both Dynamic Address Allocation and uses Scope Relative multicast. Although the SDR application is being phased out for other content announcement mechanisms (such as Web-based content servers), it makes a good case study for how dynamic multicast allocation initially was accomplished, as well as being a good example of how Scope Relative addressing is used. We will provide an overview of this application to complete our discussion of multicast addressing.
SDR listens for Session Announcement Protocol (SAP) packets on a well-known, global IP multicast group (for instance, 224.2.127.254). These SAP packets periodically are multicast by other SDR hosts that have created a multimedia session. Each SAP packet contain a session description, the time the session is active, its IP multicast group addresses, media format, contact person, and other information about the advertised multimedia session.
Figure 7 shows the SDR SAP window after it has listened to the SDR multicast group (224.2.127.254) for a period of time. Each line corresponds to a multimedia session announcement that SDR received in a SAP packet. As these packets are received, SDR updates this window by adding the multimedia session name to the list and storing this information in an SDR cache file.
Figure 7
SDR Session Announcement Window
The frequency of these SDR announcements depends on the total number of sessions being announced in the Internet. As the list of announced sessions grows, each SDR sender slows its transmission rate so that the total bandwidth consumed by SDR announcements is kept to a very low rate. The end result is that the announcement period of any one session easily can increase to several minutes.
As SDR continues to run and collect all session announcements from the Internet, it builds a database of cache files that describe every multicast session being announced in the Internet. The information in these cache files includes the multicast addresses in use that, in turn, allows SDR to determine what addresses are not in use. As a result, when users want to create a new session and allocate one or more multicast addresses, they click "New" at the top of the Session Announcement window shown in Figure 7. This launches the SDR "Create New Session" window shown in Figure 8.
Notice that SDR is proposing multicast address 224.2.234.131 for use with this audio session. Theoretically, this should be an unused global address that should not conflict with anyone else in the Internet.
The SDR multicast application is an example of an application that uses Scope Relative multicast addresses. SDR uses SAP to announce the existence of multimedia multicast conferences to other workstations in the network running the SDR application. Normally, SDR would announce these sessions by multicast to the well-known multicast group 224.2.127.254, which would travel throughout the Internet because it falls in the global Internet scope. However, when a multimedia conference is created inside a designated scoped zone such as the Site-Local zone, SDR would announce this session using the SAP scope relative address. In the case of the Site-Local zone, this would correspond to the scope relative multicast address of 239.255.255.255. Assuming that multicast boundaries were in place around the Site-Local zone to block traffic in the 239.255.0.0/16 multicast address range from leaving the Site-Local zone, these Site-Local SDR announcements to 239.255.255.255 would not leave the zone.
Figure 8
SDR Create Menu
Continuing with this SDR example of Scope Relative multicast addressing, assume that an Enterprise has deployed both Site-Local and Organization-Local (for instance, Enterprisewide) scoped zones in the 239.255.0.0/16 and 239.192.0.0/14 address ranges, respectively. In this case, an SDR workstation would use a Scope Relative multicast address of 239.255.255.255 to announce Site-Local sessions and a Scope Relative multicast address of 239.192.255.255 to announce Organization-Local (Enterprisewide) sessions1 .
SDR served its purpose in the early days of the DVMRP-based Multicast Backbone, or MBone for short, where the primary multicast content was limited to a few multimedia conferences.
SDR is being phased out by most Enterprise network administrators as the preferred method of multimedia session announcement in deference to other methods, such as well known Content Managers (IP/TV) or Web links. Therefore, until the take up of a zone protocol like MZAP (RFC 2776), these assignments have historically only been used in the Site-Local scope (with some minor exceptions), although good practice is to reserve the relative assignments within each scope for future use.
SDR has some serious drawbacks. First, unlike the hierarchical address space of the DNS, SDR uses a flat address space that cannot scale to the projected numbers of content sources in the Internet. This is particularly true if you consider that as the number of announced sessions grows, the period of the announcements also grows. Finally, not everyone who wishes to source multicast content to the Internet wants or needs to use SDR.
MASC
As far as "global dynamic multicast address allocation" methods go, the only other proposed solution is MASC. MASC is a hierarchical address allocation protocol that is defined in RFC 2909.
Figure 9 shows how MASC will work at a very high level. At key locations in the Internet (possibly at certain Internet Exchange points), top-level MASC nodes will reside in the top level, or root MASC domain. The MASC nodes in the next lower domain in the hierarchy are connected to the root-level nodes in a parent-child relationship. These second layer domain MASC nodes are connected to the MASC nodes in the third layer of hierarchy, and so on. All of these connections use TCP and are configured in a similar fashion as Border Gateway Protocol peer connections.
The root domain MASC nodes are responsible for the allocation of the global multicast address range into smaller contiguous blocks of addresses to the MASC nodes in the next lower MASC domain. Currently, it is envisioned that this first level domain of MASC nodes primarily would consist of first tier ISPs.
Figure 9
MASC Hierarchy
Each of the MASC nodes in the first tier ISPs would send a Set-Claim message containing a requested range of multicast addresses to the root domain MASC nodes. If this range is not available, the root domain MASC nodes would acknowledge the Set-Claim message and mark the range as allocated in its database. If a portion of the range already has been successfully claimed by another MASC node in another domain, the root domain node will propose an alternative range of available addresses to the requestor. This back and forth negotiation continues until the requestor had successfully claimed an acceptable range of addresses (or finally timed out).
After a MASC node has claimed a range of addresses, it can use these addresses in its internal network as well as allocate smaller contiguous blocks of addresses to lower tier domain of MASC nodes as shown in Figure 9. (The actual protocol that an end station will use inside of a domain to request a multicast address from a MASC server or one of its agents will be MADCAP. This protocol is discussed in the next section.)
Because a successful MASC Set-Claim on a range of addresses typically is valid only for a finite period of time, a MASC domain periodically must renew its claim. If the parent MASC domain experiences address exhaustion, it may reduce the size of a lower tier domain range in an attempt to free up some address space. Alternatively, a MASC domain that is beginning to experience address exhaustion also can issue additional Set-Claims to its parent domain in an attempt to allocate more space.
MASC is a nontrivial protocol, which must be carefully designed and implemented to avoid causing massive fragmentation of the limited resource of multicast addresses. If serious fragmentation does occur, one quickly can envision one of the most incredibly complex, distributed, garbage collection problems that the computer industry has seen to date.
Unfortunately, the deployment of MASC in the Internet simply has not happened. This may be partly due to the fact that the protocol is so complex. Additionally, the introduction of GLOP, EGLOP addressing, as well as the new Source-Specific Multicast extension to PIM Sparse mode has resulted in other solutions to the global address allocation problem, at least for the short term.
MADCAP
Multicast Address Dynamic Client Allocation Protocol (MADCAP) allows a client workstation to "lease" a multicast address from a MADCAP server in a manner similar to how it "leases" an IP address from a DHCP server.
When a MADCAP client workstation wants to "lease" a multicast address, first it must locate the nearest MADCAP Servers. This is accomplished by multicasting a MADCAP DISCOVER message to the MADCAP Scope Relative multicast address (-1) in the Site-Local scope, (for instance, 239.255.255.254). (Note: This is why it is important to adhere to the conventions for the Site-Local scope defined in RFC 2365.) Any MADCAP Servers that hear this Scope Relative multicast message and wish to participate in the allocation process identify themselves by sending back an OFFER message to the MADCAP client. After the client has discovered the appropriate MADCAP server, it can send REQUEST messages to the server to request the "lease" of a multicast address from the server.
MADCAP supports the concept of Administratively Scoped Zones. Workstations can request a list of known scope ranges by sending a GETINFO message to one or more MADCAP servers, which respond by sending back a list of its configured multicast scope ranges. This allows the MADCAP client to select the scope range that is most appropriate to the application and subsequently request an address from this range in a REQUEST message.
To use MADCAP for multicast address allocation in an Enterprise network, the following two requirements must be met:
•
•
The first requirement normally is beyond the control of the network administrator and, to date, few applications exist with this capability. However, if there are at least one or more applications being deployed (or expected to be deployed) in the network that will use MADCAP, it is good practice for the network administrator to deploy MADCAP servers in the network.
Beginning with Microsoft Server 2000 operating system, MADCAP Server functions have been added under the DHCP Service. Figure 10 shows an example of a "Campus" scope Multicast Scope range being configured in a Microsoft 2003 Server.
Figure 10
MADCAP Scope Configuration in Windows Server 2003
Notice that Microsoft has chosen to include the MADCAP configuration functions inside the DHCP Service even though MADCAP is a separate protocol. This is probably because the concepts of configuring a MADCAP Multicast Scope are like the configuration of a DHCP scope. However, other operating system implementations of MADCAP may take a different approach.
Addresses Allocation Considerations
The allocation of IP multicast group addresses is a complex process. Allocation of addresses needs to take into account multiple factors such as:
•
•
•
•
•
•
•
•
