Summary of ip multicast
Download
1 / 61

- PowerPoint PPT Presentation


  • 343 Views
  • Updated On :

Summary of IP Multicast. CPSC 601.43 Course Director: Dr. Anirban Mahanti Student : Liqi Shi. Outline. Introduction to Multicast Multicast Group and Service Model Multicast Routing Deployment Issues of Multicast EXPRESS References. 1 Introduction to Multicast.

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

PowerPoint Slideshow about '' - jela


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

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


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Summary of ip multicast l.jpg

Summary of IP Multicast

CPSC 601.43

Course Director: Dr. Anirban Mahanti

Student : Liqi Shi


Outline l.jpg
Outline

  • Introduction to Multicast

  • Multicast Group and Service Model

  • Multicast Routing

  • Deployment Issues of Multicast

  • EXPRESS

  • References


1 introduction to multicast l.jpg
1 Introduction to Multicast

1.1 Why Multicast /Multicast Applications

1.2 Broadcast/Unicast/Multicast


1 1 why multicast multicast applications l.jpg
1.1 Why Multicast /Multicast Applications

  • Same data sent to multiple receivers

  • To use the bandwidth efficiently

  • Reduce routing processing

  • Sender doesn’t get receiver’s address


1 1 why multicast multicast applications5 l.jpg
1.1 Why Multicast /Multicast Applications

  • Video/audio conference

  • IP TV, Video on Demand

  • Advertisement, Stock, Distance learning

  • Synchronizing of distributed database, websites


1 1 why multicast multicast applications6 l.jpg
1.1 Why Multicast /Multicast Applications

  • ConferenceXP: An Example of Multicast application

Distance Learning

Video Conference


1 2 broadcast unicast multicast l.jpg
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


1 2 broadcast unicast multicast8 l.jpg
1.2 Broadcast/Unicast/Multicast

UNICAST

With 4 receivers, sender must replicate the stream 4 times


1 2 broadcast unicast multicast9 l.jpg
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.


2 multicast group and service model l.jpg
2 Multicast Group and Service Model

  • Each multicast group is identified by a class D IP address

  • Members of the group could be anywhere in the Internet

  • Members can join and leave the group and indicate this to the routers

  • Senders and receivers are distinct: i.e., a sender need not be a member, but receivers should be

  • Routers listen to all multicast addresses and use multicast routing protocols to manage groups (IGMP)


2 multicast group and service model11 l.jpg
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 multicast datagram


2 multicast group and service model12 l.jpg
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


3 multicast routing l.jpg
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


3 1 transmission and delivery of multicast datagram l.jpg
3.1 Transmission and Delivery of Multicast Datagram

  • Local subnetwork transmission

    The source station simply addresses the IP packet to the multicast group, the network interface card maps the Class D address to the corresponding Ethernet 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 the construction 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


3 2 internet group management protocol igmp l.jpg
3.2 Internet Group Management Protocol (IGMP)

0 8 16 32

  • Introduction

    IGMP runs between hosts and the nearest multicast routers. A local host can use it to inform the router which multicast group it wants to be added in, while the multicast routers can use it to poll the LAN periodically, thus determine if known group members are still active

  • IGMP message format


3 2 internet group management protocol igmp16 l.jpg
3.2 Internet Group Management Protocol (IGMP)

  • IGMP versions

    • RFC1112, IGMP version 1

    • <draft-ietf-idmr-igmp-v2-01.txt>, 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 Query message

      • defines a Leave Group message

    • <draft-cain-igmp-00. txt>, 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 2 has been enhanced to support Group-Source Leave messages. This feature allows a host to leave an entire group or to specify the specific IP address(es) of the (source, group) pair(s) that it wishes to leave


3 2 internet group management protocol igmp17 l.jpg
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 multicast address declaring membership.

      • Local multicast router receives the message and establishes necessary routing path

    • Group membership report

      • Router sends Host Membership Query to 224.0.0.1 (all multicast hosts on a subnet)

      • Host responds with Host Membership report for each group to which it belongs (sent to group address)

      • other hosts in the same group “suppress” reports

      • Router periodically broadcasts query to detect if groups have gone away


3 2 internet group management protocol igmp18 l.jpg
3.2 Internet Group Management Protocol (IGMP)

Each host responds to the query with a random delay. If one report is received at the router, the other reports will be suppressed


3 3 multicast forwarding algorithms l.jpg
3.3 Multicast Forwarding Algorithms

Introduction: IGMP is responsible for delivering packets from a local router to directly attached subnetwork. To forwarding multicast packets across internet, we should use multicast protocols. 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)


3 3 1 flooding l.jpg
3.3.1 Flooding

  • When a router receives a packet, the router will determine whether it’s the first time it receives the packet. If so, the packet will be delivered to all interfaces except the one on which it arrived, otherwise the packet will be discarded.

  • No routing tables needed

  • Inefficient use of bandwidth

Non-red streams will be discarded according to flooding algorithm

SRC


3 3 2 spanning tree l.jpg
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 source subnetwork and group members


3 3 3 reverse path broadcasting rpb l.jpg
3.3.3 Reverse Path Broadcasting (RPB)

  • A local router only accepts packets from the ‘nearest’ source (parent), otherwise the packets are discarded

  • Accepted packets will be forwarded to all interfaces except the source

  • it does not take into account multicast group membership when building the distribution tree, so packets may be forwarded to non-membership subnetwork


3 3 4 truncated reverse path broadcasting trpb l.jpg
3.3.4 Truncated Reverse Path Broadcasting (TRPB)

  • It’s an enhancement of RPB

  • With the help of IGMP, multicast routers determine the group membership on each leaf subnetwork, thus avoiding forwarding packets to non-members

  • Eliminates unnecessary traffic on leaf subnetworks , but does not consider group memberships when building the branches of the distribution tree

Source,G1

G1

G3

G2

Truncated


3 3 5 reverse path multicasting rpm l.jpg
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 group members

  • First packet will be sent to all interfaces except the source. If none of the subnetworks connected to the leaf router have group members, the leaf router may transmit a "prune" message on its parent link informing the upstream router not to forward packets in this group to the leaf

  • In RPM, ‘first packet’ still needs to be forwarded throughout the network.

  • Each router has to maintain state information for all groups. It will be impossible as the number of groups and sources increases.


3 3 5 reverse path multicasting rpm25 l.jpg
3.3.5 Reverse Path Multicasting (RPM)

Source, G

First packet of G

G

G

Member subnetwork

Non-member subnetwork

Prune message

G


3 3 6 core based trees cbt l.jpg
3.3.6 Core Based Trees (CBT)

  • There is a backbone for CBT. It includes both core and non-core routers.


3 3 6 core based trees cbt27 l.jpg
3.3.6 Core Based Trees (CBT)

  • If a host wants to join one group, it has to send a unicast “join request” message to the core. The nearest router in the backbone will respond with ACK and the intermediate routers will record the routing information, thus a delivery tree for a group is established

  • Compared to previous algorithms, CBT can use bandwidth and router resources more efficiently

  • CBT may result in traffic concentration and bottlenecks near core routers since traffic from all sources traverses the same set of links as it approaches the core

  • A single shared tree may create trees not as optimal as source-trees


3 4 multicast protocols l.jpg
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


3 4 1 distance vector multicast routing protocol dvmrp l.jpg
3.4.1 Distance Vector Multicast Routing Protocol (DVMRP)

  • Source-based trees, data-driven (broadcast-and-prune), implicit join, dense mode protocol

  • RPM algorithm

  • Derived from Routing Information Protocol (RIP)

    • RIP forwards the unicast packets based on the next-hop towards a destination

    • DVMRP constructs delivery trees based on shortest previous-hop back to the source

  • DVMRP forwarding table: built from DVMRP’s own routing table, received prune messages

  • TTL and admin scoping available; physical or tunnel interfaces possible


3 4 1 distance vector multicast routing protocol dvmrp30 l.jpg
3.4.1 Distance Vector Multicast Routing Protocol (DVMRP)

  • If router C can receive datagrams from both A and B, then it will receive from A if A’s metric to the source is smaller than B’s or if they are equal, A has the smaller IP address on its downstream interface


3 4 1 distance vector multicast routing protocol dvmrp31 l.jpg
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 => scaling problems

Source

B

A


3 4 2 multicast ospf mospf l.jpg
3.4.2 Multicast OSPF (MOSPF)

  • OSPF provides each router with the topology of the Internet or its OSPF area

  • MOSPF uses OSPF’s topology database to calculate forwarding tree.

  • Broadcasting data for a group is demand-driven, that means it happens only when a host joins or leaves a group. Compared to data-driven protocols, the cost is that routing information should be propagated, because all routers in an area must maintain membership about every group


3 4 3 protocol independent multicast pim l.jpg
3.4.3 Protocol-Independent Multicast (PIM)

  • PIM has two variants: Dense mode (DM) and sparse mode (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 routing protocol to adapt to topology changes, but it is independent of the mechanisms of the specific unicast routing protocol, while DVMRP has its own routing table

    • PIM-DM simply forwards multicast traffic on all downstream interfaces until explicit prune messages are received


3 4 3 protocol independent multicast pim34 l.jpg
3.4.3 Protocol-Independent Multicast (PIM)

  • PIM-SM

    • Routers with directly attached or downstream members are required to join a sparse-mode distribution tree by transmitting explicit join messages

    • PIM-SM is similar to the Core-Based Tree (CBT) approach in that it employs the concept of a rendezvous point (RP) where receivers "meet" sources

Join a PIM-SM distribution tree


3 4 3 protocol independent multicast pim35 l.jpg
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 responds PIM-Join message. All routers between source and RP maintain the route so that subsequent unencapsulated multicast packets could be forwarded to the RP


3 4 3 protocol independent multicast pim36 l.jpg
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


3 4 4 bgmp and masc l.jpg
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 level Shared 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


3 4 4 bgmp and masc38 l.jpg
3.4.4 BGMP and MASC

unidirectional source tree


3 4 4 bgmp and masc39 l.jpg
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 its upstream provider

    • Claims for group allocation resolve collisions

    • Group allocations are advertised across domains

    • Group prefix allocations are not assigned to domains—they are leased

      • Applications must know that group addresses may go away

    • RFC 2909


3 4 4 bgmp and masc40 l.jpg
3.4.4 BGMP and MASC


4 deployment issues of multicast l.jpg
4 Deployment Issues of Multicast

  • Current architecture deters the commercial deployment of multicast.

    • Router mitigation: Older hardware doesn’t support multicast. If software upgrade is not applicable, the routers are forced into early retirement

    • Domain independent: For sparse mode multicast, it’s better to use CBT or PIM-SM. However, many problems are present when RPs/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 an RP 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


4 deployment issues of multicast42 l.jpg
4 Deployment Issues of Multicast

  • Current architecture deters the commercial deployment of multicast (cont.)

    • Group management: Current service model does not consider group management, including receiver/transmitter authorization, group creation, billing, etc. Dangers:

      • Flooding attack

      • Collision of sessions

      • Unauthorized reception

      • Changing the content of a session


4 deployment issues of multicast43 l.jpg
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 ([email protected])

      • 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:

        • <none>


4 deployment issues of multicast44 l.jpg
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 address allocation.

      • MAAA: It is very complicated, consisting of three protocols which connect hosts, domains, address allocation servers. The allocation of addresses between domains is handled by Multicast Address Set Claim (MASC). Multicast Address Dynamic Client Allocation Protocol (MADCAP) is used by host to request address from server. The servers inform each other of claimed address blocks by Address Allocation Protocol (AAP). However, MAAA never considers whether address resource is enough

      • Static allocation and assignment (GLOP): Restrict addresses available to domains by AS numbers

      • EXPRESS model: Uses per source and channel (S,E) structure, so each source can have 16 million channels

      • IPv6 addressing: IPv6 provides sufficient addresses


4 deployment issues of multicast45 l.jpg
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 it’s 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


5 express explicitly requested single source multicast l.jpg
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


5 1 express channel model and advantages l.jpg
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 should explicitly 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) won’t receive data from (S’,E)

    • Class D address (232.*.*.*) are assigned for experimental use by EXPRESS


5 1 express channel model and advantages48 l.jpg
5.1 EXPRESS channel model and advantages

Channel Model

Group Model


5 1 express channel model and advantages49 l.jpg
5.1 EXPRESS channel model and advantages

  • 2. EXPRESS Service Interface Extensions

    • Source Host

      • count = CountQuery (channel, countId, timeout) is used to collect count information for the channel

      • channelKey (channel, K(S,E)) is used to inform the network that 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


5 1 express channel model and advantages50 l.jpg
5.1 EXPRESS channel model and advantages

  • 3 Advantages

    • EXPRESS provides 2 channels per source. Channels needn’t 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


5 2 express count management protocol ecmp l.jpg
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 explicit source 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)


5 2 express count management protocol ecmp52 l.jpg
5.2 EXPRESS count management protocol (ECMP)

  • Generic Counting Operation

    • CountQuery can start at source or any router on the channel distribution tree. A sub-range of CountIds are defined for local use.

    • The query is sent from source to the first hop router, specifying a channel, countId and timeout

    • Receiving router minus timeout value by the measured round-trip time to its upstream router, and send the query to each downstream router

    • An end-station host responds to CountQuery with Count message

    • The value in the Count response is recorded locally. Once Counts are received from all neighbors or timeout, the counts are summed and the total is sent upstream in a Count reply


5 2 express count management protocol ecmp53 l.jpg
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 Count message to be propagated to the channel source, just as a host joins to the core in CBT

    • A host unsubscribes by sending zero Count message

    • For authenticated subscription, the upstream router uses CoutResponse to deny or validate the user. A valid key is cached in the local router

    • Core routers are connected by TCP, using Count message to maintain the connection

    • Edge routers are connected by UDP. Upstream routers have to send CountQuery periodically to maintain the tree, like IGMP


5 2 express count management protocol ecmp54 l.jpg
5.2 EXPRESS count management protocol (ECMP)


5 2 express count management protocol ecmp55 l.jpg
5.2 EXPRESS count management protocol (ECMP)

  • Neighbor discovery uses ‘neighbors’ countId, and for a local LAN, ‘all channels’ countId is used by CountQuery, as IGMP general query

  • Packet forwarding is like conventional multicast. A router looks up (S,E) after receiving an EXPRESS packet

  • Authentication is used based on trust of routers. To get more security, end-to-end encryption can be used

  • Due to single source, ECMP is easy to manage and implement


5 3 multi source applications l.jpg
5.3 Multi-source applications

  • Multi-source applications can be built on EXPRESS channels either by using multiple channels, one per source, or by allowing multiple sources to share a channel using higher-level relaying. The later one is specially used for ‘almost single source’

  • Almost single source can have several sources, but one of them is the main source

  • Session relay approach uses an SR host to relay packets. The main resource can reside on it. Packets are transferred from source station to SR host by unicast


5 3 multi source applications57 l.jpg
5.3 Multi-source applications


5 3 multi source applications58 l.jpg
5.3 Multi-source applications

  • Advantages of session relay

    • The application can select the SR placement, thus reduce communication

    • Backup SRs can be used for fault-tolerance

    • The SR can provide extra application-specific functionality beyond simply relaying data, as it can add sequence numbers to relayed packets

    • Can be used by ISP to provide session relay service. Standard relaying and accessing protocol is needed

  • Session relay is like CBT but the later one has no application level control

  • Relaying time is not significant in wide area applications


5 4 cost of express l.jpg
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


5 4 cost of express60 l.jpg
5.4 Cost of EXPRESS

  • Counting: to get an average number of customers in a long period by polling doesn’t affect system’s performance

  • Proactive Counting: Receivers and routers proactively send Count upstream without requiring a CountQuery 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 tree grows logarithmically with the group size


6 references l.jpg
6 References

  • Douglas E. Comer, Internetworking with TCP/IP vol1, Principles, Protocols, and Architectures, 4th edition Pages:319-350

  • Chuck Semeria and Tom Maufer, Introduction to IP Multicast Routing

  • L. Sahasrabuddhe and B. Mukherjee, Multicast Routing Algorithms and Protocols: A Tutorial, IEEE Network, Vol. 14, No. 1, January/February 2000

  • H. Holbrook and D. Cheriton, IP Multicast Channels: Express Support for Large-scale Single-source Applications, Proc. of ACM SIGCOMM Conference 1999

  • C. Diot, D. Levine, B. Lyles, H. Kassem, and D. Balensiefen, Deployment Issues for the IP Multicast Service and Architecture, IEEE Network, Vol. 14, No. 1, January/February 2000

  • http://www.nleymann.de/ip-multicast/mcLinksMain.htm


ad