Loading in 2 Seconds...
Loading in 2 Seconds...
Internet2 Multicast Workshop Columbia University, New York, NY December 2005. Acknowledgements. Greg Shepherd Beau Williamson Marshall Eubanks Bill Nickless Caren Litvanyi Patrick Dorn Leonard Giuliano Alan Crosswell Debbie Fligor. Mitch Kutzko Matt Davy Yul Pyun Stig Venaas
University of Oregon
Who has Juniper experience?
What's in the binder?
Slides, with space for notes.
Labs. For labs 2-5, there are separate "answers" docs which are not included in the binder. These are distributed after, or sometimes during, the labs (they're labs, not tests). If you get stuck, please ask!
References: Cisco/JUNOS multicast commands, JUNOS RIB groups, JUNOS CLI. For use during the labs.
Finding things at MITC
Meals, snacks, and coffee
Multicast on the LAN
Source-Specific Multicast (SSM)
Any-Source Multicast (ASM)
Best Current Practices; Future of Multicast
Instead of sending a separate copy of the data for each recipient, the source sends the data only once, and routers along the way to the destinations make copies as needed.
Unicast does mass mailings; multicast does chain letters.
The original multicast network was called the MBone. It used a simple routing protocol called DVMRP (Distance Vector Multicast Routing Protocol).
As there were only isolated subnetworks that wanted to deal with DVMRP, the old MBone used tunnels to get multicast traffic between DVMRP subnetworks.
i.e., the multicast traffic was hidden and sent between the subnetworks via unicast.
This mechanism was simple, but required manual administration and absolutely could not scale to the entire Internet.
Worse, DVMRP requires substantial routing traffic behind the scenes and this grew with the size of the MBone.
Thus, the legend grew that multicast was a bandwidth hog.
Starting about 1997, the building blocks for a multicast-enabled Internet were put into place.
An efficient modern multicast routing protocol, Protocol Independent Multicast - Sparse Mode (PIM-SM), was deployed. (PIM also has Dense and Sparse-Dense modes, but these are not widely used.)
The mechanisms for multicast peering were established, using an extension to BGP called Multiprotocol BGP (MBGP), and peering became routine.
The service model was split into:
a one-to-many (or “broadcast”) part: a many-to-many part (e.g., for videoconferencing): Any-Source Multicast (ASM), and
Source-Specific Multicast (SSM).
By 2001, these had completely replaced the old MBone.
Cost-efficient distribution of data
Timely distribution of data
Robust distribution of data
“Data” here could be
Streamed Audio or Video
This is the core of the streaming case.
Unicast streaming is just too expensive.
This is true either on the commodity Internet or on the Intranet.
Multicast is especially compelling for video.
This is the argument for multicast in financial services.
In unicast, it takes time to send packets separately to each receiver.
Even if cost is not a problem, time may be.
Example: A DS3 would take 2 days to distribute a 100 megabyte file to 10,000 desktops. With multicast, this would take 18 seconds.
Multicasting is compelling here if timely distribution is important.
In some streaming or data distribution cases, the problem is handling sudden large increases in load.
Multicast was designed to handle sudden large increases in load.
Internet News “Melt-down”:Web Site Performance 9:00 AM to 10:00 AM
Site% Users able to access
ABCNews.com 0 %
CNN.com 0 %
NYTimes.com 0 %
USAToday.com 18 %
MSNBC.com 22 %
(source: Keynote’s Business Performance / Interactive Week 9/17/2001)
We had a large plasma screen in the iLabs [at Networld+Interop] intended to demonstrate high rate HDTV over I2. We came in Tuesday morning and were preparing for the first day of the show when word came in about the initial plane crash into the towers. Our I2 Lead, Roy Hockett was able to switch the stream to a CNN broadcast from UMich. We began attracting exhibitors to the display even before the showfloor opened. Once the attendees were on the floor, the crowd had grown to well over a hundred.
By this point, three things had happened. The crowds around the one display had grown so large as to constitute a fire hazard, all the major news web sites had completely melted down, and CNN was being multicast from several sources. We then started loading multicast tools on every PC in the NOC, from the one driving the large video wall to people's individual laptops. By 10:30 (about half an hour after the floor opened) we had at least 3 large displays as well as a number of normal monitors turned out towards the plexiglass walls.
Soon after, we had a good number of exhibitors come and ask how to get "the CNN viewer software.”
— Jim Martin, <firstname.lastname@example.org>
More than 1,000 copies of StreamPlayerII, our multicast MPEG viewer, were downloaded or handed out on disk between 9/11 and 9/12. We normally average 20 to 100 per day.
— Rich Mavrogeanes <email@example.com>
Sudden increase in Multicast traffic of at least 1000 group members
BANDWIDTH SAVED: in excess of 1 Gbps vs. unicast
Crowds viewing the 9/11 multicasts at Networld+Interop
IETF, NANOG: see videolab.uoregon.edu
Joint Techs: http://jointtechs.es.net/vancouver2005/netcast.html
Undersea exploration with Robert Ballard: www.explorethesea.com
Digital Video Transport Service (http://apps.internet2.edu/dvts.html) provides relatively cheap & painless high-quality network video, and is increasingly popular for a wide variety of uses.
DVTS over multicast is ideal for netcasting performance events.
DancingQ performance event: http://arts.internet2.edu/dancingq.html http://people.internet2.edu/%7Ebdr/CometDVIP/DanceQ.html
DV Guide: http://db.arts.usf.edu/dvguide/
Cable TV via campus networks: http://www.tss.northwestern.edu/nutv/helpguide/
C-SPAN over Abilene: http://www.i2-multicast.northwestern.edu/
Several other campuses (Cornell, Columbia, Duke...) have TV-over-IP projects, or are considering them
Open Student Television Network
"a national initiative of student television stations working together to build a digital channel of student television shows"
Set-top boxes are available from several vendors, e.g.:
Some corporations, particularly in the financial sector, pay big bucks to have cable news multicast on their intranets.
University of Hawaii uses multicast in its Hawaii Interactive Television Service
Two-way interactive video and audio to all UH campuses and education centers
Each classroom can view and converse with at least two other sites, and listen to additional sites
Each campus can receive and transmit multiple classes simultaneously
U. of HawaiiInteractive TV Locations and Staff Sites
www.accessgrid.org: "The Access Grid® is an ensemble of resources...used to support group-to-group interactions across the Grid."
survey of AG multicast issues:www.andrewpatrick.ca/multicast-survey/
Access Grid via VRVS:http://www.vrvs.org/Documentation/VAG/
While it seems clear that the killer app for multicast will involve video, there are other things you can do with it...
radio: www.onthei.com, www.kexp.org
file distribution (a popular intranet ASM application)
Please keep us informed about your current and planned applications!
e.g., video server
IP source = IP unicast addr
Ethernet source = MAC addr
IP destination = IP multicast addr
Ethernet dest = MAC addr
source = origin of multicast stream
multicast address = an IP address in the Class D range (188.8.131.52 – 184.108.40.206), used to refer to multiple recipients.A multicast address is also called a multicast groupor channel.
multicast stream = stream of IP packets with multicast address for IP destination address. All multicast uses UDP packets.
receiver(s) = recipient(s) of multicast stream
tree = the path taken by multicast data. Routing loops are not allowed, so there is always a unique series of branches between the root of the tree and the receivers.
For every multicast source there must be two pieces of information: the source IP address, S, and the group address, G.
These correspond to the sender and receiver addresses in unicast.
This is generally expressed as (S,G).
Also commonly used is (*,G) - every source for a particular group.
Group Management Protocol - enables hosts to dynamically join/leave multicast groups. Receivers send group membership reports to the nearest router.
Multicast Routing Protocol - enables routers to build a delivery tree between the sender(s) and receivers of a multicast group.
Group Management Protocol (e.g. IGMP)
Multicast Routing Protocol (e.g. PIM-SM)
The SENDERS send without worrying about receivers
Packets are sent to a multicast address (RFC 1700)
This is in the class D range (220.127.116.11 - 18.104.22.168)
The RECEIVERS inform the routers what they want to receive
done via Internet Group Management Protocol (IGMP), version 2 (RFC 2236) or later
The routers make sure the STREAMS make it to the correct receiving networks.
Multicast routing protocol: PIM-SM
PIM-SM - Protocol Independent Multicast - Sparse Mode is used to propagate forwarding state between routers.
IGMP - Internet Group Management Protocol is used by hosts and routers to tell each other about group membership.
Other Protocols (much more on these later in the workshop)
MBGP - Multiprotocol Border Gateway Protocol is used to exchange routing information for inter-domain reverse-path forwarding (RPF) checking.
MSDP - Multicast Source Discovery Protocol is used to exchange active-source information.
IPv4 Multicast Group Addresses
Class D Address Space
High order bits of 1st Octet = “1110”
Source sends to group address
Receivers receive traffic sent to group address
The multicast address block is 22.214.171.124 to 126.96.36.199
It is cumbersome to refer to address blocks in the above fashion. Address blocks are usually described using “CIDR notation”
This specifies the start of a block, and the number of bits THAT ARE FIXED.
In this shorthand, the multicast address space can be described as 188.8.131.52/4 or, even more simply, as 224/4. The fixed part of the address is referred to as the prefix, and this block would be pronounced "two twenty four slash four."
Note that the LARGER the number after the slash, the LONGER the prefix and the SMALLER the address block.
184.108.40.206 - 220.127.116.11 (224.0.0/24) - reserved & not forwarded
18.104.22.168 - All local hosts
22.214.171.124 - All local routers
126.96.36.199 - DVMRP
188.8.131.52 - OSPF
184.108.40.206 - Designated Router OSPF
220.127.116.11 - RIP2
18.104.22.168 - PIM
22.214.171.124 - VRRP
126.96.36.199 – IGMP
188.8.131.52 - 184.108.40.206 (232/8) - SSM
220.127.116.11 - 18.104.22.168 (239/8) - Administrative Scoping
“Ordinary” multicasts don’t have to request a multicast address from IANA.
TTL value defines scope and limits distribution
IP multicast packet must have TTL > interface TTL or it is discarded
No longer recommended as a reliable scoping mechanism
Administratively Scoped Addresses – RFC 2365
Private address space
Similar to RFC 1918 unicast addresses
Not used for global Internet traffic
Used to limit “scope” of multicast traffic
Same addresses may be in used in different sub-networks for different multicast sessions
Site-local scope: 22.214.171.124/16
Organization-local scope: 126.96.36.199/14
For a long time, this was a sore spot. There was no way to claim or register a Multicast Class D address like unicast address blocks can be registered.
For temporary teleconferences, this is not such a problem, but it does not fit well into a broadcast model.
Now, there are two solutions:
For SSM, addresses don’t matter, as the broadcast address is really unique as long as the (S,G) pair is unique.
For ASM, there is “GLOP”.
Provides globally available private Class D space
233.x.x/24 per AS number
Insert the 16-bit AS number into the middle two octets of the 233/8
Online GLOP calculator:www.shepfarm.com/multicast/glop.html
If you have an AS, you have multicast addresses.
GLOP based address assignment has worked well.
Every organization gets the same amount of space, a /24.
What if you need more?
There is an (as yet unused) mechanism for requesting more GLOP space: RFC 3138.
Is this unused because of lack of demand, or because the mechanism is not fully implemented?
Dave Thaler of Microsoft has proposed prefix-based assignment.
The idea is that every unicast address assignment you have is mapped into a multicast address range.
Take one of the unused multicast /8's
For a /N unicast assignment, the multicast address block becomes
[/8] [/N][24 - N bits of available addresses]
So, a /24 provides a /32; a /16 provides a /24; a /8 provides a /16
This would complement GLOP by giving larger organizations more addresses.