Multipoint Communication over IP and ATM

1
Multipoint Communicationover IP and ATM

• Raj Jain The Ohio State UniversityColumbus, OH
  43210Jain_at_cse.ohio-State.Edu
• http//www.cse.ohio-state.edu/jain/cis788-97/Ema
  il questions to mbone_at_netlab.ohio-state.edu

2
Overview

• Why Multipoint?
• Multipoint Routing Algorithms
• Multipoint Communication in IP networks
• Multipoint Communication in ATM Networks

3
Multipoint Communication

• Can be done at any layer
• Application Layer Video Conferencing
• Transport Layer ATM
• Network Layer IP
• Datalink Physical Layers Ethernet

4
Multipoint Applications

• Audiovisual conferencing
• Distance Learning
• Video on Demand
• Tele-metering
• Distributed interactive games
• Data distribution (usenet, stock prices)
• Server synchronization (DNS/Routing updates)
• Advertising and locating servers
• Communicating to unknown/dynamic group

5
Application Layer Multipoint Comm.

• Problems n times more processing/buffering/bandwi
  dth overhead
• Applications need lower layers help in handling
  unknown addresses

6
Multipoint Routing Algorithms

• Flooding
• Spanning Trees
• Reverse Path Forwarding
• Flood and Prune
• Steiner Trees
• Center-Based Trees, e.g., core-based trees
• Most routing protocol standards are combination
  of these algorithms.

7
Flooding

• Used in usenet news
• Forward if first reception of this packet ? Need
  to maintain a list of recently seen packets
• Sometimes the message has a trace of recent path

8
Spanning Tree
1
2
E
E
A
C
A
C
3
4
6
5
B
D
B
D

• Used by MAC bridges
• Packet is forwarded on all branches of the tree
  except the one it came on
• Problem All packets from all sources follow the
  same path ? Congestion

9
Reverse Path Forwarding
1
2
1
2
E
E
A
C
A
C
3
4
3
4
6
5
6
5
B
D
B
D

• Also known as reverse path broadcasting (RPB)
• Used initially in MBone
• On receipt, note source S and interface I
• If I belongs to shortest path towards S,
  forward to all interfaces except I
• Otherwise drop the packet

10
RPF (Cont)
1
2
A
C
E
3
4
6
5
B
D

• Optionally, check and forward only if the node is
  on the shortest path to the next node
• Implicit spanning tree. Different tree for
  different sources.
• Problem Packets flooded to entire network

11
Flood and Prune
2
2
E
E
Prune
Graft
5
5
No listeners at E
Listeners at E

• Also known as reverse path multicasting (RPM)
• Used in MBone since September 1993
• First packet is flooded
• All leaf routers will receive the first packet

12

• If no group member on the subnet, the router
  sends a "prune"
• If all branches pruned, the intermediate router
  sends a "prune"
• Periodically, source floods a packet
• Problem Per group and per source state

13
Steiner Trees

• Centralized algorithm to compute global optimal
  spanning tree given all listeners
• Applies only if links are symmetric
• NP Complete ? Exponential complexity ? Not
  implemented
• Tree varies with the membership ? Unstable

14
Center-Based Trees
1
2
A
C
E
3
4
6
5
B
D

• Aimed at multiple senders, multiple recipients
• Core-based tree (CBT) is the most popular example
• Choose a center
• Receivers send join messages to the center
  (routers remember the input interface)
• Senders send packets towards the center until
  they reach any router on the tree

15
CBT (Cont)

• Possible to have multiple centers for fault
  tolerance
• Routers need to remember one interface per group
  (not per source) ? More scalable than RPF
• Problem Suboptimal for some sources and some
  receivers

16
Multipoint Routing Protocols

• Reverse Path Forwarding (RPF)
• Distance-vector multicast routing protocol
  (DVMRP) Flood and prune
• Multicast extensions to Open Shortest-Path First
  Protocol (MOSPF) Source-based trees (RPF)
• Protocol-Independent Multicast - Dense mode
  (PIM-DM) Flood and prune
• Protocol-Independent Multicast - Sparse mode
  (PIM-SM) Core-based trees

17
IP Multicast Design Principles

• Single address per group
• Members located anywhere
• Members can join and leave at will
• Senders need not be aware of membershipsLike a
  TV channel ? Scalable
• Sender need not be a member
• Soft connections ? periodic renewal

18
IP vs ATM

• UNI 4.0 adds leaf initiated join.

19
Multiway Communication on ATM

• ATM Forum Multiway BOF formed in June 1996 after
  marketing studies indicated high user interest
• ITU Study group 13 on ATM based multiway
  communications technologies
• ITU Study group 11 on Signaling requirements for
  Capability Set 3 (Multimedia) specifies 4 types
  of multipoint connections.

20
Multiway on ATM (Cont)

• Type 1 point-to-point
• Type 2 Point-to-multipoint
• Unidirectional
• Bi-directional with nonzero return bandwidth
• Type 3 Multipoint-to-point
• Type 4 Multipoint-to-Multipoint
• Variegated VCs ? Receivers with different
  bandwidthApplications Video distribution, stock
  market

21
Key Issues
0
0
0
0
0
0
0
1
1
1
0
0
0
1
EOF

• Routing and packet multiplexing
• Packet multiplexing not allowed in AAL5
• AAL 3/4 has a 10-bit multiplexing ID in each cell
  payload ? 1024 packets can be intermixed

22
ATM Multiway Methods

• 1. LAN Emulation ? Broadcast and Unknown Server
  (BUS)
• 2. MPOA ? Multicast Address Resolution Server
  (MARS)
• 3. VC Mesh Overlaid pt-mpt Connections
• 4. Multicast Server (MCS)
• 5. SEAM
• 6. SMART
• 7. VP Multicasting
• 8. Subchannel multicasting

23
IP Multicast over ATM

• Need to resolve IP multicast address to ATM
  address list ? Multicast Address Resolution
  Servers (MARS)
• Multicast group members send IGMP join/leave
  messages to MARS
• Hosts wishing to send a multicast send a
  resolution request to MARS

24
Overlaid pt-mpt Connections

• Also known as VC Mesh
• Each sender in the group establishes a pt-mpt
  connection with all members
• Problem VC explosion, new members should be
  advertised and joined

25
Multicast Server (MCS)

• All hosts send to MCSMCS has a single mpt VC to
  all members
• MCS serializes the packets ? Does not intermingle
  cells of packets from different incoming VCs
• Problems with MCS
• Reflected packets
• Single point of congestion
• Better for dynamic set of receivers

26
VC Merge

• Allows multipoint to point flow
• All cells of one source are switched until the
  last cell of the packet
• Cells from other sources on the same VC wait

27
SEAM

• Scalable and Efficient ATM Multipoint-to-multipoin
  t Communication
• Uses core-based tree
• At merging points, switches have to store all
  cells of a packet (reassembly is not required) ?
  Packet switching ?Authors call it "cut through")
• Ref M. Grossglauser and K.K. Ramakrishnan, ATM
  Forum/96-1142, August 1996.

28
SMART

• Shared Many-to-many ATM Reservations
• Needs only one VCC but allows using multiple
  VCCs for performance and reliability
• Limits to one transmitter at a time. Token
  holder (root) can transmit.
• Anyone wishing to transmit data, must request the
  token from current root and become new root.
• Ensures that there only one transmitter in the
  tree ? No cell interleaving
• Ref E. Gauthier, et al, IEEE JSAC, April 1997

29
SMART (Cont)

• Data blocks delineated by RM cells
• Not scalable for very large ATM networks or for
  small interactions

30
VP Multicasting

• A single VP is setup connecting all nodes
• Each source is given a unique VCI within the VP
• Problem Size limited
• VPs are used by carriers for other purposes

31
Subchannel Multicasting

• Used in Washington University's Giga Switch
• Use GFC to provide 15 subchannels for each VC
  (FF indicates idle subchannel)
• Each burst is preceded and followed by "Start"
  and "End" RM cells.
• Subchannel is allocated on the first RM cell and
  released on the last.
• Subchannel IDs are changed at every switch (just
  like VC IDs)

32

• Allows multiplexing up to 15 simultaneous
  packets at each switch port per VC.
• If a Start RM cell is received and no subchannel
  is available, the burst is lost.
• Jon Turner claims the loss probability is less
  than 10-12

33
Summary

• Multipoint communication is required for many
  applications and network operations
• Network and transport support
• Internet community has developed and experimented
  with many solutions for multipoint communication
• ATM solutions are being developed

34
Key References

• See http//www.cse.ohio-state.edu/jain/refs/mul_
  refs.htm for further references.
• C. Huitema, "Routing in the Internet,"
  Prentice-Hall, 1995
• T. Maufer and C. Semeria, "Introduction to IP
  Multicast Routing," March 1997,
  http//www.internic.net/internet-drafts/draft-ietf
  -mboned-intro-multicast-02.txt

35
References (Cont)

• S. Fahmy, et al, "Protocols and Open Issues in
  ATM Multipoint Communications,"
  http//www.cse.ohio-state.edu/jain/papers/mcast.h
  tm
• C. Diot, et al, "Multipoint Communication A
  Survey of Protocols, Functions, and Mechanisms,"
  IEEE JSAC, April 1997, pp. 277-290.

36
Thank You!
37
Multipoint vs Multicast

• Multipoint not point-to-point
• Multicast Subset of broadcast Broadcast
  limited to a group Media property Phy and
  datalink layer issues
• Ethernet Phy is broadcast. Datalink limits that
  to multicast.
• ATM networks Phy is unicast. Datalink has to
  extend that.
• Multipoint communication is easy iff Phy is
  multicast
• Anycast 1-to-n (forward) 1-1 (reverse)

38
IP Multicast Implementations

• Sun - Solaris 2.x
• SGI - Irix
• x86 - Windows 95, NT, FTP Software, BSDI, NetBSD,
  FreeBSD, Linux
• Mac - Open Transport
• Routers - 3com, Bay, Cisco, Proteon, Alantec
• Patches Supplied
• Sun - SunOS 4.x DEC - Ultrix
• HP - HP-UX IBM - AIX

39
IGMP

• Internet Group Management Protocol
• Used by hosts to report multicast membership
• Join-IP-Multicast Group (address, interface)
• Leave-IP-Multicast Group (address, interface)
• Ref RFC 1112 (Version 1)

Routers
Hosts
40
IGMP Operation

• One "Querier" router per link
• Every 60-90 seconds, querier broadcasts "query"
  to all-systems (224.0.0.1) with TTL 1
• After a random delay of 0-10 seconds, hosts
  respond for each multicast group
• Everyone hears responses and stops the delay
  timer ? One response per group
• Non-responding groups are timed-out
• New hosts send a "membership report" immediately
  without waiting for query

41
IGMP Version 2

• Querier election method
• Messages include "maximum response time"
• "Leave group" message to reduce leave
  latencySent only if the host that responded to
  the last query leaves
• Querier then issues a "membership query" with a
  short response time
• Already implemented. RFC soon.
• Ref http//www.internic.net/internet-drafts/draft
  -ietf-idmr-igmp-v2-06.txt

42
IGMP Version 3

• Allows hosts to listen to
• A specified set of hosts sending to a group
• All but a specified set of hosts sending to a
  group
• Allows informing the source if no one is
  listening
• Being designed.

43
Reverse Path Forwarding (RPF)

• Originally due to Dalal and MetcalfeModified by
  Steve Deering for IP Multicasting
• Send multicast packets received on SPF interface
  from the source to all other interfaces
• Pruning Forward on an interface only if there is
  a group member downstream ? Routers need to
  remember whether any listeners for all groups and
  all interfaces ? May be excessive overhead for
  large number of groups

44
DVMRP

• Distance Vector Multicast Routing Protocol
• Multicast extension of RIP
• Broadcast and prune approach
• Periodically, packets are broadcast to all
  routers
• Routers with no downstream members send prune
  messages
• Later routers may send graft messages to add
  members
• Broadcast and prune ? OK for dense group. High
  overhead for a sparse group.

45
DVMRP (Cont)
P
G
P
G
(b) Truncated Broadcast
(a) Initial Topology
(c) Pruning
(d) Grafting
46
Hierarchical DVMRP

• Two level hierarchy Regions and inter-regions
• Boundary routers run DVMRP
• Internal routers run any multicast protocols

47
MOSPF

• Multicast Open Shortest Path First (Link state)
• Routers build source-based trees
• Tree is pruned based on the group membership
• Packets forwarded only on the interfaces in the
  pruned tree
• Group membership advertised by a link state
  record
• Heavy computation ? Computation done only if a
  packet is received
• Expensive for a large number of groups and large
  number of sources

48
PIM

• Protocol Independent Multicast
• Unicast routes are imported from existing tables
  ? Use RIP or OSPF tables ? Protocol Independent
• Two modes Dense and Sparse
• PIM-DM is similar to DVMRP. Uses broadcast and
  prune.
• PIM-SM is similar to core-based tree. Uses a
  rendezvous point (RP)

49
PIM-SM (Cont)

• RP Tree Reverse shortest path tree rooted at RP
• Routers with listeners join towards RP
• Routers with sources send encapsulated packets to
  RP
• Routers with listeners and RP may initiate
  switching to source-specific SPT

50

• To find RP, routers hash group address to the
  small set of known RPs in the region.
• Keeps multicast host simple.
• Similar to core-based tree except that PIM-SM
  allows switching to a source-based tree
• Refs http//www.internic.net/internet-drafts/draf
  t-ietf-idmr-pim-arch-04.txt,
• http//www.internic.net/internet-drafts/draft-ietf
  -idmr-pim-sm-spec-09.txt,
• http//www.internic.net/internet-drafts/draft-ietf
  -idmr-pim-dm-spec-04.txt

51
Multicasting Transport Protocols

• Scalable Reliable Multicast (SRM)
• Reliable Multicast Transport Protocol (RMTP) by
  Shiroshita, et al
• Reliable Multicast Transport Protocol (RMTP) by
  S. Paul, et al

52
SRM

• Scalable Reliable Multicast
• Reliable ? All receivers receive all data sent
  to a multicast group from different sources.
• No ordering across different sources.
• Problem Unicast reliability algorithms (timeout
  and retransmission) depend upon RTT and cannot be
  used for dynamic multicast trees

53
SRM Design Principles

• Application level framing ? Applications
  responsible for reliability (not transport).
• Each receiver responsible to ensure that it has
  all data.
• Group members send quasi-periodic session
  messages to report their current state.
• Receivers detect errors and request repair
• Any node with the data can reply

54

• All requests and replies are multicast
• Wait random time to minimize duplicate
  request/responses
• Recovery overhead can be reduced by limiting the
  scope of request and repair multicasts.

55
SRM Example
R5
D
R1
A
R3
R4
C
R2
B

• A sends two packets
• One of the packets is lost
• D sends a request for the lost packet
• C retransmits the lost packet

56
RMTP

• Reliable Multicast Transport Protocol
• Runs over UDP over IP Multicast
• Receivers send nacks to indicate missing packets
• Source retransmits missing packets via either
  multicast or unicast (depending upon the number
  of Nacks)
• Ref Shiroshita, et al, http//www.internic.net/in
  ternet-drafts/draft-shiroshita-rmtp-spec-00.txt

57
RMTP

• Reliable Multicast Transport Protocol
• Hierarchical division of network into regions
• Each region has a "designated receiver" (DR)
• A distribution tree containing all nodes is
  created by network layer.

R2,2
R2,1
R3,1
S SenderLi Local access switch for ith
regionRi,j jth receiver of ith regionAN
Access node
L2
AN
R3,2
S
BackboneNetwork
L3
L1
R3,3
R1,2
58

• DRs send periodic status to source. Includes
  requests for retransmission.
• Sources retransmit only to DRs.
• Other receivers send periodic status to their DR.
  DRs retransmit in the region.
• Ref S. Paul, et al, IEEE JSAC, April 1997

59
SMART (Cont)

• Arrows ? Data can flow in that direction
• Solid arrow ? That end has bias. ? Will reject
  a grant if it has also sent a grant.
• Bias is prenegotiated. Arbitrarily.
• Solid lines ? Requests/grants on the wire
• Dotted lines ? Request/grants accepted

60
SMART (Cont)
(a) A1, A2, B1, B2 send grantsAll grants are
accepted
(b) X, Y send grants to each other
B1
A1
B1
A1
Grant
Grant
Grant
.
Grant
Grant
Y
X
Y
X
Grant
Grant
Grant
Grant
Grant
B2
A2
B2
A2
B1
A1
B1
A1
Grant
Request
Grant
Grant
Y
X
Y
X
Grant
Grant
Grant
Grant
Grant
Grant
B2
A2
B2
A2
(c) X accepts, Y rejects. X is root
(d) A1 wants to send data
61
SMART (Cont)
(e) X accepts request, sendsgrant to A1.
(f) A1 accepts grant. Sends data.
B1
A1
B1
A1
Req.
Grant
Grant
Grant
Grant
Y
X
Y
X
Grant
Grant
Grant
Grant
Grant
Grant
B2
A2
B2
A2
B1
A1
B1
A1
Grant
Grant
Grant
Req
Req
Req
Req
Y
X
Y
X
Req
Req
B2
A2
B2
A2
(g) B1 issues a req. Propagates to A1
(h) A1 accepts req, sends grant.