This exercise assumes a large global enterprise running sparse mode PIM with multicast everywhere, and lots of different multicast applications with different relevant scopes. Some applications will never reach beyond the local link, some will multicast between continents, the others fall somewhere in between. This design is a scalable framework. You won't be deploying this whole scheme all at once, but it's helpful to get all of these bits and pieces into place early to allow for room to grow without having to rip things apart later.
I assume we don't have the luxury of using Source Specific Multicast (SSM), a mechanism in which the receivers (or, alternatively, the leaf routers) know the address of the originating endpoints, and ask for them by source IP. Instead, we'll plan for Any Source Multicast (ASM), which requires the placement, configuration and peering of PIM Rendezvous Points (RPs) to bring together active data flows and interested receivers.
IPv4 Multicast falls into the 224/4 address block: 224.0.0.0 - 239.255.255.255. Within this range there are sub-ranges used for various purposes, which will drive our assigment decisions:
RFC2365 Administratively Scoped IP Multicast
RFC2365 gives us the "IPv4 Local Scope" 239.255/16. The only restrictions on the use of this scope is that it not be further subdivided, and that it be the smallest scope in use. It's perfect for Link-Local multicast applications that won't be routed off-net. Things like application heartbeat traffic, server load balancing coordination, pricing application backends, etc... Because this traffic won't be routed, the group addresses can be re-used on different subnets. Depending on your perspective, this re-use can make your life easier (production and disaster recovery instances of an application can run with the same backend configuration), or more complicated (trying to keep track of exactly what is using 239.255.5.5 on each subnet). Proceed with caution.
RFC2365 also prescribes the 239.192/14 block for private use within an organization. The block breaks nicely into four /16s, which is exactly the number of routable scopes I'm going to present. If you need more scopes, you can dip into the expansion range described by section 6.2.1 (not recommended), or you can slice the /14 into smaller chunks.
Don't use x.0.0.x or x.128.0.x
There are thirty-two /24s that should be avoided at all costs. These are a
byproduct of RFC 1112 Section 6.4 and RFC 3171 Section 3. These multicast
groups map into MAC addresses 01:00:5E:00:00:XX. L2 flooding suppresion mechanisms don't work on these groups. They will always flood to all ports in a broadcast domain unless you're using very new and expensive equipment which can restrain L2 multicast traffic based on information in the L3 header.
Internet groups
Most of the 224/4 block is registered space. The applications here could conceivably be delivered to you over The Internet, but more likely will arrive on dedicated circuits from vendors and business partners. A common example of this sort of traffic is market pricing data in financial firms. You won't likely be talking PIM with your ISP, but you might see multicast using registered space at your B2B network edge.
The Scopes
| 239.255.0.0/16 | Link local | Used for non-routable traffic only. Group addresses are universally re-usable. |
| 239.192.0.0/16 | Building local scope | Used for applications where the sender and receivers live in the same building. A building-wide public address system might use this scope. Group addresses can be re-used in each building: Perhaps the same PA system is in each building. If you use the same addresses, the application owners won't need a special configuration for each building. |
| 239.193.0.0/16 | Campus local scope | The campus local scope works just like the building scope, but has wider reach. Perhaps you're pulling MPEG2 HDTV out of the air and multicasting it onto your LAN. You probably don't want to put these fat streams on the wide area links, so you duplicate the multicasts in each campus. By re-using group addresses, you'll only need a single TV guide for the whole enterprise. Users who tune into 239.193.1.1 will find their local ABC affiliate (for example), no matter which office they're in. |
| 239.194.0.0/16 | Region local scope | Works just like Campus and Building scopes, but with national or continental scale. |
| 239.195.0.0/16 | Enterprise local scope | The enterprise local scope is for application streams that will be used enterprise-wide. These group addresses are not reusable. |
| 224.0.0.0/4 | Internet scope | Subsets of this /4 are registered space. You probably won't be multicasting to or from The Internet anytime soon, but might find yourself forwarding registered applications that arrive on private circuits. |
One final detail about these scopes: Lets say you have offices in London, Madrid, Tokyo, Los Angeles, and a multi-building campus in Chicago.
The Building scopes are easy to identify: Each building is a scope!
The Chicago campus obviously constitutes a campus scope, but what about those one-office cities? They're campuses too. One-building campuses. As applications roll out in LA, pretend you have multiple buildings there, and assign addresses accordingly. If you assign KTLA to a Building-scope multicast group, you'll have to reconfigure things when a new office opens so that those folks won't miss watching any live police chases.
Accordingly, the Tokyo office represents a Building, Campus and Region, all by itself. When the Osaka office opens, the Region-scoped Japanese music-on-hold multicast stream that you deployed in Tokyo will be available for use in Osaka.
PIM BiDir
Finally, we need to carve those scopes up one more time. Bidirectional PIM is a mechanism where multicast traffic flows in both directions between end stations. Everybody is a sender and a receiver at the same time. BiDir PIM doesn't use a shortest-path-tree like ASM, so it's good to set aside an address block for it, even if we're not going to use it right away. We'll take the top half of each local routable /16 for BiDir.
The Building scopes are easy to identify: Each building is a scope!
The Chicago campus obviously constitutes a campus scope, but what about those one-office cities? They're campuses too. One-building campuses. As applications roll out in LA, pretend you have multiple buildings there, and assign addresses accordingly. If you assign KTLA to a Building-scope multicast group, you'll have to reconfigure things when a new office opens so that those folks won't miss watching any live police chases.
Accordingly, the Tokyo office represents a Building, Campus and Region, all by itself. When the Osaka office opens, the Region-scoped Japanese music-on-hold multicast stream that you deployed in Tokyo will be available for use in Osaka.
PIM BiDir
Finally, we need to carve those scopes up one more time. Bidirectional PIM is a mechanism where multicast traffic flows in both directions between end stations. Everybody is a sender and a receiver at the same time. BiDir PIM doesn't use a shortest-path-tree like ASM, so it's good to set aside an address block for it, even if we're not going to use it right away. We'll take the top half of each local routable /16 for BiDir.
| Link Local |
| ||||
| Building |
| ||||
| Campus |
| ||||
| Region |
| ||||
| Enterprise |
|
No comments:
Post a Comment