The goal for this study is to clear out major issues concerning multicasting technology in modern network environments. Multicasting is the technology used to replace old technologies in cases where several people must receive the same information. Previously this has been made by using unicasting and broadcasting but the consumption of network resources and management issues force new technologies to be introduced.
This study is a part of the course "Internetworking seminar" and the main weight is put on IP-networks and multicast features in them. Some new technologies will replace parts of old IP networks in the near future and that's why we are also trying to figure out future development and trends.
Multicasting is a method of sending same information to several recipients simultaneously. It is an enhancement to traditional unicast and broadcast transmission methods. New network services and modern high capacity network techniques have created a lot of pressure to develop a method to share information in more efficient way than before.
Traditional transmission methods, unicasting and broadcasting, differ quite a lot from multicasting. In unicasting environment transmitter sends his data to one recipient. Normally in data communication networks he uses recipient's network address to reach him. For example, network address can be IP address or IPX address. If a transmitter wants to send the same information to multiple recipients he must use several addresses in order to reach all these recipients. It is possible that a transmitter must send the same data several times and waste large amounts of resources to do that.
Broadcasting means that same information is sent to all recipients. Recipient can then choose if he needs this information and then possibly discard it. From the transmitter's point of view it seems that data is sent once and usually to one address only. Broadcasting does not consume transmitter's resources any more than single unicasting but usually the resources of the network infrastructure are consumed in a quite inefficient way. Radio and television transmissions are a good examples of broadcasting. In modern data communication networks broadcasting is also quite often used. Some network protocols use broadcasting every time when communicating with each other. Some protocols use broadcasting to discover resources from the network. It is quite usual that a workstation send a broadcast message to a network when discovering the server for example. In datacommunications networks broadcasting is usually restricted to one physical or logical network segment in order to decrease load from the whole network. If broadcasting were not restricted then broadcast message flood from all parts of the network could cause the total load to rise too much.
Multicasting is a method to reach several recipients by one transmission. Recipients must also be defined separately and it must be possible to restrict those recipient who receive data that is sent. The result of one multicast transmission is exactly the same as when unicast transmission is committed several times consequently; once for each recipient. The major difference is that transmitter has to send data only once and transmitter has consumed resources as little as possible. The data is also sent to only those recipients who were expecting it. Network's resources are also consumed as little as possible.
By using multicasting technologies several advantages are gained. This is the major reason for development and discussion around different multicasting technologies recently. New data communication networks have created a whole lot more capacity. The increased capacity has created new possibilities to develop innovative services. These new services have created a need for new transmission methods.
Using traditional transmission methods in large scale networks like the Internet causes an enormous traffic load to the whole network. Broadcasting in large network consumes resources very inefficiently because all data packages are sent to all parts of the network. That's why in TCP/IP networks possibility to send broadcast messages is limited to one logical subnet. Often even this is too much. In A or B class network the broadcast domain is so large that infrastructure can not handle the total load caused by broadcast messages sent when discovering hardware addresses and other resources. This kinds of networks are nearly always divided to smaller subnets.
It is quite clear why broadcasting can not be used when sending the same information to several recipients outside the local subnet. Unicasting has been the other alternative. Services needing information sharing are currently created by using unicast technologies. This kind of solutions consumes server resources in totally other way than broadcast and multicast technologies. We can take an example: Server must deliver the same information to 1000 recipients. This is quite a lot of data and one transmission takes 10 seconds. By using unicast this takes 10000 seconds to commit this transmission. By using functional multicast method this would have taken only ten seconds. It is possible that the server transmitting this information could have something else to do during that 9990 seconds than retransmiting information several times! This kind of example grows to another scale if this data changes frequently and retransmissions to all recipient must be made a few times in a minute.
The another benefit is that quite often transmitter is not interested in who received the information it sends. There might just be a need that this information is available and whoever wants it can take part in this transmission and receive all information. Functional multicast solution can include methods to manage addresses and who receives data sent to some multicast address. Functional multicast system works just like traditional mailing lists. One party can send some e-mail to several recipients. The major disadvantage in mailing list system is that it consumes resources quite much because underlying infrastructure does not support multicasting.
The current development in the Internet has showed that the traditional audio and video services are slowly integrating to Internet services. This has set a demand for higher capacity and new transmission methods.
Traditional audio and video services like TV and radio have always used broadcast transmissions to reach all recipient needing these services. The inability to use broadcasting technology in the Internet has slowed down this development. It is quite hard to reach several listeners or watchers by using unicast technology. The capacity of the server must be enormous and it's network connection is very heavily loaded. Currently the Internet bandwidth is not broad enough to support feasible transmissions.
By using multicast technology it would be easy to define who wants to receive the program that TV or radio station is sending and then include these users to the multicast transmission. TV or radio station can then easily handle the load caused by transmission and recipients can define if they want to see or hear the program.
Conferencing is another service quite heavily weighted in current development discussions. The need for remote conferencing between several parties has emerged recently to be a one of the most important services for large multinational companies. Functional remote conferencing method decreases the need for travelling and causes enormous savings in travel expenses and lowers the step to co-operate with people in distant locations.
Currently companies use quite often ISDN based video conferencing equipment or special services provided by telecommunications service providers for example. This kind of equipment is usually expensive and inefficient. The major question is that if we have devices like computers capable of providing this kind of services, why can't we use them instead of special equipment.
Internet has connected companies together and since there is already a connection capable of providing these services between companies why create another one. Conferencing in the Internet, intranet of extranet would be economically reasonable. The lack of multicasting technology has been the greatest reason to slow down companies in this area.
Instead of using broadcast technologies to discover network services the multicast transmission can also applied to resource discovery. Service discoveries are usually limited to one logical subnet in TCP/IP network. By using multicasting an multicast addresses to contact service managers the logical area to discover servers from can easily be expanded to another scale. It would certainly be nice if logical subnets did not limit the servers ability to provide services.
This kind of solution would make it possible to connect to network everywhere and then just use multicast transmission to receive appropriate parameters for networking and server connections. This would enhance current Bootp or DHCP protocols quite a lot.
Recently groupware software like Lotus Notes, Microsoft Exchange and Corel Groupwise have become much more important in information sharing than just traditional e-mail. Groupware softwares include possibilities to share information with other parties. In large scale networks it is important that databases in several distant locations are synchronised as often as possible in order to avoid collisions and keep all locations updated with recent information.
Synchronisation and information sharing with distant locations is usually done by replication. Changes are sent from one database to all other databases containing the same information. Now this must be done separately with every server containing the databases. By using multicasting it would be possible to send changes instantly to all other databases by one transmission. All databases would instantly contain the same information.
This kind of solution would make it possible to create very large 'Groupware' networks. All information would be independent of location all the time. User in China could read the same information as the user in USA and they could together make changes to the database without danger of being unaware about the changes the other party makes.
IP multicast is an extension of IP-protocol, which uses class D addresses, i.e. addresses from 224.0.0.0 to 239.255.255.255 (224.0.0.0/4). These addresses are called group addresses. When applications send one copy of information to such group address, IP multicast capable network copies information to all interested recipients. Each packet of information is transferred only once over one particular link and is copied to different recipients only when paths to recipients differ. Figure 3.1 clarifies the difference between IP-unicast and IP-multicast. It is clear, that IP unicast consumes a lot more network bandwidth than IP multicast in this kind of applications.
Figure 3.1.
IP multicast capable network forwards multicast packets according to group address of the packet. Network keeps track of which parts of the network have multicast hosts joined to particular groups. Multicast packets for each group are only forwarded towards such networks, that have IP multicast capable hosts joined to this particular group. Therefore, if some media-broadcasting server's IP multicast group does not have any members (i.e. recipients), no network resources are consumed either.
IP multicast extensions to standard IP protocol are described in RFC 1112 [1]. This RFC specifies two levels of support for IP multicast. At level 1, hosts can only send multicast datagrams. This can be useful in some limited multicast based services, for example resource location. At level 2 full IP multicast is implemented. Hosts can join to multicast groups and receive datagrams sent to group addresses.
The most important part of host IP multicast support implementation is Internet Group Management Protocol (IGMP) [1] [15]. Logically IGMP situates in IP layer along with ICMP (Internet Control Message Protocol). IGMP's function is to keep neighbouring multicast routers informed of the host group memberships present on a particular local network. IGMP uses reserved multicast group 224.0.0.1 to communicate with local routers. This multicast group is called "all-hosts group", which addresses all hosts in local LAN. Through this channel IP multicast routers know, if there are any hosts that are joined to a multicast group in this particular LAN. Basically routers send IGMP queries to this address at local LAN and hosts respond by telling, which groups they want to join.
The mapping between a Class D IP address and ethernet MAC-layer multicast address is obtained by placing the low- order 23 bits of the Class D address into the low-order 23 bits of IANA's reserved MAC-layer multicast address block. Mapping from class D group address to MAC address is not one to one, because high 5 bits of class D group address are discarded. In practice, there is a small chance of collisions between different groups. Upper layer protocols detect also if a received packet is relevant for this host.
Normally sender does not keep state information about receivers in IP multicast, i.e. transport is connectionless, using UDP datagrams with IP multicast addresses. This kind of transport is appropriate in many streaming applications, for example transferring video and audio from media servers or in video conferences. Video and audio decoders can manage with some missing datagrams without information content to disturb too much.
RFC 1889 [9] with a companion RFC 1890 [11] describes real-time transport protocol (RTP) and supporting RTP control protocol (RTCP). These are intended for real-time transfer of video and audio over IP unicast or multicast network services.
There are many situations, where multicast transport must be reliable. For example in multicasting web-applications and in cache or other database replication reliable transport is required. Normal TCP is not possible, because it is designed to be one to one protocol. TCP can keep state information only about one connection, whereas in multicast connection there is in principle state information for each sender-receiver pair.
One multicast transport connection can involve hundreds or even thousands of receivers. Different receivers may lose different packets and packets can arrive in different order. Reliable transport protocol must handle all these situations, so that every receiver receives consistent information. Therefore, designing reliable, scaleable and efficient multicast transport protocol is a really demanding project.
There exists many proposals for this kind of protocol and active research is still going on. One of the proposals is described in RFC 1301: Multicast Transport Protocol (MTP) [2]. There is also MTP-2, which is a revised version of MTP [10]. An another example of reliable transport protocol is RMTP (Reliable Multicast Transport Protocol) [16].
IP unicast routing is relatively simple compared to IP multicast routing. In unicast routing, each host has unique IP address, which determines route to that host. When doing multicast routing, the problem to solve is much harder. Now destination address does not specify route to some place, but merely a transmission session. Multicast routers should forward datagrams to all participants in this session.
The basic approach is that multicast capable routers communicate with neighbouring multicast routers and exchange information about group membership and network topology. Because each physical network can have several multicast capable routers, one of them is selected as the designated router for this network. This router then communicates with other designated routers in neighbouring networks to construct a spanning tree for each multicast source. (This is called Reverse Path Multicasting (RPM).) Now datagrams from source to other group members is transferred along this spanning tree. Spanning tree is loopless and guarantees, that each receiver gets it's datagrams along the shortest possible route.
Constructing and maintaining spanning trees for sources is difficult task. Hosts join and leave groups which means that spanning trees must be updated all the time. Also new sources appear and old ones go away, so spanning trees must be constructed and deleted. There are two basic methods for handling of spanning trees.
The first one assumes that group members are located densely throughout the network and there is plenty of network resources available between members. Multicast routing protocols working in this mode are called "dense-mode" routing protocols. They periodically flood group information between routers to construct and update spanning trees. Flooding is not a problem, if network is limited in size and there is enough bandwidth available. Distance Vector Multicast Routing Protocol (DVMRP) [4] [5], Multicast Open Shortest Path First (MOSPF) [18] and Protocol-Independent Multicast - Dense Mode (PIM-DM) are dense mode protocols.
The second assumption is that group members are sparsely distributed throughout the network and there is limited network bandwidth available. Therefore flooding is not possible to distribute routing information between routers but more sophisticated procedures must be used. Routing protocols working in this mode are called "sparce-mode" protocols. Some of these protocol do not build a different spanning tree for each source - destination group pair, but build one spanning tree per multicast group. Core Based Trees (CBT) [19] and Protocol-Independent Multicast - Sparse Mode (PIM-SM) are examples of such methods.
MBone (IP Multicast Backbone on the Internet) is a set of interconnected IP multicast capable networks. Because not all internet backbone routers support native IP multicast, MBone is constructed with tunnels across networks that do not support multicast routing. Figure 3.2 describes tunnelling. MBone therefore is a virtual network layered on top of internet.
Figure 3.2.
Encapsulation in tunnels is IP in IP, i.e. multicast IP packets are prepended with another IP header, where source and destination addresses are addresses of the tunnel endpoints. Tunnel endpoints are routers or workstations with mrouted software.
Routing protocol used in MBone is DVMRP [4] [5]. Some parts may also use locally MOSPF or PIM. Implementing multicast routing in the whole internet is not yet possible, because none of the current multicast routing protocols scale to such a big network. Development is going towards shared spanning-tree algorithms (PIM-SM and CBT protocols) which are designed to scale to the whole internet.
Address space for multicast addresses in IPv6 addressing scheme is much larger than in IPv4 scheme. Address space in IPv6 is 128 bits and from this address space a fraction of 1/256 is allocated to multicast addresses.
Binary prefix of multicast addresses in IPv6 is 1111 1111. The rest 120 bits are divided to three fields: 4 bits for flags, 4 bits for scope and remaining 112 bits for group ID. Figure 3.3 below shows the structure of multicast addresses in IPv6 addressing scheme.
| 8 | 4 | 4 | 112 bits |
+--------+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
Figure 3.3.
Low order bit of flags indicates permanently or non-permanently-assigned multicast address. Other flag bits are zero. Scope field is used to limit the scope of the multicast group. Possible scopes are node-local, link-local, site-local, organisation-local and global scope. Non-permanently-assigned multicast addresses are meaningful only within a given scope. [3]
Mapping of IPv6 multicast addresses to ethernet MAC addresses is similar to IPv4 mapping, but low order 32 bits of group address are mapped to MAC address instead of low order 23 bits in IPv4 specification [7].
In modern networking, security issues must also be considered. Security issues in IP multicast concentrates around applications used. Because there are no application level proxies for multicast applications, security is only depended on desktop applications. Today's applications are developing rapidly and correctness of programs can not be guaranteed.
Typical security problem in multicast application (and in any application reading unchecked data from network) is overwriting buffer area in memory, typically in stack. If application receives data from multicast stream and places that unchecked in buffer allocated from stack, application program may end up running code from attacker. Therefore allowing IP multicast traffic to secure networks with unmature and experimental multicast applications is a big unknown.
Privacy in multicasting is also sometimes important. For example many video conferences are private in nature, so outsiders should not be able to join conference session or to monitor the session. Privacy is easy to achieve by agreeing on secret key to be used to encrypt session data. Key exchange can be made before session for example by sending PGP encrypted mail, which contains key to be used. To join the session, participant enters the key to her conference application, which uses that key to encrypt and decrypt data to and from other participants.
ATM networks will be the future trend in the backbone networks. It is very possible that ATM networks will replace also current LAN protocols. Currently the only problem is the unavailability of ATM specific services and protocol stacks capable to offer ATM services to applications. Winsock 2 protocol might help this and it is possible that native ATM services will be much more important that today. ATM's native transport system is very capable of transmitting real-time video and audio, which are the core systems requiring multicasting. The bandwidth ATM networks are capable of offering is also a very important factor when defining the needs for new infrastructure. Even though ATM is very connection oriented and ordinary IP multicasting methods are not directly available.
There is also a solution for multicasting in the ATM network based on UNI 3.0/3.1. This solution is called MARS (Multicast Address Resolution Server). MARS is derived from original ATM ARP service and contains information to transfer ATM network to a multicast capable network infrastructure. MARS service is described in RFC 2022 [12].
The ATM Forum's current signalling specifications does not specify multicast addressing. Multicast is supported by point to multipoint unidirectional VC's. MARS works through interacting with ATM endpoints like hosts and routers. MARS transmits group information to transmitting hosts and through that hosts are available to reach several destinations by one transmission.MARS solution quite tightly bound to IPv4 networks. The specification has few features that support also other higher level protocols and there has been deliberate attempt to create this method to work with other protocols also. Currently IPv4 is very clearly the dominant protocol in the large scale networks, but IP is really not optimal choice for true real-time applications and the overhead IP protocol creates in video or audio transmission is quite useless.
Video conferencing is the other bandwidth consuming service important for many companies. The importance of clear picture and hi-fi quality voice is quite big even in standard every day videoconferences. Otherwise it will be hard to convince ordinary users to use these services instead of travelling around the world. The other thing is the need to share applications and files between several users simultaneously. I would personally like the idea of having one connection with few colleagues and be able to use one application with them and have live discussion at the same time. This would be a enormous load for the underlying network, but the work and idea sharing capability without the jet lag would certainly be valuable.
If the future trend is that all communication methods use the same base infrastructure it would certainly be reasonable to include voice, video, conferencing and data transmissions to this base infrastructure. Even if the base infrastructure in the future is ATM nobody is able to say in what direction the protocol stack goes. Native ATM services are very appropriate for several types of services but TCP/IP networks interconnect the whole world already and because of that these networks have several advantages to ATM networks, despite of the overhead caused by protocol and useless processing is causes in several phases.
CU-SeeMe is a free videoconferencing program (under copyright of Cornell University [13] and its collaborators) available to anyone with a Macintosh or Windows and a connection to the Internet. With CU-SeeMe, you can videoconference with another site located anywhere in the world. By using a reflector, multiple parties at different locations can participate in a CU-SeeMe conference, each from his or her own desktop computer. There is currently also a commercial version of CU-SeeMe application [14].
The interesting thing in CU-SeeMe is the multicast software called reflector. It was developed because Apple Macintosh was not capable to use IP multicast methods. Reflector makes it possible to have multipoint videoconference using Macs and PCs. There are several public hosts in the Internet that are all the time sending video transmission using CU-SeeMe and it really seems to work.
CU-SeeMe's Reflector works on Unix workstation and it send packets coming from participant to other participants by using unicast several times consequently. Reflector can use also IP multicast to send packets to several locations but originally it uses own technology to transmit packets.
There exists experimental www-browser, mMosaic, that supports multicasting everything you browse [6]. This can be used for example to show www-pages as slides for other participants. mMosaic also allows one to run Xt toolkit based X programs inside mMosaic window, so that all participants can see that program in their mMosaic windows.
Another similar, but more scalable to many participants around the internet is WebCanal [8]. WebCanal project has specified new reliable transport protocol for multicast delivery. Protocol is Light-weight Reliable Multicast Protocol (LRMP). It is based on Real Time Transport Protocol / Real Time Transport Control Protocol (RTP/RTCP) [9] and uses UDP frames for data delivery. LRMP offers three important features: loss repair, ordered packet delivery, and adapted rate-based flow control. This is one of the newest reliable multicast transport protocols discussed in section 3.2.
Current stanard for distributing internet news articles is NNTP [17]. All communication with NNTP is point to point utilizing TCP connections. Current NNTP protocol uses quite a lot of network bandwidth. In the other hand the nature of news distribution fits very well in the idea of multicasting. The challenge is to develop reliable transport suitable for news transmission between news servers. Utilizing multicasting can save considerable amount of network bandwidth.
Multicast techniques used in reasonable way can be a tool for future proxy or cache implementations. It is possible that there are a network of several proxies changing updates by using multicast. Large network of newly updated proxies could easily ease the total load of the Internet. In several cases it would not be necessary to transfer data from the original site if local proxy contains the same information already.
There has also been discussions about corporate intranet radio channels...
Multicast applications and their future are very important factors for Internet content development. Simultaneous transmission to several locations is an essential basic structure that must be in use in order to create some kind of mass transmissions into Internet. It is very hard to figure out any ways to implement WebTV or WebRadio without multicast capabilities. There is certainly too much load if one server must take care of several simultaneous transmission by using unicast. Current test sites can manage their load by special arrangements but true business applications do certainly need multicast features.
The most important technical aspects of IP multicast are IP multicast routing and transport protocols. Efficient routing protocol is necessary for IP multicast routing to become standard in every router in internet. Reliable, efficient and scalable transport protocol is necessary for many applications. Multicast transport protocol is technically demanding and there are many different approaches with different properties regarding efficiency and scalability in large and heterogeneous networks.
Last modified: Thu May 29 17:56:54 EET DST