Multicasting Short recap of the basics No single link should - - PowerPoint PPT Presentation

Multicasting

Short recap of the basics

R H H R R R R R H H H No single link should contain multiple copies of same packet. No unwanted packets should be received.

Multicast packets Extra packets with replicated unicast Extra packet with broadcast

Near-term vs Long-term

The Standard IP Multicast Model

1. A source can send multicast packets at any time, with no need to register or to schedule transmission. 2. Based on UDP. 3. Sources need only to know a multicast address and not who is in the group. 4. Sources need not be a part of the group itself. 5. Arbitrary number of sources. 6. Members can join or leave a multicast group at will. 7. No synchronization og registration with a centralized management group. Model does not discuss routing, security, QoS, or address allocation.

MBone

• A virtual network on top of IP
• Connectivity over IP-encapsulated tunnels.
• Reverse-Path Forwarding Tree
• DVMRP

Distance vector multicast routing protocol (DVMRP)

Each node would have its own routing table. Loop avoidance with reverse shortest path tree. Created using flooding and later also pruning. Rooted at the source

(Illustration of a regular DVRP table)

Flooding

Multicast routers Other routers Hosts

Flooding

Flooding

Flooding

Flooding

Flooding

Reverse-Path Forwarding

C Destination interface A

• B

1 C 2 B B A 2 1 4

(Note: This is a simplified routing table.)

Reverse-Path Forwarding

C Destination interface A

• B

1 C 2 B B A 2 1 4

(Note: This is a simplified routing table.)

Reverse-Path Forwarding

C Destination interface A

• B

1 C 4 B B A 2 1 4

(Note: This is a simplified routing table.)

Reverse-Path Forwarding

C Destination interface A

• B

1 C 4 B A 2 1 4 Not the same interface, so it won’t forward the message.

(Note: This is a simplified routing table.)

More Reverse-path forwarding

C B A

More Reverse-path forwarding

C B A

More Reverse-path forwarding

C B A

More Reverse-path forwarding

C B RPF makes sure these links are not used for multicast

• traffic. Done

through prune messages. A

More Reverse-path forwarding

C B RPF makes sure these links are not used for multicast traffic A

More Reverse-path forwarding

C B Sends prune message towards source if all interfaces except source has received prune message A

Reaching the leaf node(s)

C B Checks to see if it knows of any group members in the subnet. A

Reaching the leaf node(s)

C B If any member is a part of the group, the leaf router will forward the packet

• n the subnet.

A

Reaching the leaf node(s)

C B If there are no members in of the group in the subnet it will send back a prune message. A

Pruning

C B It will be forwarded further back towards the source. A

Pruning

C B This router will also send out a prune message as it has no

• ther links than the one

towards source. A

Pruning

C B Receives prune A

Pruning

C B A

Pruning

C B A Each router need to remember which interface is not a part of the tree.

The reverse shortest path tree

C A

Protocol Independent Multicast (PIM)

Uses whatever unicast routing table to perform RPF checks. Sparse mode: PIM-SM Dense mode: PIM-DM

Dense mode

In short:

• We flood the network and branches that has no

members are eliminated.

• Does this regularly to create the reverse-path

forwarding tree.

• This is how is finds new members.

Works best with high density of members. Lots of unnecessary packets if low density

• Works better for low density of members.
• Explicit join messages.
• A single core as a meeting place for sources and receivers.

Rendezvous Point (RP)

• A group can only have a single RP.
• Creates a Rendezvous-point tree
• Protocol Independent Multicast (PIM-SM)

Sparse mode

PIM Multicast trees

B A RP Needs an RP. This will be the root. Note that the RP does not have to be the source.

PIM Multicast trees

B If B wants to join the group it sends a join message towards the RP. A RP

PIM Multicast trees

B Gets forwarded to the RP. A RP

PIM Multicast trees

B A RP But how does it know who is RP?

PIM Multicast trees

B A RP As in DM the routers still needs to remember which interfaces is a part of the tree.

PIM Multicast trees

B A RP This only tells RP that B is a receiver. So what about the sources?

PIM Multicast trees

B A RP Source sends a unicast encapsulated multicast message to the RP.

PIM Multicast trees

B A RP If the RP knows about this group it strips

• ff the unicast

header and forwards the multicast message down the tree

PIM Multicast trees

B A RP If RP doesn’t have forwarding state for the group it sends back a register-stop message.

PIM Multicast trees

B A RP If RP doesn’t have forwarding state for the group it sends back a register-stop message.

PIM Multicast trees

B A RP If RP doesn’t have forwarding state for the group it sends back a register-stop message.

PIM Multicast trees

B A RP If RP doesn’t have forwarding state for the group it sends back a register-stop message.

PIM Multicast trees

B A RP If RP doesn’t have forwarding state for the group it sends back a register-stop message.

In short

Dense mode:

• Best when high density of members
• Broadcast-and-prune protocol
• Source is always root
• More distributed traffic.

Sparse mode:

• Best when low density of members
• Join protocol
• Rendezvous Point (RP)
• Single point of failure and lots of traffic

Native multicast in MBone

Issues with MBone

• Scalability:

Flat networks: Must keep track of state information.

• Manageability:
• No central management. How to manage this?
• Can’t configure better routes.
• Interdomain policy management

Intradomain Multicast

• Emerge due to the need to provide scalable hierarchical, internet-wide

multicast.

• Extension of the interdomain unicast route exchange protocol BGP to make

multicast routing hierarchical.

Multicast with BGP

• Hierarchical
• Supports interdomain routing.
• Simply a matter of choosing the best

External link.

• MBGP
• Something is still missing:
• Doesn’t provide multicast tree construction

functions. What is the format of the join message? When should it be sent?

MSDP

• Uses PIM-SM
• How to inform an RP in one

domain that there are sources In other domains.

• (in practice) One RP per domain
• MSDP works by having

representatives in each domain.

MSDP operations

1. New source. Register with RP. 2. MSDP sends SA til connected peers. 3. Message flooding. 4. Group state-check within each domain. If state exist

• > RP sends PIM join to source

5. If data is contained in the message, the RP will forward it on the multicast tree. 6. Step 3-5 will repeat until all MSDP peers have received the SA message and all group members are receiving data from the source.

Long-term proposals

Border Gateway Multicast Protocol (BGMP)

• Bidirectional shared trees between domains using a single root.
• BGMP needs to decide in which particular domain to root the shared tree.
• Uses a strict address allocation scheme. Each domain should have specific

set of address. Solving dependency problems between domains.

• GLOP and MASC

Example of dependency problems

Root Address Multicast Architecture

A response to the complexity of MBGP/PIM-SM/MSDS and BGMP. The other ones misses security, billing , and management. A need for fundamental changes. Tries to avoid the complexity of core placement: Two primary protocols: Express Multicast and Single Multicast.

Commodity Internet

• Measuring success.
• At the time of publishment studies had only dealt with MBone.
• Bring MBone to the new infrastructure.

Solution: make the MBone its own AS

Internet2 deployment

• Multicast “the right way”
• Internet2 Multicast Working Group has set some ground rules:
• Must be native
• Must be sparse mode
• No tunnels allowed
• All routers must support interdomain multicast routing.

Conclusion

Multicasting: Top, middle, bottom

Multicasting at different layers

Multicasting

➔

Sending the same data to multiple recipients in a group.

Multicasting

➔

Sending the same data to multiple recipients in a group.

At different levels

• Application multicast
• Overlay multicast
• IP multicast

L7: Application L6: Presentation L5: Session L4: Transport L3: Network L2: Link L1: Physical

Metrics used

• Tree quality

○ Multicast tree cost ○ End to end delay

• Control overhead

○ Number of control messages

Application multicast

• Two categories:

○ Unstructured (NARADA) ■ Periodically exchange membership & routing info ■ Build a mesh on E2E measurements ■ Build delivery tree on top, based on distance ○ Structured (NICE) ■ Recursively arrange members into hierarchy

Application multicast

• Pros & cons

○ Unstructured (NARADA) ■ Good for small and sparse groups ■ Does not scale to larger groups, too many control messages ■ Sends and uses a lot of data to build high quality tree ○ Structured (NICE) ■ Efficient logical path, slightly less efficient than NARADA ■ Control messages scale well

Overlay multicast

• Backbone overlay hosts - Proxies
• Users cluster around their closest proxy
• POM - Pure Overlay Multicast

○ Tree managed in backbone, users connect via unicast

• Can be very efficient
• More work than application: Need to set up and

configure the overlay network

IP multicast

• Integrate into internet
• Prerequisite:

○ Agree on single, global protocol for routing ○ Address space

• PIM-SSM

○ Reverse path forwarding ○ Source-Specific Multicast

So, which works best?

Test parameters

• Router topology based on map of approx 300 router

nodes within one ISP

• Group members randomly, uniformly distributed in

network

○ Group size from 5 to 1280

• Source randomly selected within group
• All protocols are source oriented; not core oriented

Application multicast

• NARADA (unstructured)

○ Tree cost is efficient ○ E2E delay consistent, and lower than for NICE, regardless of group size ○ Large amount of control messages required to maintain the tree

• NICE (structured)

○ Sacrifices cost and delay some, for improved scalability ■ Fewer control messages ○ Less control messages (than NARADA) as it scales

Overlay multicast

• Tree cost increases faster than IP multicast

○ Scalability can be improved by using IP multicast for the last leg; from backbone to recipient

• Delay is slightly higher than IP multicast
• Control overhead varies:

○ Application can be better for small groups (<100); Overlay is better for larger groups. ○ IP multicast always beats overlay multicast

Overlay multicast

• Tree cost increases faster than IP multicast

○ Scalability can be improved by using IP multicast for the last leg; from backbone to recipient

• Delay is slightly higher than IP multicast
• Control overhead varies:

○ Application can be better for small groups; Overlay is better for larger groups. ○ IP multicast always beats overlay multicast

IP multicast

• Lowest tree cost, for all group sizes
• E2E delay same as unicast

○ PIM-SSM uses shortest path trees.

• Lowest control overhead overall

Conclusions

• Short term/small group: Application multicast

○ Less effort to set up ○ Pretty efficient with small groups, not with scale

• Larger groups/long term: Overlay multicast

○ More work, but better for medium and large groups ○ More fitting for permanent investment than one off application

• Whenever available: IP based multicast

○ Overall best option; if it is available

Conclusions

Metric IP Overlay Application Ease of deployment Low Medium High Multicast efficiency High Medium Low Control overhead Low Medium High

Based on table table 1 - Comparison of multicast architectures

Bit Indexed Explicit Replication

BIER - RFC 8279

Background

• IP Multicast challenges:

○ Often limited availability ○ Some tree types do not follow unicast paths ○ Need to aggregate more tree state to be optimal ○ Specialized to troubleshoot/maintain

• Only networks with overwhelming business need have

multicast deployed; not available for most services

○ Often internal, in one network/AS

• Can we do better?

Concept

• Consider my topology; not global
• Only encode end-receivers in packets
• Assign end-receivers a bit position in bit string

○ Smallest possible identifier: One bit per receiver ○ Used to indicate who should (and needs) to receive it ○ Encoded in packet headers

• Compile Bit Forwarding Table on all BIER nodes

○ To allow every BIER node to forward based on the bit-string

Example: Forwarding packets

Message for 0111 Message for 0111 Message for 0100 Message for 0011 Message for 0100 Message for 0001 Message for 0010

Scaling: BIER Sets

• Problem: One receiver per bit in bit string - limited
• Solution:

○ Group the list of receivers into sets ○ Bit positions are only unique in the context of the set ○ Packet is replicated - One copy sent to an ingress router/node for each set. ○ It will then be transmitted in the set, as normal

• Bitstring length varies

○ Defined by encapsulation standard ○ RFC 8296 - BIER in MPLS suggests 256 bit.

Scaling: BIER Sets

Advantages

• Follows unicast route towards receiver

○ Inherits unicast efficiency ○ Saves bandwidth by transmitting fewer times, as with normal multicast ○ If overlay: Most efficient path through overlay

• No multicast flow state needed to be kept in the network

Disadvantages

• Bit string has an upper bound, will not cover all scenarios
• Scaling using sets wastes some bandwidth, as the same

packet has to be sent to every ingress router

○ Example: ■ RIPE NCC wants to distribute update to their probes ■ 11107 probes / 256 bit = 44 sets ■ Ignores issues with independent networks

Probe image source: RIPE Atlas - https://atlas.ripe.net/landing/probes-and-anchors/

References

“A Comparative Study of Multicast Protocols: Top, Bottom, or In the Middle?”, Lao, Cui, Gerla, Maggiorini (IEEE, 2005) “Bit Indexed Explicit Replication BIER”, Greg Shepherd (RIPE, 2015) ISO/IEC standard 7498-1:1994 (ISO Model)

Further reading

• The articles themselves
• RFC 8279 - Multicast using BIER
• RFC 8296 - Encapsulation for BIER using MPLS
• Protocol specifications
• L. Lao, J.-H. Cui. M. Gerla. and D. Maggiorim. A

comparative study of multicast protocols: Top, bottom. or in the middle? Technical report, Jan. 2005