internet2 multicast workshop columbia university new york ny december 2005 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Internet2 Multicast Workshop Columbia University, New York, NY December 2005 PowerPoint Presentation
Download Presentation
Internet2 Multicast Workshop Columbia University, New York, NY December 2005

Loading in 2 Seconds...

play fullscreen
1 / 39

Internet2 Multicast Workshop Columbia University, New York, NY December 2005 - PowerPoint PPT Presentation


  • 103 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Internet2 Multicast Workshop Columbia University, New York, NY December 2005' - shoushan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
acknowledgements
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

Columbia University

NYSERNet

Cisco Systems

Juniper Networks

preliminaries
Preliminaries

Introductions

Instructors

Students

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.

preliminaries1
Preliminaries

Finding things at MITC

Meals, snacks, and coffee

Restrooms

Etc.

Workshop schedule

contents
Contents

Overview

Multicast on the LAN

Source-Specific Multicast (SSM)

Any-Source Multicast (ASM)

Intra-domain ASM

Inter-domain ASM

Troubleshooting Methodology

Best Current Practices; Future of Multicast

the basic idea
The Basic Idea

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.

unicast vs multicast
Unicast vs. Multicast

Unicast

Multicast

the mbone
The MBone

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.

multicast grows up
Multicast Grows Up

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.

what capabilities does ip multicast provide
What capabilities does IP Multicast provide ?

Cost-efficient distribution of data

Timely distribution of data

Robust distribution of data

“Data” here could be

Files

Streamed Audio or Video

cost efficient data distribution
Cost Efficient Data Distribution

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.

timely distribution of data
Timely Distribution of Data

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.

robust distribution of data
Robust Distribution of Data

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.

case study 9 11 2001
Case Study: 9/11/2001

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)

internet news performance on 9 11 2001
Internet News Performance on 9/11/2001
  • Of course, the “melt-down” was caused by the incredible demand for news after the attacks.
  • Unicast streaming web sites suffered similar problems, at least from anecdotal evidence
  • By contrast, multicast performed well
    • Large increase in traffic
    • Roughly 1 Gigabit per second saved at peak
    • Over time, the multicast peering mesh degraded, but this was NOT due to increased traffic
eyewitness accounts
Eyewitness Accounts

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, <jrm@nortelnetworks.com>

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 <rmavro@vbrick.com>

viewership
Viewership

Sudden increase in Multicast traffic of at least 1000 group members

  • Mostly viewing VBrick’s television broadcast
  • Measured viewership >830
  • But each measured point could have many individual viewers since they multicast locally

BANDWIDTH SAVED: in excess of 1 Gbps vs. unicast

Crowds viewing the 9/11 multicasts at Networld+Interop

how is multicast being used today
How is Multicast Being Used Today?
  • Network Video!
    • Netcast Events, TV over IP, Distance Learning, Collaboration
    • See https://mail.internet2.edu/wws/arc/bigvideo/
  • Other applications
  • Some examples follow...
video netcast events
Video: Netcast Events

Technical events

IETF, NANOG: see videolab.uoregon.edu

Joint Techs: http://jointtechs.es.net/vancouver2005/netcast.html

Scientific events

Undersea exploration with Robert Ballard: www.explorethesea.com

Performance events

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

video tv over ip
Video: TV over IP

DV Guide: http://db.arts.usf.edu/dvguide/

ResearchChannel: www.researchchannel.org/projects/i2wg/prj_multi.asp

Northwestern University

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

www.ostn.tv

"a national initiative of student television stations working together to build a digital channel of student television shows"

video tv over ip1
Video: TV over IP

Set-top boxes are available from several vendors, e.g.:

www.vbrick.com/products/EtherneTV-stb.asp

www.aminocom.com

www.i3micro.com

www.2wire.com

www.bastinc.com

Some corporations, particularly in the financial sector, pay big bucks to have cable news multicast on their intranets.

video distance learning
Video: Distance Learning

University of Hawaii uses multicast in its Hawaii Interactive Television Service

http://www.hawaii.edu/dl/general/

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

video distance learning1
Video: Distance Learning

U. of HawaiiInteractive TV Locations and Staff Sites

video collaboration
Video: Collaboration

Access Grid:

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/

other applications
Other Applications

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)

NNTP

Please keep us informed about your current and planned applications!

See https://mail.internet2.edu/wws/arc/wg-multicast

essential multicast terminology
Essential Multicast Terminology

e.g., video server

IP source = IP unicast addr

Ethernet source = MAC addr

IP destination = IP multicast addr

Ethernet dest = MAC addr

receivers

source

Multicast stream

source = origin of multicast stream

multicast address = an IP address in the Class D range (224.0.0.0 – 239.255.255.255), 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.

s g notation
(S,G) notation

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.

essential multicast protocols
Essential Multicast Protocols

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.

  • Receivers
  • Delivery tree
  • Membership reports
  • Senders

Group Management Protocol (e.g. IGMP)

Multicast Routing Protocol (e.g. PIM-SM)

multicast building blocks
Multicast Building Blocks

The SENDERS send without worrying about receivers

Packets are sent to a multicast address (RFC 1700)

This is in the class D range (224.0.0.0 - 239.255.255.255)

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

multicast protocol summary
Multicast Protocol Summary

Essential Protocols

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.

multicast addressing
Multicast Addressing

IPv4 Multicast Group Addresses

224.0.0.0–239.255.255.255

Class D Address Space

High order bits of 1st Octet = “1110”

Source sends to group address

Receivers receive traffic sent to group address

cidr address notation
CIDR Address Notation

The multicast address block is 224.0.0.0 to 239.255.255.255

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 224.0.0.0/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.

multicast addressing1
Multicast Addressing

RFC 3171

http://www.iana.org/assignments/multicast-addresses

Examples:

224.0.0.0 - 224.0.0.255 (224.0.0/24) - reserved & not forwarded

224.0.0.1 - All local hosts

224.0.0.2 - All local routers

224.0.0.4 - DVMRP

224.0.0.5 - OSPF

224.0.0.6 - Designated Router OSPF

224.0.0.9 - RIP2

224.0.0.13 - PIM

224.0.0.18 - VRRP

224.0.0.22 – IGMP

232.0.0.0 - 232.255.255.255 (232/8) - SSM

239.0.0.0 - 239.255.255.255 (239/8) - Administrative Scoping

“Ordinary” multicasts don’t have to request a multicast address from IANA.

scoping
Scoping

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

239.0.0.0–239.255.255.255

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

Examples

Site-local scope: 239.253.0.0/16

Organization-local scope: 239.192.0.0/14

multicast address allocation
Multicast Address Allocation

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”.

multicast addressing2
Multicast Addressing

GLOP addresses

Provides globally available private Class D space

233.x.x/24 per AS number

RFC 2770

How?

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.

expanding multicast address assignment
Expanding MulticastAddress Assignment

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?

prefix based multicast address assignment
Prefix-based Multicast Address Assignment

Dave Thaler of Microsoft has proposed prefix-based assignment.

draft-ietf-mboned-ipv4-uni-based-mcast-02.txt

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.