multi cast summary pp t 1469
TRANSCRIPT
-
8/12/2019 Multi Cast Summary Pp t 1469
1/61
Summary of IP Multicast
CPSC 601.43Course Director: Dr. AnirbanMahanti
Student : Liqi Shi
-
8/12/2019 Multi Cast Summary Pp t 1469
2/61
Outline
1. Introduction to Multicast
2. Multicast Group and Service Model3. Multicast Routing
4. Deployment Issues of Multicast
5. EXPRESS6. References
-
8/12/2019 Multi Cast Summary Pp t 1469
3/61
1 Introduction to Multicast
1.1 Why Multicast /Multicast Applications
1.2 Broadcast/Unicast/Multicast
-
8/12/2019 Multi Cast Summary Pp t 1469
4/61
1.1 Why Multicast /Multicast
Applications
Same data sent to multiple receivers
To use the bandwidth efficiently Reduce routing processing
Sender doesnt get receivers address
-
8/12/2019 Multi Cast Summary Pp t 1469
5/61
1.1 Why Multicast /Multicast
Applications
Video/audio conference
IP TV, Video on Demand Advertisement, Stock, Distance learning
Synchronizing of distributed database,
websites
-
8/12/2019 Multi Cast Summary Pp t 1469
6/61
1.1 Why Multicast /Multicast
Applications
ConferenceXP: An Example of Multicast
applicationVideo Conference Distance Learning
-
8/12/2019 Multi Cast Summary Pp t 1469
7/61
1.2 Broadcast/Unicast/Multicast
Broadcast: One sender, all the others as
receivers Unicast: One sender and one receiver
Multicast: One sender (potentially many
senders), many receivers
You can take broadcast and unicast as two
special types of multicast
-
8/12/2019 Multi Cast Summary Pp t 1469
8/61
1.2 Broadcast/Unicast/Multicast
UNICAST
With 4 receivers,
sender must
replicate the
stream 4times
-
8/12/2019 Multi Cast Summary Pp t 1469
9/61
1.2 Broadcast/Unicast/Multicast
MULTICAST Source transmits
one stream of data
for n receivers
Replication
happens inside
routers and
switches
WAN links only
need one copy of
the data, not n
copies.
-
8/12/2019 Multi Cast Summary Pp t 1469
10/61
2 Multicast Group and Service Model
Each multicast group is identified by a class D IPaddress
Members of the group could be anywhere in theInternet
Members can join and leave the group and indicatethis to the routers
Senders and receivers are distinct: i.e., a senderneed not be a member, but receivers should be
Routers listen to all multicast addresses and usemulticast routing protocols to manage groups (IGMP)
-
8/12/2019 Multi Cast Summary Pp t 1469
11/61
2 Multicast Group and Service Model
Multicast Address IP reserved class D addresses for multicast
224.0.0.0~239.255.255.255
Base address: 224.0.0.0 is reserved 224.0.0.1~224.0.0.255 are devoted to multicast routing
and group maintenance protocols
Multicast addresses can only be used as destination
No ICMP error messages can be generated for multicastdatagram
-
8/12/2019 Multi Cast Summary Pp t 1469
12/61
2 Multicast Group and Service Model
Mapping IP Multicast to Ethernet Multicast: Place the lower
23 bits of the IP multicast address into the lower 23 bits of
special Ethernet multicast address 01.00.5E.00.00.00. 32
multicast groups may be mapped into the same address.
Probability is small, but receivers should check the datagram
-
8/12/2019 Multi Cast Summary Pp t 1469
13/61
3 Multicast Routing
3.1 Transmission and Delivery of Multicast Datagram
3.2 Internet Group Management Protocol (IGMP)
3.3 Multicast Forwarding Algorithms Flooding
Spanning Trees
Reverse Path Broadcasting (RPB)
Truncated Reverse Path Broadcasting (TRPB)
Reverse Path Multicasting (RPM)
Core Based Trees (CBT)
3.4 Multicast Protocols Distance Vector Multicast Routing Protocol (DVMRP) Multicast OSPF (MOSPF)
Protocol-Independent Multicast (PIM)
BGMP and MASC
-
8/12/2019 Multi Cast Summary Pp t 1469
14/61
3.1 Transmission and Delivery of Multicast
Datagram
Local subnetwork transmissionThe source station simply addresses the IP packet to the multicast group, the
network interface card maps the Class D address to the correspondingEthernet multicast address, and the frame is sent. Receivers that wish to
capture the frame notify their IP layer that they want to receive datagrams
addressed to the group
Transmission throughout the Internet
Routers are required to implement a multicast routing protocol that permits theconstruction of multicast delivery trees and supports multicast data packet
forwarding. In addition, each router needs to implement a group membership
protocol (IGMP) that allows it to learn about the existence of group members on
its directly attached subnetwork
-
8/12/2019 Multi Cast Summary Pp t 1469
15/61
3.2 Internet Group Management
Protocol (IGMP)
Introduction
IGMP runs between hosts and the
nearest multicast routers. A localhost can use it to inform the routerwhich multicast group it wants to beadded in, while the multicast routerscan use it to poll the LANperiodically, thus determine ifknown group members are still
active IGMP message format
Type 0x11 0x11 0x16 0x17 0x12
Group
Addre
ss
unuse
d
used used used used
Meani
ng
Gener
al
memb
ership
query
Specifi
c
memb
ership
query
Memb
ership
report
Leave
group
Memb
ership
report
(V1)
0 8 16 32
-
8/12/2019 Multi Cast Summary Pp t 1469
16/61
3.2 Internet Group Management
Protocol (IGMP)
IGMP versions RFC1112, IGMP version 1
, IGMP version2 defines a procedure for the election of the multicast querier for each
LAN
defines a new type of Query message-the Group-Specific Querymessage
defines a Leave Group message
, IGMP version 3 introduces support for Group-Source Report messages so that a host
can elect to receive traffic from specific sources of a multicast group
support for Leave Group messages first introduced in IGMP Version 2has been enhanced to support Group-Source Leave messages. Thisfeature allows a host to leave an entire group or to specify the specificIP address(es) of the (source, group) pair(s) that it wishes to leave
-
8/12/2019 Multi Cast Summary Pp t 1469
17/61
3.2 Internet Group Management
Protocol (IGMP)
How it works
One host joins a group
Newly joined host in a group sends IGMP message to group multicastaddress declaring membership.
Local multicast router receives the message and establishesnecessary routing path
Group membership report
Router sends Host Membership Query to 224.0.0.1 (all multicast hostson a subnet)
Host responds with Host Membership reportfor each group to which itbelongs (sent to group address)
other hosts in the same group suppress reports
Router periodically broadcasts query to detect if groups have goneaway
-
8/12/2019 Multi Cast Summary Pp t 1469
18/61
3.2 Internet Group Management
Protocol (IGMP) Each hostresponds to the
query with a
random delay. If
one report is
received at the
router, the otherreports will be
suppressed
-
8/12/2019 Multi Cast Summary Pp t 1469
19/61
3.3 Multicast Forwarding Algorithms
Introduction: IGMP is responsible for delivering packets from alocal router to directly attached subnetwork. To forwardingmulticast packets across internet, we should use multicastprotocols. Several algorithms may be used by the protocols.
3.3.1 Flooding
3.3.2 Spanning Trees
3.3.3 Reverse Path Broadcasting (RPB)
3.3.4 Truncated Reverse Path Broadcasting (TRPB)
3.3.5 Reverse Path Multicasting (RPM)
3.3.6 Core Based Trees (CBT)
-
8/12/2019 Multi Cast Summary Pp t 1469
20/61
3.3.1 Flooding
When a router receives a packet, the router will determinewhether its the first time it receives the packet. If so, the packet
will be delivered to all interfaces except the one on which itarrived, otherwise the packet will be discarded.
No routing tables needed
Inefficient use of bandwidth
SRC Non-red streams will be
discarded according to
flooding algorithm
-
8/12/2019 Multi Cast Summary Pp t 1469
21/61
3.3.2 Spanning Tree
Only one active path connects any two of routers
The multicast packets will not loop and reach all routers
May not provide the most efficient path between the sourcesubnetwork and group members
-
8/12/2019 Multi Cast Summary Pp t 1469
22/61
3.3.3 Reverse Path Broadcasting (RPB)
A local router only acceptspackets from the nearestsource (parent), otherwise the
packets are discarded Accepted packets will be
forwarded to all interfacesexcept the source
it does not take into accountmulticast group membership
when building the distributiontree, so packets may beforwarded to non-membershipsubnetwork
-
8/12/2019 Multi Cast Summary Pp t 1469
23/61
3.3.4 Truncated Reverse Path
Broadcasting (TRPB)
Its an enhancement of RPB
With the help of IGMP,
multicast routers determine thegroup membership on each leaf
subnetwork, thus avoiding
forwarding packets to non-
members
Eliminates unnecessary traffic
on leaf subnetworks , but doesnot consider group
memberships when building the
branches of the distribution tree
Source,
G1
G1
G2
G3
Truncated
-
8/12/2019 Multi Cast Summary Pp t 1469
24/61
3.3.5 Reverse Path Multicasting (RPM)
RPM creates a delivery tree that spans only
Subnetworks with group members, and
Routers along the shortest path to subnetworks with groupmembers
First packet will be sent to all interfaces except the source. Ifnone of the subnetworks connected to the leaf router havegroup members, the leaf router may transmit a "prune"message on its parent link informing the upstream router not toforward packets in this group to the leaf
In RPM, first packet still needs to be forwarded throughout thenetwork.
Each router has to maintain state information for all groups. Itwill be impossible as the number of groups and sourcesincreases.
-
8/12/2019 Multi Cast Summary Pp t 1469
25/61
3.3.5 Reverse Path Multicasting (RPM)
Source,
G
G
G
First packet of G
G Member subnetwork
Non-member
subnetwork
Prune message
-
8/12/2019 Multi Cast Summary Pp t 1469
26/61
3.3.6 Core Based Trees (CBT)
There is a backbone for CBT. It includes both
core and non-core routers.
-
8/12/2019 Multi Cast Summary Pp t 1469
27/61
3.3.6 Core Based Trees (CBT)
If a host wants to join one group, it has to send a unicast joinrequest message to the core. The nearest router in thebackbone will respond with ACK and the intermediate routerswill record the routing information, thus a delivery tree for agroup is established
Compared to previous algorithms, CBT can use bandwidth androuter resources more efficiently
CBT may result in traffic concentration and bottlenecks near
core routers since traffic from all sources traverses the sameset of links as it approaches the core
A single shared tree may create trees not as optimal as source-trees
-
8/12/2019 Multi Cast Summary Pp t 1469
28/61
3.4 Multicast Protocols
3.4.1 Distance Vector Multicast Routing Protocol(DVMRP)
3.4.2 Multicast OSPF (MOSPF)
3.4.3 Protocol-Independent Multicast (PIM)
3.4.4 BGMP and MASC
-
8/12/2019 Multi Cast Summary Pp t 1469
29/61
3.4.1 Distance Vector Multicast Routing
Protocol (DVMRP)
Source-based trees, data-driven (broadcast-and-prune), implicitjoin, dense mode protocol
RPM algorithm Derived from Routing Information Protocol (RIP)
RIP forwards the unicast packets based on the next-hop towards adestination
DVMRP constructs delivery trees based on shortest previous-hopback to the source
DVMRP forwarding table: built from DVMRPs own routing table,received prune messages
TTL and admin scoping available; physical or tunnel interfacespossible
-
8/12/2019 Multi Cast Summary Pp t 1469
30/61
3.4.1 Distance Vector Multicast Routing
Protocol (DVMRP)
If router C can receive datagrams from both A and B, then itwill receive from A if As metric to the source is smaller than
Bs or if they are equal, A has the smaller IP address on its
downstream interface
-
8/12/2019 Multi Cast Summary Pp t 1469
31/61
3.4.1 Distance Vector Multicast Routing
Protocol (DVMRP)
Separate processes (and updates) for unicast and multicast
routing Limitations:
distance-vector => slow to adapt to topology changes;
Must store source-specific sate even when not on tree => scalingproblems
B A
Source
-
8/12/2019 Multi Cast Summary Pp t 1469
32/61
3.4.2 Multicast OSPF (MOSPF)
OSPF provides each router with the topology of theInternet or its OSPF area
MOSPF uses OSPFs topology database to calculateforwarding tree.
Broadcasting data for a group is demand-driven, thatmeans it happens only when a host joins or leaves agroup. Compared to data-driven protocols, the costis that routing information should be propagated,because all routers in an area must maintainmembership about every group
-
8/12/2019 Multi Cast Summary Pp t 1469
33/61
3.4.3 Protocol-Independent Multicast
(PIM)
PIM has two variants: Dense mode (DM) and sparsemode (SM) DM builds source-based trees in a data-driven (broadcast-and-
prune), implicit join manner
SM allows shared tree and uses explicit join.
PIM-DM it employs the Reverse Path Multicasting (RPM) algorithm
PIM-DM relies on the presence of an existing unicast routingprotocol to adapt to topology changes, but it is independent of themechanisms of the specific unicast routing protocol, while DVMRPhas its own routing table
PIM-DM simply forwards multicast traffic on all downstreaminterfaces until explicit prune messages are received
-
8/12/2019 Multi Cast Summary Pp t 1469
34/61
3.4.3 Protocol-Independent Multicast
(PIM)
PIM-SM
Routers with directly attached or downstream members arerequired to join a sparse-mode distribution tree bytransmitting explicit join messages
PIM-SM is similar to the Core-Based Tree (CBT) approach inthat it employs the concept of a rendezvous point (RP)where receivers "meet" sources
Join a PIM-SM
distributiontree
-
8/12/2019 Multi Cast Summary Pp t 1469
35/61
3.4.3 Protocol-Independent Multicast
(PIM)
PIM-SM (cont.) When a host first transmits a multicast packet to a group, its
DR encapsulates the multicast packet in a PIM-SM-Register
packet and unicasts it to the primary RP. The RP respondsPIM-Join message. All routers between source and RPmaintain the route so that subsequent unencapsulatedmulticast packets could be forwarded to the RP
-
8/12/2019 Multi Cast Summary Pp t 1469
36/61
3.4.3 Protocol-Independent Multicast
(PIM)
PIM-SM (cont.)
PIM-SM allows receivers to either continue to receive
multicast traffic over the RP-shared tree or over a source-rooted shortest-path tree that a receiver subsequently creates.
The shortest-path tree allows a group member to reduce the
delay between itself and a particular source
-
8/12/2019 Multi Cast Summary Pp t 1469
37/61
3.4.4 BGMP and MASC
BGMP (Border Gateway Multicast Protocol )
BGMP builds shared tree of domains for a group
So we can use a rendezvous mechanism at the domain levelShared tree is bidirectional
Root of shared tree of domains is at root domain
Runs in routers that border a multicast routing domain
Runs over TCP
Joins and prunes travel across domains Can build unidirectional source trees
-
8/12/2019 Multi Cast Summary Pp t 1469
38/61
3.4.4 BGMP and MASC
unidirectional
source
tree
-
8/12/2019 Multi Cast Summary Pp t 1469
39/61
3.4.4 BGMP and MASC
MASC (Multicast Address Set Claim )
Group prefixes are temporarily leased to domains
Allocated by ISP who in turn received them from itsupstream provider
Claims for group allocation resolve collisions
Group allocations are advertised across domains
Group prefix allocations are not assigned to domainstheyare leased
Applications must know that group addresses may go away
RFC 2909
-
8/12/2019 Multi Cast Summary Pp t 1469
40/61
3.4.4 BGMP and MASC
-
8/12/2019 Multi Cast Summary Pp t 1469
41/61
4 Deployment Issues of Multicast
Current architecture deters the commercial deployment ofmulticast.
Router mitigation: Older hardware doesnt support multicast. If
software upgrade is not applicable, the routers are forced intoearly retirement
Domain independent: For sparse mode multicast, its better to useCBT or PIM-SM. However, many problems are present whenRPs/core and sources are in different domains Traffic sources in other domains may require traffic controls, such as
rate or congestion control
ISP has little control over receivers who receive messages from anRP in another domain
ISP refuses to be a core if it has no receives or sources
Advertisement of the addresses of the RP/core is not very easy
-
8/12/2019 Multi Cast Summary Pp t 1469
42/61
4 Deployment Issues of Multicast
Current architecture deters the commercialdeployment of multicast (cont.) Group management: Current service model does
not consider group management, includingreceiver/transmitter authorization, group creation,billing, etc. Dangers: Flooding attack
Collision of sessions
Unauthorized reception
Changing the content of a session
-
8/12/2019 Multi Cast Summary Pp t 1469
43/61
4 Deployment Issues of Multicast Current architecture deters the commercial deployment of multicast (cont.)
Multicast security:
Authentication, authorization, encryption and data integrity
Current IP multicast service and architecture do not mandate any authentication
Encryption is appropriate mechanism to preserve data privacy at application level Secure Multicast services are network level solutions to ensure that multicast tree
construction and delivery services are restricted to authenticated and authorized hosts(i.e. KHIP)
MSEC - Multicast Security (MSEC@IETF)
Drafts:
The Group Domain of Interpretation (draft-ietf-msec-gdoi-06.txt)
Group Key Management Architecture (draft-ietf-msec-gkmarch-03.txt)
GSAKMP Light (draft-ietf-msec-gsakmp-light-sec-01.txt) MIKEY: Multimedia Internet KEYing (draft-ietf-msec-mikey-04.txt)
HMAC-authenticated Diffie-Hellman for MIKEY (draft-ietf-msec-mikey-dhhmac-00.txt)
RFCs:
http://www.ietf.org/html.charters/msec-charter.htmlhttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-dhhmac-00.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-mikey-04.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gsakmp-light-sec-01.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gkmarch-03.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.nleymann.de/ip-multicast/ietf/draft-ietf-msec-gdoi-06.txthttp://www.ietf.org/html.charters/msec-charter.html -
8/12/2019 Multi Cast Summary Pp t 1469
44/61
4 Deployment Issues of Multicast
Current architecture deters the commercial deployment of multicast(cont.) Address allocation: When multicast service is popular, address allocation
will be a big problem. Currently there are four alternatives for addressallocation. MAAA: It is very complicated, consisting of three protocols which connect hosts,
domains, address allocation servers. The allocation of addresses betweendomains is handled by Multicast Address Set Claim (MASC). Multicast AddressDynamic Client Allocation Protocol (MADCAP) is used by host to requestaddress from server. The servers inform each other of claimed address blocks byAddress Allocation Protocol (AAP). However, MAAA never considers whetheraddress resource is enough
Static allocation and assignment (GLOP): Restrict addresses available todomains by AS numbers
EXPRESS model: Uses per source and channel (S,E) structure, so each sourcecan have 16 million channels
IPv6 addressing: IPv6 provides sufficient addresses
-
8/12/2019 Multi Cast Summary Pp t 1469
45/61
4 Deployment Issues of Multicast
Some alternate service models
EXPRESS
Application level multicast: Application level
multicast has the potential to address most
problems associated with IP multicast, since its
based on unicast. However, Application level
multicast can not perform as well as IP multicast.The reason is that some redundant traffic on
physical links is unavoidable
-
8/12/2019 Multi Cast Summary Pp t 1469
46/61
5 EXPRESS (Explicitly Requested
Single Source Multicast)
5.1 EXPRESS channel model and
advantages
5.2 EXPRESS count management protocol
(ECMP)
5.3 Multi-source applications
5.4 Cost of EXPRESS and conclusion
-
8/12/2019 Multi Cast Summary Pp t 1469
47/61
5.1 EXPRESS channel model and
advantages
1. Channel Model The channel model is identified by (S,E), where S is the
single source and E is a channel destination address
Only source S can send datagrams to (S,E)
If a subscriber host wants to receive data from S, it shouldexplicitly specify both S and E in its request
Compared to group model, (S,E) and (S,E) are unrelated.That means a subscriber to (S,E) wont receive data from(S,E)
Class D address (232.*.*.*) are assigned for experimentaluse by EXPRESS
-
8/12/2019 Multi Cast Summary Pp t 1469
48/61
5.1 EXPRESS channel model and
advantages
Channel Model Group Model
-
8/12/2019 Multi Cast Summary Pp t 1469
49/61
5.1 EXPRESS channel model and
advantages
2. EXPRESS Service Interface Extensions Source Host
count = CountQuery (channel, countId, timeout)is used tocollect count information for the channel
channelKey (channel, K(S,E)) is used to inform the networkthat the channel is authenticated
Subscriber Host
result = newSubscription (channel, [K(S,E)])is used to
participate in a channel result = deleteSubscription (channel)is used to unsubscribe
form a channel
count (channel, countId, count)is used to reply to CountQuery
-
8/12/2019 Multi Cast Summary Pp t 1469
50/61
5.1 EXPRESS channel model and
advantages
3 Advantages
EXPRESS provides 2 channels per source.
Channels neednt be treated as scarce resource
The source has exclusive access to a channel
A subscriber can only get data from the
designated source
Single source and knowledge of subscriber
numbers enables ISP easy in charging
24
-
8/12/2019 Multi Cast Summary Pp t 1469
51/61
5.2 EXPRESS count management
protocol (ECMP)
ECMP maintains the distribution tree and supports
source-directed counting and voting
Routing aspect of ECMP is simple because explicitsource specification allows reverse path forwarding
(RPF)
ECMP consists of three messages:
CountQuery(channel, countId, timeout)
Count(channel, CountId, K(S,E))
CountResponse(channel, CountId, status)
-
8/12/2019 Multi Cast Summary Pp t 1469
52/61
5.2 EXPRESS count management
protocol (ECMP)
Generic Counting Operation
CountQuery can start at source or any router on the channeldistribution tree. A sub-range of CountIds are defined for local use.
The query is sent from source to the first hop router, specifying achannel, countId and timeout
Receiving router minus timeout value by the measured round-triptime to its upstream router, and send the query to eachdownstream router
An end-station host responds to CountQuery with Count message
The value in the Count response is recorded locally. Once Countsare received from all neighbors or timeout, the counts are summedand the total is sent upstream in a Count reply
-
8/12/2019 Multi Cast Summary Pp t 1469
53/61
5.2 EXPRESS count management
protocol (ECMP)
Distribution Tree Maintenance subscriberId is a reserved countId used to report number of
subscribers in a subtree
A newSubscription causes an unsolicited subscriberId Countmessage to be propagated to the channel source, just as a hostjoins to the core in CBT
A host unsubscribes by sending zero Count message
For authenticated subscription, the upstream router usesCoutResponse to deny or validate the user. A valid key is cachedin the local router
Core routers are connected by TCP, using Count message tomaintain the connection
Edge routers are connected by UDP. Upstream routers have tosend CountQuery periodically to maintain the tree, like IGMP
-
8/12/2019 Multi Cast Summary Pp t 1469
54/61
5.2 EXPRESS count management
protocol (ECMP)
-
8/12/2019 Multi Cast Summary Pp t 1469
55/61
5.2 EXPRESS count management
protocol (ECMP)
Neighbor discovery uses neighbors countId, and fora local LAN, all channels countId is used byCountQuery, as IGMP general query
Packet forwarding is like conventional multicast. Arouter looks up (S,E) after receiving an EXPRESSpacket
Authentication is used based on trust of routers. Toget more security, end-to-end encryption can beused
Due to single source, ECMP is easy to manage andimplement
-
8/12/2019 Multi Cast Summary Pp t 1469
56/61
5.3 Multi-source applications
Multi-source applications can be built on EXPRESSchannels either by using multiple channels, one persource, or by allowing multiple sources to share achannel using higher-level relaying. The later one isspecially used for almost single source
Almost single source can have several sources, butone of them is the main source
Session relay approach uses an SR host to relaypackets. The main resource can reside on it.Packets are transferred from source station to SRhost by unicast
-
8/12/2019 Multi Cast Summary Pp t 1469
57/61
5.3 Multi-source applications
-
8/12/2019 Multi Cast Summary Pp t 1469
58/61
5.3 Multi-source applications
Advantages of session relay
The application can select the SR placement, thus reducecommunication
Backup SRs can be used for fault-tolerance
The SR can provide extra application-specific functionality beyondsimply relaying data, as it can add sequence numbers to relayedpackets
Can be used by ISP to provide session relay service. Standardrelaying and accessing protocol is needed
Session relay is like CBT but the later one has no applicationlevel control
Relaying time is not significant in wide area applications
-
8/12/2019 Multi Cast Summary Pp t 1469
59/61
5.4 Cost of EXPRESS
The key cost of EXPRESS Cost of router FIB memory for channels (12 bytes
for each entry) Cost of management-level router state (16 bytes
for each count activity)
Cost of maintaining this state (the cost growing
linearly with the number of channels) The incremental costs of EXPRESS can be
neglected compared to economic effects
-
8/12/2019 Multi Cast Summary Pp t 1469
60/61
5.4 Cost of EXPRESS
Counting: to get an average number of customers ina long period by polling doesnt affect systems
performance Proactive Counting: Receivers and routers
proactively send Count upstream without requiring aCountQuery solicitation. Get more accurate estimation of user number, consume
more bandwidth The convergence time of the algorithm grows approximately
linearly with the depth of the tree, while the depth of a treegrows logarithmically with the group size
-
8/12/2019 Multi Cast Summary Pp t 1469
61/61
6 References Douglas E. Comer, Internetworking with TCP/IP vol1, Principles,
Protocols, and Architectures, 4thedition Pages:319-350
Chuck Semeria and Tom Maufer, Introduction to IP Multicast Routing
L. Sahasrabuddhe and B. Mukherjee, Multicast Routing Algorithmsand Protocols: A Tutorial, IEEE Network, Vol. 14, No. 1,January/February 2000
H. Holbrook and D. Cheriton, IP Multicast Channels: Express Supportfor Large-scale Single-source Applications, Proc. of ACM SIGCOMMConference 1999
C. Diot, D. Levine, B. Lyles, H. Kassem, and D. Balensiefen,
Deployment Issues for the IP Multicast Service and Architecture, IEEENetwork, Vol. 14, No. 1, January/February 2000
http://www.nleymann.de/ip-multicast/mcLinksMain.htm
http://www.nleymann.de/ip-multicast/mcLinksMain.htmhttp://www.nleymann.de/ip-multicast/mcLinksMain.htmhttp://www.nleymann.de/ip-multicast/mcLinksMain.htmhttp://www.nleymann.de/ip-multicast/mcLinksMain.htm