Engineering Workshops Internet2 Multicast Workshop Florida International University February 2003.

Engineering Workshops

Internet2 Multicast Workshop

Florida International UniversityFebruary 2003


22

Acknowledgements

Greg ShepherdMarshall Eubanks

Bill NicklessPatrick Dorn

University of OregonCisco Systems

Juniper NetworksFlorida International University


33

Contents

• Overview• Multicast on the LAN• Source-Specific Multicast (SSM)• Any-Source Multicast (ASM)

– Intra-domain ASM– Inter-domain ASM

• Making the Case for Multicast


44

Overview


55

The Basic Idea

Rather than 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.


66

Unicast vs. MulticastMulticastUnicast


77

Some Uses for Multicast

• Any application with multiple receivers– one-to-many or many-to-many

• Live video distribution• Collaborative groupware• Periodic data delivery - “push” technology

– stock quotes, sports scores, magazines, newspapers

– advertisements


88

Some More Uses for Multicast

• Server/web site replication• Reducing network/resource overhead

– more efficient to establish multicast tree rather than multiple point-to-point links

• Resource discovery• Distributed interactive simulation

– war games– virtual reality


99What Happened to Multicast?

What Happened to Multicast?

• By 1995, multicast seemed well on its way to adoption.– The MBone (Multicast backBone) had been set up and

was growing.– Audiocasts and Videocasts of meetings, seminars, etc.,

were fairly routine.– Serious interest was coming from industry.

• So why isn’t it ubiquitous now ?– The hype got ahead of the technology!– The original technology was not suitable for adoption

throughout the Internet. Basic parts had to be re-engineered.

– This took from 1997 to early 2001.


1010

The MBoneThe 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.


1111

Multicast Grows UpMulticast 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.

–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 many-to-many part (e.g., for videoconferencing):

Any-Source Multicast (ASM), and • a one-to-many (or “broadcast”) part:

Source-Specific Multicast (SSM).• By 2001, these had completely replaced the old MBone.• This path is not unusual for new technology...


1212

The Life Cycle of New Technologies in General

(From Lawrence Orans of Gartner)


1313

The Life Cycle of Multicast in Particular


1414

Deployment of MulticastDeployment of Multicast• Multicast Technologies has been monitoring the state of

multicast since April, 2001. Deployment is at 5% to 15%.

From http://www.multicasttech.com/status/


1515

Multicast Terminology: the basics

• 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 group or channel.

• multicast stream = stream of IP packets with multicast address for IP destination address.

• (S,G) = (source, group) reference• All multicast uses UDP packets

• receiver(s) = recipient(s) of multicast stream

IP source = IP unicast addrEthernet source = MAC addr

IP destination = IP multicast addr Ethernet dest = MAC addr

source

Multicast stream

receivers

e.g., video server


1616

Multicast Protocol Summary

• IGMP - Internet Group Management Protocol is used by hosts and routers to tell each other about group membership.

• PIM-SM - Protocol Independent Multicast-Sparse Mode is used to propagate forwarding state between routers.

• MBGP - Multiprotocol Border Gateway Protocol is used to exchange routing information for inter-domain RPF checking.

• MSDP - Multicast Source Discovery Protocol is used to exchange active source information between RPs.


1717

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


1818

IP 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


1919

Essential IP 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.

Senders

Receivers

Group Management Protocol (e.g. IGMP)

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

Delivery treeMembership reports


2020

• Multicast Routing can be thought of as the reverse of

Unicast Forwarding.

– Unicast Forwarding is concerned with where the

packet is going.

– Multicast Routing is concerned with where the

packet will be coming from.

• Multicast paths to many receivers form a “tree”.

The tree is built (or torn down) from the receiver back

toward the source (or, if there is more than one

source, the Rendezvous Point, or core).

Multicast Routing


2121

PIM-SM

Protocol Independent Multicast - Sparse Mode– The core multicast protocol: builds and

tears down multicast trees– draft-ietf-pim-sm-v2-new-06.txt

obsoletes RFC 2362; bootstrap router removed from PIM spec

– explicit join: assumes that not everyone wants the data

– uses externally-provided reachability table to build forwarding topology


2222

Multicast Distribution Trees

• The path taken by data from the source to receivers is called the “tree”– Routing loops are not allowed, so there is

always a unique series of branches between the root of the tree and the receivers.

– For each receiver, the tree is the shortest path from the source or core / RP to the receiver. The tree is built based on RPF reachability information.


2323

Reachability• When a unicast packet shows up on an interface, the

destination address is looked up in the unicast forwarding table to determine where the router should send the packet next.

• When a multicast (S,G) Join shows up on an interface, the source address, S, is looked up in the reverse-path forwarding (RPF) table to determine how the router should join the source-based forwarding tree. This information is used to build the multicast forwarding tree.

• The unicast forwarding table and the RPF table contain the same kind of information — unicast routes, or reachability information — and may in fact be the same table.

• The point of having separate tables is to enable separate policies and paths for unicast forwarding and RPF. You need MBGP, IS-IS, or static mroutes to do this.

• Once the multicast forwarding tree is built, multicast forwarding works similarly to unicast forwarding.


2424

Multicast Distribution Trees Shortest-path or Source-based Distribution

Tree

Group Member 1

Source

Group Member 2

State Information: (S, G) S = Source G = Group


2525

Multicast Distribution Trees

Group Member 1

Source 1

Group Member 2

State Information: (*, G) * = Any Source G = Group

Shared or Core-Based Distribution Tree

Source 2

Rendezvous Point (RP), aka Core


2626

• Source or Shortest-Path trees– More resource intensive; requires more state n(S x

G)– You get optimal paths from source to all receivers,

which minimizes delay– Best for one-to-many distribution

• Shared or Core-Based trees– Uses less resources; requires less memory n(G) – You may get suboptimal paths from source to all

receivers, depending on topology– The rendezvous point (core) itself and its location may

affect performance– Best for many-to-many distribution– Necessary for in-band source discovery

Multicast Distribution Trees Compared


2727

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; receiver

receives from group address– 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


2828

CIDR Address NotationCIDR 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.


2929


• RFC 3171• http://www.iana.org/assignments/multicast-addresses• Examples of Reserved & Link-local Addresses

• 224.0.0.0 - 224.0.0.255 reserved & not forwarded• 239.0.0.0 - 239.255.255.255 Administrative Scoping• 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.15 - CBT• 224.0.0.18 - VRRP

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


3030


• 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


3131

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


3232


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.


3333

Multicast on the LAN


3434

Multicast Addressing at Layer 2

• An IPv4 multicast address is 32 bits, of which the first 4 bits are always the same, leaving 28 bits.

• A MAC multicast address is 48 bits, of which the first 24 bits are always the same. One of the remaining bits is reserved, leaving 23 bits.

• So, one multicast MAC address maps to 32 multicast IP addresses.


3535

000000010000000001011110

0 8 31

0

32-bit IP address

48-bit Ethernet address

00 24

0 = Internet multicast1 = Reserved for other use

IANA owns 01-00-5E vendor address block; half of it is assigned for IP multicast.

IEEE Ethernet multicast bit

1110 ignored, leaving 28 bits

47

Ethernet Multicast Addressing

23 bits

01-00-5E-

Class D address

00-00-00 thru 7F-FF-FF


3636

IGMP• Internet Group Management Protocol - how hosts tell routers

about group membership• Routers also solicit group membership from directly connected

hosts• RFC 1112 specifies version 1 of IGMP

– Supported on Windows 95• RFC 2236 specifies version 2 of IGMP

– Supported on latest service pack for Windows, newer Windows releases, and most UNIX systems

• RFC 3376 specifies version 3 of IGMP– provides source include-list capabilities (SSM!)– Support?

• FreeBSD patch, Linux patch, Window XP• www.shepfarm.com/multicast/


3737

IGMPv2• Router:

– sends Membership Query messages to All Hosts (224.0.0.1)• query-interval = 125 secs default

– router with lowest IP address is Querier (rest non-queriers)– If lower-IP address query heard, back off to non-querier state

• Other Querier Present Interval default: (robust-count x query-interval) + (0.5 x query-response-interval) = 255 secs

– listens for reports (whether querier or not) and adds group to membership list for that interface

• query-response-interval = 10 secs default– timeout (Group member interval) default:

• (robust-count x query-interval) + (1 x query-response-interval) = 260 sec

– robust-count - provides fine-tuning to allow for expected packet loss on a subnet. Default = 2 (tunable from 2-10)


3838

IGMPv2• Host:

– sends Membership Report messages, if joined• waits 0-10 sec (default) • Hosts listen to other host reports• Only 1 host responds

– sends unsolicited Membership Reports (i.e., Join Messages) to group address (e.g. 224.10.8.5)

– sends Leave messages to All Routers (224.0.0.2)– reports group membership ONLY – no sources.

Only the existence of local group members is reported, not the actual members themselves


3939

IGMP Protocol Flow - Join a Group

• Router triggers group membership request to PIM.• Hosts can send unsolicited join membership messages

– called reports in the RFC (usually more than 1)• Or hosts can join by responding to periodic query from

router

I want 230.0.0.1

230.0.0.1

230.0.0.1Forwards stream

Router adds group

I want to JOIN!

230.0.0.1


4040

IGMP Protocol Flow - Querier

• Hosts respond to query to indicate (new or continued) interest in group(s)– only one host should respond per group

• Hosts fall into idle-member state when same-group report heard.

• After 260 sec with no response, router times out group.

224.0.0.1

Still interested?

(general query)

224.0.0.1125 sec

I want 230.0.0.1

230.0.0.1

230.0.0.1

0-10 sec

230.0.0.1 group

Yes, me!


4141

IGMP Protocol Flow - Leave a Group

• Hosts that support IGMPv2 send leave messages to all-routers group indicating group they’re leaving.– Router follows up with 2 group-specific queries messages

• IGMPv1 hosts leave by not responding to queries (260 sec timeout)

I don’t want 230.0.0.1 anymore

224.0.0.2<230.0.0.1>

230.0.0.1 group

I wantto leave!

Anyone still want this group?

224.0.0.1<230.0.0.1>

224.0.0.1<230.0.0.1>

1 sec (re-transmit timer)


4242

Soft State• Say I set up an active Multicast group, say by

issuing a membership report. What happens if my computer goes down and never directly leaves the group ?

• This is fixed with “Soft State”– Everything has a timer, and if not periodically

reinitiated the timer will expire and the state will be removed.

– So there is no danger of some rogue group lasting forever.


4343

Source = 1.1.1.1Group = 224.1.1.1

H1 - Member of 224.1.1.1

R1

R3

R2

Source = 2.2.2.2Group = 224.1.1.1

IGMPv3: MODE_IS_INCLUDEJoin 1.1.1.1, 224.1.1.1

IGMPv3

• H1 wants to receive from S = 1.1.1.1 but not from S = 2.2.2.2

• With IGMPv3, specific sources can be pruned back - S = 2.2.2.2 in this case

Specified in RFC 3376Enables hosts to listen only to a specified subset of the sources sending to the group

Video Server

Video Server


4444

IGMPv3 Enhancements

– Group-Source Report message is defined. Enables hosts to specify which senders it can receive or not receive data from.

– Group-Source Leave message is defined. Enables host to specify the specific IP addresses of a (source,group) that it wishes to leave.


4545

Lab 1: Multicast on the LAN


4646

SSM


4747

PIM-SM• SM stands for “Sparse Mode.”

– RFC 2362 and draft-ietf-pim-sm-v2-new-06.txt – There is also a Dense Mode but we don’t recommend

using it.– Cisco has a proprietary “Sparse-Dense” mode which

they use for RP discovery.

• PIM-SM allows for both Shared Trees (STs) from a Rendezvous Point (RP) and Shortest Path Trees (SPTs) from the source.– Note that STs are shortest path, just to the RP.

• There are two ways to use PIM-SM…


4848

ASM and SSM• ASM: Any-Source Multicast. Traditional multicast – data

and joins are forwarded to a Rendezvous Point (RP). – all routers in a PIM domain must have RP mapping– when load exceeds threshold, forwarding swaps to

shortest path tree. The default threshold is one packet; in this case, the sole purpose of the ST is to learn which sources are active (with IGMPv2, the receiver can only specify the group, not specific sources.)

– state increases (not everywhere) as number of sources and number of groups increase

– source-tree state is refreshed when data is forwarded and with Join/Prune control messages

• SSM: Source-Specific Multicast. PIM-SM without RPs – instead, source is learned out-of-band, and shortest-path tree is built directly to it.


4949

SSMSSM• Source-Specific Multicast (SSM) is a subset of ASM,

so – SSM concepts apply directly to ASM, but– SSM is a lot simpler than ASM.

For these reasons, we cover SSM first in this workshop.

• 232 / 8 is assigned to SSM as an address space. Other address ranges can also be set up for SSM -- this is primarily a function of the receiving network.

• Source activity and IP addresses are assumed known, say through a web page.

• IGMPv3 allows for “Include” lists of (S,G) pairs.


5050

SSM• SSM - draft-ietf-ssm-arch-01.txt

– 232/8 – IANA assigned– No shared trees– Guarantees ONE source on any delivery tree

• Content security – no unwanted sources– Reduced protocol dependence – more later...– Solves address allocation issues for inter-domain one-to-many

• tree address is 64 bits – S,G– Host must learn source address out-of-band (e.g, from a web

page)– Host-to-router join request specifies source as well as group

• requires IGMPv3 for include-source list– Hard-coded behavior in 232/8

• Configurable to expand range


5151

SSM in ActionSSM in Action• Each (S,G) pair listed in the IGMPv3

include list generates a (S,G) join directly towards the source.

• That’s it. It’s very simple. All you need to implement is :– Edge routers need IGMP version 3– Interior Routers need filters to prevent

RP (*,G) joins & other RP state for the SSM address block


5252

SSM Group AddressesSSM Group Addresses• 232 / 8 is assigned to SSM as an address

space. – You don’t have to ask, you can just

pick one and use it.• How can this be ?

– Note that all joins are unique as long as the combination of S and G are unique. Not only can one source support multiple groups, but if there are two sources using the same Group address, everything works just fine.


5353

SSM

Receiver

RP

Receiver announces desireReceiver announces desireto join group G AND source to join group G AND source SSwith an IGMPv3 include-list.with an IGMPv3 include-list.IGMPv3 host report

(S, G) JoinLast-hop router joins the Source Tree.

Source

Source Tree

Traffic Flow (S,G) state is built between the source and the receiver.


5454

SSM

Receiver

RP

Data flows down the source Data flows down the source tree to the receiver.tree to the receiver.

Source

Source Tree

Traffic Flow


5555

Lab 2: SSM


5656

ASM


5757

ASM• Allows Source Trees or Shared Trees• Rendezvous Point (RP)

– Matches senders with receivers– Provides network source discovery– Root of shared tree

• Typically use shared tree to bootstrap source tree• RP’s can be learned via:

– Static configuration – RECOMMENDED– Auto-RP (PIM-SM v1 & v2)– Bootstrap Router (PIM-SM v2)


5858

The Original Multicast Service Model

The Original Multicast Service Model

• From RFC 1112 :– Packet transmission is based on UDP, so packet delivery is

“best-effort”, with no loss detection or retransmission– A source can send multicast packets at any time, with no

need to register or schedule transmissions.– Sources do not know the group membership. A group may

have many sources and many members.– Group members may come and go at will, with no need to

coordinate with a central authority.– And, critically, group members know only the group. They

need know nothing about sources - not even if any exist.• This is the ASM paradigm. It requires sender registration

and tree-switching, which make it much more complex than SSM.


5959

Designated Router (DR)• Neighboring PIM-SM routers multicast periodic “Hello” messages

to each other - default 30 seconds– Hello-interval tunable for faster convergence

• On receipt of a Hello message– a router stores the IP address and priority for that neighbor

• Router with highest IP address is selected as the DR, if the priorities match

• When DR goes down:– new one selected by scanning all neighbors on the interface

and choosing the one with the highest IP address• DR sends

– “Join/Prune” messages toward the RP from receiver network– “Register” messages toward the RP from source network


6060

Intra-domain ASM


6161

ASM Shared Tree Join

Receiver

RP

(*, G) Join

Shared Tree

(*, G) State created from the RP to the receiver.

Receiver announces desireto join group G with igmpv2host report – (*,G).

IGMPv2 host report First hop router sends PIM (*,G) join toward the RP; subsequent routers do likewise.

First hop router sends PIM (*,G) join toward the RP; subsequent routers do likewise.


6262

ASM Sender Registration

Receiver

RPSource

(S, G) State created onlyalong the Source Tree.

Shared Tree

Source Tree

Traffic Flow(S, G) Register (unicast)

(S, G) Join

Active source triggers first-hoprouter (S,G) Register message to RP.

RP sends (S,G) Join to source.


6363


Receiver

RP

Shared Tree

Source Tree

RP sends a Register-Stop back to the first-hop router to stop the Register process.

(S, G) Register-Stop (unicast)

Traffic Flow(S, G) Register (unicast)

(S, G) traffic begins arriving at the RP via the Source tree.

Source


6464


Receiver

RP

Source traffic flows nativelyalong SPT to RP.

From RP, traffic flows downthe Shared Tree to Receivers.

Source

Source Tree

Shared Tree

Traffic Flow


6565

How can PIM do both SPTs and STs ?

• PIM-SM includes a mechanism for switching between a tree based on the RP and one based on the Source.– Generally, this is configured to happen

immediately, i.e., at most one packet flows down the ST.

– This means that the placement of the RP and the speed of the links to it are not so important.

• This gets pretty complicated !


6666

How PIM Switches Trees1.) Source sends data to its First Hop Router.2.) First Hop Router encapsulates it and unicasts it

to the RP in a Register message.3.) If the RP has receivers that belong to the

group, it sends the data down the shared tree.Receivers may join before or after the source

starts.Receivers join just the group (i.e., a (*,G) join).

4.) The RP issues a (S,G) join towards the source, S, in order to receive the data through multicast.


6767

Switching Trees (cont’d)5.) The routers in the path learn about the

particular S from the traffic down the shared tree.

6.) The receiver’s first hop router issues a (S,G) join towards the source.

7.) This travels hop by hop towards the source until it finds a router with (S,G) state - maybe at the source, maybe closer.

8.) The (S,G) data start flowing directly from the source to the receiver.


6868

Yet more on Switching Trees9.) Some router in the ST is receiving two

copies of the data, from the SPT and the ST. 10.) This router drops the ST data from the RP,

and issues a (S,G) leave message towards the RP.

11.) This travels hop by hop towards the RP, pruning the state, until it reaches a router that needs the (S,G) data for some other receiver.


6969

ASM SPT Cutover

Receiver

RP

(S, G) Join

Last-hop router joins the Source Tree.

Additional (S, G) State is created along new part of the Source Tree.

Source

Source Tree

Shared Tree

Traffic Flow


7070

ASM SPT Cutover

Receiver

RP

Source Tree

Shared Tree

(S, G) RP-bit Prune

Traffic begins flowing down the new branch of the Source Tree.

Additional (S, G) State is created along the Shared Tree to pruneoff (S, G) traffic.

Traffic Flow

Source


7171

ASM SPT Cutover

Receiver

RP

Source Tree

Shared Tree

(S,G) Traffic flow is now pruned off of this branch of the Shared Tree and is flowing to the Receiver via the Source Tree.

Traffic for other sources may still be flowing down the Shared Tree.

Traffic Flow

Source


7272

ASM SPT Cutover

Receiver

RP

Source Tree

Shared Tree

(S, G) traffic flow is no longer needed by the RP so it Prunes the flow of (S, G) traffic.

Traffic Flow

(S, G) Prune

Source


7373

ASM SPT Cutover

Receiver

RP

Source Tree

Shared Tree

(S, G) Traffic flow is now only flowing to the Receiver via a single branch of the Source Tree.

Traffic Flow

Source

RP maintains list of all active sources.


7474

ASM Configuration• RP Mapping options

– Static RP• Recommended• Easy transition to Anycast-RP• Allows for a hierarchy of RPs

– Auto-RP• Fixed convergence timers (slow)• Must flood RP mapping traffic

– bootstrap router• No longer in the PIM spec.• Fixed convergence timers (slow)• Allows for a hierarchy of RPs


7575

Lab 3: Intra-domain ASM


7676

Inter-domain ASM


7777

MBGP

• Multiprotocol extensions to BGP

• MBGP overview

• MBGP capability negotiation

• Multicast Reachability


7878

MBGP Overview

• MBGP: Multiprotocol BGP(aka multicast BGP in multicast networks)– Makes it possible for multicast routing policies to

differ from unicast routing policies– Defined in RFC 2283 (extensions to BGP)– Can carry different route types for different purposes

• Unicast• Multicast

– Both route types carried in same BGP session– Does not propagate multicast state information– Same path selection and validation rules

• AS-Path, LocalPref, MED, …


7979

MBGP

• Tag unicast prefixes as multicast source prefixes for intra-domain mcast routing protocols to do RPF checks.

• WHY? Allows for inter-domain RPF checking where unicast and multicast paths are non-congruent.

• DO I REALLY NEED IT? – YES, if:

• ISP to ISP peering• Multiple-homed networks

– NO, if:• You are single-homed


8080

New multiprotocol attributes

• MP_REACH_NLRI and MP_UNREACH_NLRI– Address Family Information (AFI) = 1 (IPv4)

• Sub-AFI = 1 (NLRI is used for unicast forwarding)

• Sub-AFI = 2 (NLRI is used for multicast RPF check and MSDP peer-RPF check)


8181

MBGP—Capability Negotiation• BGP routers establish BGP sessions through the OPEN message• OPEN message contains optional parameters• BGP session is terminated if OPEN parameters are not

recognised• New parameter: CAPABILITIES

• Multiprotocol extension• Multiple routes for same destination

• Configures router to negotiate either or both NLRI– If neighbor configures both or subset, common NRLI is used

in both directions– If there is no match, notification is sent and peering doesn’t

come up– If neighbor doesn’t include the capability parameters in

open, session backs off and reopens with no capability parameters

• Peering comes up in unicast-only mode


8282

JunOS: RIBs & RIB groups

• Routing Information Base (RIB)– Simply a routing table with a purpose

• RIB Group– Primary import RIB– Optional list of secondary import RIBs– Export RIB

• Well-known JunOS RIBs– Inet.0 – Primary unicast RIB (Sub-AFI = 1)– Inet.1 – Multicast forwarding RIB– Inet.2 – Multicast reachability– Inet.3 – MPLS RIB– Inet.4 – MSDP SA RIB


8383

Cisco IOS Multicast Reachability• Unicast forwarding never uses the

AF=Multicast reachability topology• PIM uses both the AF=Unicast and the

AF=Multicast topologies– Use show ip rpf to see what’s really going

on– show ip mbgp lets you see some

AF=Multicast routes


8484

Cisco IOS Multicast Reachability

• Distance-preferred lookups (default)– Every route has an “administrative distance”– “Best match” is the route with the lowest

administrative distance, regardless of Address Family

• Longest-prefix match (hidden command option)– Top-level configuration: ip multicast longest-

match– Best match is the most specific route in either the

AF=Multicast or AF=Unicast tables.

• Ties between AF=Multicast and AF=Unicast routes– Broken in favor of the AF=Multicast route


8585


Example 1: • 140.221.201.0/24 AF=Multicast AD=20

Ethernet 0/0140.221.201.128/27 AF=Unicast AD=200

Ethernet 0/1• Distance-Preferred Lookup of 140.221.201.129

– Administrative Distance of 20 dominates, so show ip rpf 140.221.201.129 will select Ethernet 0/0

• Longest-prefix Match Lookup of 140.221.201.129– Longest prefix of /27 dominates, so show ip rpf

140.221.201.129 will select Ethernet 0/1


8686


Example 2: •140.221.201.0/24 AF=Multicast AD=200

Ethernet 0/0140.221.201.0/24 AF=Unicast AD=200

Serial 0/0• Ties are broken in favor of the AF=Multicast route

–show ip rpf 140.221.201.161 will select Ethernet 0/0

Note that the default in IOS is to make the unicast AD and multicast AD equal, as in this example.


8787

MBGP—Summary

• Solves part of inter-domain problem

– Can exchange unicast prefixes for multicast RPF checks

– Uses standard BGP configuration knobs

– Permits separate unicast and multicast topologies if desired

• Still must use PIM to:

– Build distribution trees

– Actually forward multicast traffic


8888

Lab 4: MBGP & Inter-domain SSM


8989Inter-domain ASM and MSDP

Inter-domain ASM and MSDP

• A PIM domain is a network in which all routers use the same RP for any given multicast group.

• Inter-domain SSM is easy. Because you know the IP address of the source, you can issue PIM joins that leave your PIM domain and travel hop by hop across as many PIM domains as necessary.

• Inter-domain ASM requires another protocol: Multicast Source Discovery Protocol (MSDP).– Why? Because even if the receiver knows the source

address, S, it’s still restricted to sending only (*,G) joins. And the RP in the receiver's PIM domain can't help join it with the source, because the source is in a different PIM domain and therefore registering to a different RP. MSDP is needed for the receiver's RP to find the (S,G).

– Officially, MSDP is a temporary solution. We shall see.


9090

MSDPMSDP• MSDP sets up peering between Rendezvous

Points (RPs) in different domains.– draft-ietf-msdp-spec-14.txt

• These MSDP Peer RPs pass Source Active (SA) messages for every (S, G) they know about.

• Your local RP thus knows about the source, and can implement a direct (S,G) join from the RP to the source.– This sets up an SPT to the local RP.– Then the routing can switch over to a direct SPT to

the receiver in the usual fashion.


9191

MSDP Operation

• MSDP peers (inter- or intra-domain)– TCP port 639 is used for communications between peers

• Higher IP address LISTENS and is passive• “FLOOD & join”

– SA (source active) packets periodically sent to MSDP peers indicating:

• source address of active streams• group address of active streams• IP address of RP originating the SA

– only originate SAs for your sources within your domain• “flood & JOIN”

– interested parties can send joins towards source (creates inter-domain source trees)


9292

MSDP Source Active Messages• Initial SA message sent when source first registers

– May optionally encapsulate first data packet• Supports SAP / SDR !!

– Should be treated as if it was a PIM register packet• Originating RP sends subsequent SA messages every

60 seconds, for as long as source remains active• Other MSDP peers don’t originate this SA but only

forward it if received• SA messages must be cached on router for new

group members that may join – Recent change to Draft– Reduces join latency– Prevents SA storm propagation


9393

MSDP Overview

SA Message192.1.1.1, 224.2.2.2

Domain C

Domain B

Domain D

Domain E

SA

SA

SA SA

SA

SA

Source ActiveMessages

SA

Domain A

SA Message192.1.1.1, 224.2.2.2

r

Join (*, 224.2.2.2)

MSDP Peers

RP

RP

RP

RP

sRP

Register192.1.1.1, 224.2.2.2


9494

MSDP Overview

Domain C

Domain B

Domain D

Domain E

Domain A

RP

RP

RP

RP

r

MSDP Peers

Join

(S

, 224

.2.2

.2)RP

s

Join

(S

, 224

.2.2

.2)


9595

MSDP Overview

Domain C

Domain B

Domain D

Domain E

Domain A

RP

RP

RP

RP

r

MSDP Peers

Multicast Traffic RP

s


9696

MSDP Overview

Domain C

Domain B

Domain D

Domain E

Domain A

RP

RP

RP

RP

r

MSDP Peers


s

Join

(S, 224.2.2.2)


9797

MSDP Overview

Domain C

Domain B

Domain D

Domain E

Domain A

RP

RP

RP

RP

r

MSDP Peers


s


9898

MSDP Peers (inter-domain case)

• MSDP establishes a neighbor relationship between MSDP peers– Peers connect using TCP port 639– Peers send keepalives every 60 secs (fixed)– Peer connection reset after 75 seconds if no MSDP

packets or keepalives are received• MSDP peers must have knowledge of multicast topology.

– May be an MBGP peer, a BGP peer or both– Required for peer-RPF checking of the RP address in the

SA to prevent SA looping. Note that this is not the same thing as the multicast routing RPF check.

– Exception: BGP is unnecessary when peering with only a single MSDP peer (default-peer)


9999

MSDP so far

• Allows RPs to share information about which sources in their domains are active sending.

• Interconnects RPs (MSDP Peers) between domains, using TCP connections to pass source active messages (SAs).

• Can also be used within a domain to provide RP redundancy (Anycast-RP).

• RPs send SA messages for internal sources to MSDP peers.• SAs are Peer-RPF checked before accepting or forwarding. • RPs learn about external sources via SA messages and

may trigger (S,G) joins on behalf of local receivers.• MSDP connections typically parallel MBGP connections.• Next: Peer-RPF checking in detail. This is complex.


100100

Receiving SA Messages(accept first match)

• Skip RPF Check and accept SA if:– Sending MSDP peer is default-peer– Sending MSDP peer = Mesh-Group peer

• RPF Check the received SA message– If the MSDP peer IS THE originating RP – then accept.– Lookup best MBGP path to RP in SA message

• Search rib-group as per config (MBGP inet.2 recommended)– If path to RP not found, RPF Check Fails; ignore SA

message– Is the sending MSDP Peer also an MBGP peer?

• Yes: Is best path to RP via this MBGP peer?– If yes, RPF Check Succeeds; process SA message

• No: Is the first AS in the best path to RP = the first AS in the best path to MSDP peer?

– If yes, RPF Check Succeeds; process SA message


101101

Receiving SA Messages

• RPF Check rule example cases

– Case 1: Sending MSDP Peer = iMBGP peer

• Is best path to RP via this MBGP peer?

– Case 2: Sending MSDP Peer = eMBGP peer

• Is best path to RP via this MBGP peer?

– Case 3: Sending MSDP Peer != BGP peer

• Is the next AS in best path to RP = AS of the

sending MSDP peer?


102102

RPF Check Example

MSDP/iMBGP peering

MSDP SA

AS13.1

4.2

4.12.1

MBGP Table router BA Destination Next hop AS path* 172.16.0.2/32 >172.16.3.1 i

MSDP Peers router B

Peer Address State 172.16.3.1 Established 172.16.4.1 Established

RPF Success!

Who is the iMBGP peer adverting this route?in our example 172.16.3.1

Is the MSDP == MBGP peer?

RPF rule when MSDP peer == iMBGP peer

Source

RP

A C

B

rp { local { address 172.16.0.2;


103103

RPF Check Example

AS1

MSDP/iMBGP peering

MSDP SA

MBGP Table router BA Destination Next hop AS path* 172.16.0.2/32 >172.16.3.1 i

3.1

4.2

4.12.1


MSDP Peers router B

Peer Address State 172.16.3.1 Established 172.16.4.1 Established

Who is the iMBGP peer adverting this route?In our example 172.16.3.1

Is the MSDP == MBGP peer?

RPF Failure!Source

RP

A C

B

RPF rule when MSDP peer == iMBGP peer


104104

RPF Check Example

AS1 AS3

MSDP/eMBGP peering

MSDP SA

MBGP Table

Destination Next Hop Path* 172.16.0.2/32 >172.16.3.1 1 i 172.16.0.2/32 172.16.4.1 3 1 i

3.1

4.2

4.12.1

MSDP Peers router B

MSDP Peer State 172.16.3.1 Established 172.16.4.1 Established

RPF rule when MSDP == MBGP peer

Who is the BGP peer advertising this route?

BGP Neighbours router B

Peer AS 172.16.3.1 1172.16.4.1 3

Source RPF Success!Is the AS of the sending MSDP peer == First AS in RP route?

RP


A C

B

MSDP SA

4.1

AS 2


105105

RPF Check Example

AS1

AS 2

AS3

MSDP/eMBGP peering

MSDP SA

BGP Table

Destination Next Hop Path* 172.16.0.2/32 >172.16.3.1 1 i 172.16.0.2/32 172.16.4.1 3 1 i

3.1

4.2

4.12.1

MSDP Peers router B

MSDP Peer State 172.16.3.1 Established 172.16.4.1 Established

Who is the BGP peer advertising this route?

BGP Neighbours router B

Neighbor AS 172.16.3.1 1172.16.4.1 3

Source RPF Failure!

RP

RPF rule when MSDP == MBGP peer

Is the AS of the sending MSDP peer == First AS in RP route?


A C

B


106106

RPF Check Example

MSDP/eMBGP peering

MSDP SA

BGP Table router B

Destination Next Hop Path*172.16.0.2/32 >172.16.3.1 1 i 172.16.0.2/32 >172.16.4.1 3 1 I*172.16.4.0/24 >172.16.4.1 3 i*172.16.3.0/24 >172.16.3.1 1 i

MSDP Peers router B

MSDP Peer State 172.16.3.1 Established172.16.4.1 Established

RPF rule when MSDP != MBGP peer

AS1 AS3

3.1

4.2

4.12.1

Source RPF Success!

Is the first AS in the path to the MSDP peer == First AS in best path to the RP?

AS 2

RP


A C

B


107107

RPF Check Example

MSDP/eMBGP peering

MSDP SA

BGP Table router B

Destination Next Hop Path*172.16.0.2/32 >172.16.3.1 1 i 172.16.0.2/32 >172.16.4.1 3 1 I*172.16.4.0/24 >172.16.4.1 3 i*172.16.3.0/24 >172.16.3.1 1 i

MSDP Peers router B

MSDP Peer State 172.16.3.1 Established172.16.4.1 Established

AS1 AS3

RP

3.1

4.2

4.12.1

Source RPF Failure!

RPF rule when MSDP != MBGP peer

AS 2


A C

B

Is the first AS in the path to the MSDP peer == First AS in best path to the RP?


108108

MSDP debug

• The only way to check why an MSDP SA is/isn’t accepted is to turn on MSDP debug printout. If you do this, watch out! Lots of messages will follow! It may kill your router.

• See current MSDP Internet Draft for details.


109109

MSDP Application: Anycast-RP• draft-ietf-mboned-anycast-rp-08.txt• Within a domain, deploy more than one MSDP Peer

RP for the same group range• Sources from one RP are known to other RPs using

MSDP• Give each RP the same /32 IP address• Sources and receivers use closest RP, as

determined by the IGP• Used intra-domain to provide redundancy and RP

load sharing, when an RP goes down, sources and receivers are taken to new RP via unicast routing– Fast convergence!– Becoming best common practice for large networks


110110

MSDP Application: Anycast-RP

• Rules are fairly simple- Have e-MSDP peers and i-MSDP peers

• If a mesh group member originates a SA message– Send to all i-MSDP peers and any e-MSDP peers

• If a mesh group member receives a SA message from an i-MSDP peer– send to any e-MSDP peers– Do NOT send to other i-MSDP peers

• If a mesh group member received a SA message from a e-MSDP peer– Check RPF - If passes, then– Flood to all i-MSDP peers and any other e-MSDP peers.


111111

Anycast-RP

RP2 – lo0Y.Y.Y.Y10.0.0.1

Rec

RecRecRecRec

Rec

SrcSrc

Src

RP1 – lo0X.X.X.X10.0.0.1

MSDPMSDP


112112

Anycast-RP

RP2 – lo0Y.Y.Y.Y10.0.0.1

Rec

RecRecRecRec

Rec

SrcSrc

Src

RP1 – lo0X.X.X.X10.0.0.1

XX


113113

Lab 5: MSDP & Inter-domain ASM


Cisco Multicast Forwarding State Flags


115115

D – Dense Mode Flag

• The D flag indicates that the multicast group is a dense mode group.

• Appears only on (*,G) entries


116116

S – Sparse Mode Flag

• The S flag indicates that the multicast group is a sparse mode group.

• Appears only on (*,G) entries


117117

s – SSM Group Flag

• Shows up on (*,G) entries for SSM groups• Incoming and Outgoing Interfaces are Null• SSM group (*,G) parent entries exist only

for internal data structure purposes


118118

L – Local Flag

• The L flag indicates that the router itself is a member of the group.

• The router will process the traffic at the route processor.

• Example: PIM RP-Discovery (224.0.1.40)


119119

C – Connected Flag

• The C flag indicates that there’s a directly connected receiver.

• Shows up on (*,G) state from IGMPv2 Host Membership reports.

• Shows up on (S,G) state from IGMPv3 Host Membership reports (without INCLUDE lists).


120120

I – Source Specific Host Report

• The I flag indicates that the directly connected receiver indicated that it wants traffic from a specific source on the specific group.

• Shows up on (S,G) state created by IGMPv3 Host Membership reports (with INCLUDE lists).


121121

U – URD

• Shows up on (S,G) entries created by the Cisco-Proprietary URL Redirect protocol (URD)

• URD provides SSM semantics on networks/hosts that don’t support IGMPv3 natively.

• Host sends special HTTP request towards the last-hop router on TCP port 659, which specifies the source and group address.

• Router intercepts that HTTP request and creates this (S,G) state.


122122

P – Pruned Flag

• The P flag indicates that either:

(1) the outgoing interface list (OIL) is Null-or-

(2) all interfaces in the outgoing interface list (OIL) are in the Prune state

• The P flag results in a Prune being sent to the upstream neighbor for this (S,G) entry.


123123

T – SPT Flag

• The T flag (or SPT) flag indicates that traffic is being forwarded via the (S,G) entries. That is, on Source-Specific Tree.

• Appears only on (S,G) entries


124124

J – Join SPT flag on (*,G)

• Appears on (*,G) entries when the C flag is set (there’s a locally connected receiver).

• Set when traffic rate on the Shared Tree exceeds the SPT-Threshhold.

• When set, the next packet down the (*,G) Shared Tree will create separate (S,G) state. (SPT-cutover)


125125

J – Join SPT flag on (S,G)

• (S,G) created by SPT-cutover.• PIM checks the rate every minute to decide

whether there’s enough traffic to justify maintenance of the (S,G) state.


126126

R – RP-bit flag

• Shows up on (S,G) entries only• The (S,G) entry’s RPF is towards the RP

(not towards S)• The output interface list is often Null, or a

subset of the output interface list on the (*,G) parent entry

• Used to prune (S,G) traffic from the shared tree when downstream routers have joined the SPT tree instead


127127

F – Register flag

• F flag means that Register messages are being sent to the Rendezvous Point (RP)

• Set on Designated Router (DR) state for each (S,G)

• Also set on the parent (*,G) state if any child (S,G) state entry has the F flag set.


128128

A – Advertised via MSDP

• Shows up on (S,G) entries at the Rendezvous Point (RP)

• Indicates that Register messages are being received, and converted by the RP into MSDP Source Active messages for transmission to peers.


129129

M – MSDP Created Entry

• Shows up on (S,G) entries at the Rendezvous Point (RP)

• Indicates that the (S,G) entry was created when an MSDP Source Active message was received on a group for which there is “group interest”.

• Group Interest: a (*,G) entry exists, created either by local IGMP or PIM (*,G) joins.


130130

X – Proxy-Join Timer

• Shows up on (S,G) entries when a router becomes the “Turnaround Router”

• Deals with situations like “RP On A Stick”• State times out if not refreshed


131131

SSM Revisited


132132

Rationale for SSM• Why go to all the trouble involved in using

RPs (tree-switching, MSDP) when the shared tree to the RP is dropped for the shortest-path tree to the source, as soon as the first packet flows down the shared tree?– The RP is not really forwarding data, just

doing source discovery.– Isn’t there an easier way ?

• This is the rationale for Source-Specific Multicast (SSM).


133133

SSM Makes MSDP Unnecessary

Domain C

Domain B

Domain D

Domain E

Domain A

RP

RP

RP

RP

r

ASM MSDP Peers(irrelevant to SSM) RP

sSource in 232/8

Receiver learns

S AND G out of

band; e.g., from a

Web page


134134

SSM Makes MSDP Unnecessary

Domain C

Domain B

Domain D

Domain E

Domain A

RP

RP

RP

RP

r

ASM MSDP Peers(irrelevant to SSM) RP

sSource in 232/8

Receiver learns

S AND G out of

band; e.g., from a

Web page


135135

Summary: Advantages of SSM

• No shared trees

• No register packets

• No RP mapping required (no RP required!)

• No RP-to-RP source discovery (no MSDP required!)

• No RP means no concentration of traffic towards the RP,

and no single point to attack

• Rogue sources cannot easily spoof traffic

• SSM can use entire multicast address space, but

232/8 is reserved for SSM exclusively


136136

Making the Case for Multicast


137137

What’s Right?Mcast Enabled ISP

Unicast-Only Network

Content Owner

Mcast Enabled Local Provider

Mcast Traffic

Mcast Join


138138

What’s Right?Mcast Enabled ISP


Content Owner


Mcast Traffic

Mcast Join


139139

What’s Wrong?Mcast Enabled ISP


Content Owner


Mcast Traffic

Mcast Join

..tick..tick

..tick..tick

..tick..tickTimeout!Timeout!


140140



Content Owner


Mcast Traffic

Mcast Join

Session Session Description Description File defines File defines mcast timeout, mcast timeout, AND the AND the backup unicast backup unicast transport.transport.

To gain To gain maximum maximum audience size, audience size, unicast fallback unicast fallback streams (ie streams (ie servers) are servers) are deployed.deployed.

Ucast Request


141141



Content Owner


Mcast Traffic

Mcast Join

Ucast Request

Ucast Stream


142142



Content Owner


Mcast Traffic

Mcast Join

Ucast Request

Ucast Stream


143143



Content Owner


Mcast Traffic

Mcast Join

Ucast Request

Ucast Stream

$$$!!!

$$$!!!


144144

What’s Wrong?

• Even multicast-aware content owners must provide unicast streams to gain audience size

• Unicast will never scale– Splitters/Caches just distribute the problem

• Still has a cost-per-user– As receiver bandwidth increases, problem gets

worse– Creates a non-functional business model– Will never bring ~real content to IP

• Must provide a multicast-only solution for content owners, but how?


145145

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


146146

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


147147

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 the cost is not an object, the 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.


148148

Robust Distribution of Data

• In some streaming or data distribution cases, the problem is handling large increases in load.– This is really the case with MacWorld or

Victoria’s Secret type streaming.• Multicast was designed to handle sudden

increases in load.


149149

Enterprise Data Delivery

• Multicast data delivery is a big business now, and will become increasingly important in the future.– The combination of cost-effectiveness, timely

delivery, and robustness is compelling as physical delivery (e.g. FedEx) becomes increasingly supplanted and complemented by Internet data delivery.

– This will move out of financial services into the mainstream.


150150

Case Studies: Enterprise Streaming•Bandwidth is limited on enterprise networks.

•A typical business quality video stream uses 300 Kbps, while a high quality stream might be 1 Mbps.

•On a typical 100BaseT Ethernet, 300 unicast viewers would completely saturate the network.

•100 unicast viewers would saturate a point-to-point DS3 link between corporate campuses; five would saturate a point to point DS1.

•The case for multicast is compelling for corporations with more than a few hundred desktops.


151151

Enterprise Streaming and the ISP

• Most enterprises with more than 100 desktops will have people in remote locations.

• There will generally be no reason to tie up expensive VPN bandwidth for streaming video.

• ISP’s should offer multicast carriage to their customers to allow for cost effective streaming to their remote locations.– RTSP can be used to negotiate bandwidth with

remote sites.


152152

Consumer Streaming

• There is already a sufficient critical mass of multicast enabled consumers to support multicast streaming media delivery.– These will be increasingly aimed at high-

bandwidth broadband consumers.– The robustness afforded by multicasting is

(for live events) almost as important as its cost-effectiveness to the content delivery industry.

• The adoption of MPEG-4, with its interactive capabilities, will accelerate the development of a second generation streaming industry.


153153

The Audience for Consumer Streaming

The Audience for Consumer Streaming

• Total US broadband population currently 10 million connected users with ~1-2 million multicast enabled users.

• Most are college-educated adults ages 18-35. A substantial fraction are college students in their dormitories and offices (at least 1 million).

• This demographic cannot be reached by cable television, and has low satellite TV penetration.

• Potential audience will reach over 100 million people in the next ten years.


154154

Multicast-Only Solution

• Successful business model will bring more content

• Unicast edge networks are only pain-point– Upgrade or die.

• It’s coming...– Many proposals– Many players– Lowest pain-to-deployment may (should)

win


155155

Multicast Myths• “It’s too hard.”

– NOT!– It just hasn’t been a requirement (yet) for many people

• “If it hasn’t caught on yet, it never will.”– It’s unfortunately been an all-or-nothing solution– Multicast needs an mcast-to-ucast transition

technology• Provider – “If multicast catches on, my customers

will stop buying big circuits.”– WRONG!

• Vendor – “If multicast catches on, no one will need big routers and high-speed interfaces.”– WRONG!


156156

How Do ISPs Make Money from Multicast ?

• By offering as a value-added part of their basic service.

• Enterprise customers, in particular, will want and need multicast to extend their internal video and data delivery to remote locations.

• Multicast should also be part of every broadband consumer rollout.– Multicast enabled consumers will have

access to more content.


157157

What are the Costs of Migrating to Multicast ?

• New equipment costs are usually minimal. – If you can run IOS 11 on your Cisco

routers, you can support multicast.– Junipers all support multicast.– There have been issues with Nortel /

Cisco interoperability.– Most switches now support IGMP

snooping. This is necessary for bridged Ethernet networks, which is common in the Enterprise.


158158

Other Costs of Migrating to Multicast

• Peering Costs– Sprint and Verio include multicast peering at no

extra costs, as do a number of ISP’s.• Multicast Peering is available at the LINX in

London, and also in Amsterdam.• All GigaPoPs offer multicast exchanges /

peering.– It can be a problem, though, if none of your

peers support multicast.– On the other hand, offering multicast peering

can attract customers.


159159

Multicast Debugging Costs

• Multicast Debugging– Multicast debugging can be tedious.– Setting it up is easy. But, what if it

doesn’t work ?– Most companies do not provide good

multicast technical support.– You may want to contract for network

assistance.


160160

Mcast Enabled ISP

Content OwnersAccess providers

When the World Deploys Multicast


161161

When the World Deploys Multicast

• A successful multicast business model makes IP profitable for content owners– Success brings MORE content

• Access networks of tomorrow look like provider networks of today– Few large circuits upstream, many small

circuits downstream• Provider revenue model gets flopped

– Few small circuits from content networks, many large circuits down to access networks


162162

Lab 6: Troubleshooting


163163

Information Online

• http://multicast.internet2.edu especially the tutorial-style paper at http://multicast.internet2.edu/almeroth.pdf

• www.ncne.nlanr.net/documentation/faq/mcast_eng_faq.html• http://dast.nlanr.net/Projects/Beacon/• www.multicasttech.com/faq/multicast_faq.html

andwww.multicasttech.com/status/

• Greg Shepherd’s multicast site: www.shepfarm.com/multicast/

• www.cisco.com/warp/public/cc/pd/iosw/tech/ipmu_ov.htm and ftp://ftpeng.cisco.com/ipmulticast.html

• www.sprint.net/multicast/faq.html

Engineering Workshops Internet2 Multicast Workshop Florida International University February 2003.

Documents

Transcript of Engineering Workshops Internet2 Multicast Workshop Florida International University February 2003.