Examensarbete LITH-ITN-KTS-EX--06/004--SE
IP TV påverkan och anpassning av IP-nätet hos en
datakomoperatör.
Jessica Eriksson
2006-02-03
Department of Science and Technology Institutionen för teknik och naturvetenskap Linköpings Universitet Linköpings Universitet SE-601 74 Norrköping, Sweden 601 74 Norrköping LITH-ITN-KTS-EX--06/004--SE
IP TV påverkan och anpassning av IP-nätet hos en datakomoperatör. Examensarbete utfört i kommunikation- och transportsystem vid Linköpings Tekniska Högskola, Campus Norrköping Jessica Eriksson
Handledare Monika Gullin Examinator Di Yuan
Norrköping 2006-02-03 Datum Avdelning, Institution Date Division, Department
Institutionen för teknik och naturvetenskap 2006-02-03
Department of Science and Technology
Språk Rapporttyp ISBN Language Report category ______x Svenska/Swedish Examensarbete ISRN LITH-ITN-KTS-EX--06/004--SE Engelska/English B-uppsats ______C-uppsats Serietitel och serienummer ISSN x D-uppsats Title of series, numbering ______
______
URL för elektronisk version
Titel Title IP TV påverkan och anpassning av IP-nätet hos en datakomoperatör.
Författare Author Jessica Eriksson
Sammanfattning Abstract TDC Song has just entered the private market with Internet Access and VoIP services. To stay competitive on the market in the future, the company will be required to offer the customers video- and TV- services and have a complete triple play packet. The purpose of this master s thesis is to determine which techniques that exist within IPTV, analyze TDC Song s network and see what actions the company needs to take in network design and network quality in order to distribute a premium packet with up to 50 channels when using Moving Picture Experts Group phase 2 (MPEG-2) to compress the video. A literature study was made to get knowledge about IPTV and the available standards to compress, transmit and display the video. Furthermore, tests were set up and performed in both laboratory and real life network environments. The theoretical study showed that the network should be configured with Protocol Independent Multicast Sparse Mode (PIM-SM) as the intra-domain routing protocol and Multicast Source Discovery Protocol (MSDP) as the inter-domain protocol to connect the PIM-SM domains together. The switches that can handle layer 3 routing should also be configured with PIM-SM and the other switches should use Internet Group Management Protocol Snooping to enhance their performance. In the laboratory tests the Extreme Summit48i switch couldn t act as Rendezvous Point (RP), but has no problem with handling multicast traffic up to 1 Gbps. No multicast traffic ought to be transmitted in the parts of the network where the Cisco routers 7206 and 3640 are situated, since their performance decrease and they will drop packets. The downlink speed from the network to the Digital Subscriber Line Access Multiplexer (DSLAMs) should be upgraded from 100 Mbps to 1 Gbps to be able to handle the IPTV, VoIP and Internet traffic with as little congestion as possible.
Nyckelord Keyword IPTV, multicast, networking Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra- ordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/
© Jessica Eriksson
Introducing IPTV
Impacts and adjustments to the distribution and backbone network of a network operator
Master Thesis project performed at TDC Song AB
by
Jessica Eriksson
Tutor at TDC Song AB: Monika Gullin Tutor at Linköping University: David Gundlegård Examiner: Di Yuan
Abstract
TDC Song has just entered the private market with Internet Access and VoIP services. To stay competitive on the market in the future, the company will be required to offer the customers video- and TV- services and have a complete triple play packet.
The purpose of this master’s thesis is to determine which techniques that exist within IPTV, analyze TDC Song’s network and see what actions the company needs to take in network design and network quality in order to distribute a premium packet with up to 50 channels when using Moving Picture Experts Group phase 2 (MPEG-2) to compress the video.
A literature study was made to get knowledge about IPTV and the available standards to compress, transmit and display the video. Furthermore, tests were set up and performed in both laboratory and real life network environments.
The theoretical study showed that the network should be configured with Protocol Independent Multicast Sparse Mode (PIM-SM) as the intra-domain routing protocol and Multicast Source Discovery Protocol (MSDP) as the inter-domain protocol to connect the PIM-SM domains together. The switches that can handle layer 3 routing should also be configured with PIM-SM and the other switches should use Internet Group Management Protocol Snooping to enhance their performance.
In the laboratory tests the Extreme Summit48i switch couldn’t act as Rendezvous Point (RP), but has no problem with handling multicast traffic up to 1 Gbps. No multicast traffic ought to be transmitted in the parts of the network where the Cisco routers 7206 and 3640 are situated, since their performance decrease and they will drop packets. The downlink speed from the network to the Digital Subscriber Line Access Multiplexer (DSLAMs) should be upgraded from 100 Mbps to 1 Gbps to be able to handle the IPTV, VoIP and Internet traffic with as little congestion as possible.
A buffer in the Set-Top Box should be enough to eliminate any jitter the network may cause. To be able to handle packet losses and the limited bandwidth, the network should be designed with a separate VLAN per service. This will make it possible for the company to prioritize IPTV by using VLAN tags to give Quality of Service.
2 (80)
Acknowledgements
I would like to thank the employees at TDC Song that have been involved by helping me whenever I have had a question. Furthermore, I want to give a special thanks to my tutor Monika Gullin for her support and Mikael Abrahamsson for his great networking knowledge and help during the tests.
From the University I would like to thank my tutor David Gundlegård. His broad knowledge in data- and telecommunication has given me valuable inputs and reflections on my work. I would also like to thank my opponents Mattias Bruhn and Anna Garde for their comments and suggestions that have improved my rapport.
Finally, I want to thank my family and friends for the great support I have been given. Thank you for listening when I needed it the most.
3 (80)
Contents
1 INTRODUCTION 7
1.1 BACKGROUND 7 1.2 PURPOSE 7 1.3 OBJECTIVE 7 1.4 SCOPE 8 1.5 METHODOLOGY 8 1.6 OUTLINE 8
2 THE FUNDAMENTALS OF IPTV 9
2.1 THE INTERNET PROTOCOL 9 2.2 TELEVISION 10 2.3 SYSTEM COMPONENTS 11 2.4 VIDEO COMPRESSION 13 2.5 MEDIA STREAMING PROTOCOLS AND STANDARDS 14 2.5.1 TRANSPORT CONTROL PROTOCOL AND USER DATAGRAM PROTOCOL 15 2.5.2 REAL-TIME TRANSPORT PROTOCOL AND REAL-TIME CONTROL PROTOCOL 15 2.5.3 REAL-TIME STREAMING PROTOCOL AND SESSION INITIATION PROTOCOL 16 2.5.4 SESSION DESCRIPTION PROTOCOL 16 2.6 QUALITY OF SERVICE 16 2.6.1 JITTER 17 2.6.2 PACKET LOSS 18 2.6.3 BANDWIDTH 20 2.6.4 TRAFFIC ISOLATION 20 2.6.5 SCHEDULING AND POLICING 22
3 MULTICAST 25
3.1 INTERNET GROUP MANAGEMENT PROTOCOL 26 3.1.1 IGMPV1 27 3.1.2 IGMPV2 27 3.1.3 IGMPV3 28 3.2 MULTICAST ROUTING ALGORITHMS 29 3.2.1 FLOODING 29 3.2.2 MULTICAST DISTRIBUTION TREES 29 3.2.3 REVERSE PATH FORWARDING 31 3.3 MULTICAST ROUTING PROTOCOLS 32 3.3.1 DISTANCE VECTOR MULTICAST ROUTING PROTOCOL 32 3.3.2 MULTICAST OPEN SHORTEST PATH FIRST 33 3.3.3 PROTOCOL INDEPENDENT MULTICAST - DENSE MODE 34 3.3.4 PROTOCOL INDEPENDENT MULTICAST - SPARSE MODE 37 3.3.5 CORE-BASED TREES 40 3.4 INTER-DOMAIN MULTICAST ROUTING 42 3.4.1 MULTIPROTOCOL BORDER GATEWAY PROTOCOL 42
4 (80)
3.4.2 MULTICAST SOURCE DISCOVERY PROTOCOL 43 3.4.3 BORDER GATEWAY MULTICAST PROTOCOL 45 3.4.4 MULTICAST ADDRESS SET-CLAIM 46 3.5 MULTICAST AT LAYER 2 46 3.5.1 LAN SWITCHES 47 3.5.2 INTERNET GROUP MANAGEMENT PROTOCOL SNOOPING 48 3.5.3 CISCO GROUP MANAGEMENT PROTOCOL 50
4 TDC SONG’S NETWORK 52
4.1 CORE NETWORK 52 4.2 DISTRIBUTION NETWORK 53 4.2.1 STOCKHOLM 53 4.2.2 GÖTEBORG 54 4.3 ACCESS NETWORK 55 4.4 TRAFFIC 56
5 TEST ENVIRONMENT 57
5.1 LABORATORY TEST 57 5.1.1 TEST 1 57 5.1.2 TEST 2 58 5.1.3 TEST 3 58 5.1.4 TEST 4 59 5.1.5 TEST 5 59 5.1.6 TEST 6 60 5.1.7 TEST 7 60 5.1.8 TEST 8 61 5.2 LIVE NETWORK TEST 62 5.2.1 TEST 9 62
6 RESULT AND DISCUSSION 64
6.1 TEST 1, 2 AND 3 64 6.2 TEST 4 64 6.3 TEST 5 65 6.4 TEST 6 66 6.5 TEST 7 AND 8 67 6.6 TEST 9 70
7 CONCLUSION 71
7.1 FURTHER WORK 72
5 (80)
APPENDIX A - NETWORKING FUNDAMENTALS 76
APPENDIX B - NETWORK AND TEST EQUIPMENT 77
APPENDIX C - CONFIGURATION 79
6 (80)
1 Introduction
1.1 Background
TDC Song is a Nordic company that delivers Asymmetric Digital Subscriber Line (ADSL, see appendix A) access to wholesale customers, i.e. companies that offer the service down the chain to the private market. In 2005, the services consist of Internet Access and Voice over Internet Protocol (VoIP). Since the end of 2005 TDC Song also offers these services directly to private customers.
To stay competitive on the market the company will in the near future be required to offer the customers video-and TV- services and have a complete triple play packet. This means that the customers will have the opportunity to get Internet, telephone and TV on the same copper wire at a lower price.
When Internet Protocol Television (IPTV) arrives as a service, apart from Internet and VoIP, new demands will be required on TDC Songs network infrastructure in the form of quality, capacity and equipment. The quality because the transmissions are in real-time and the customers expects a TV picture with good quality. The capacity since the company wants to offer a large amount of different channels. It also requires equipment that can handle the multimedia format and the demand for compression. Another interesting aspect to consider is the potential to store already sent programs so the customer can watch them when it is convenient for them.
This master thesis is based on the fact that TDC Song wants to know what is required to deliver the quality the customer demands when they are watching TV. It is also based on the interest of examine how and if the network design for the backbone- and distribution-network will have to change in order to deliver this TV services.
1.2 Purpose
The purpose of this master’s thesis is to determine which techniques exist within IPTV, analyze the network and the actions needed in network design and network quality given a premium packet with up to 50 channels when using Moving Picture Experts Group phase 2 (MPEG-2) to compress the video, see section 2.4.
1.3 Objective
The main goal of the master’s thesis is to recommend suitable networking technologies for distributing IPTV that is appropriate to implemented within TDC Song’s network and to locate weaknesses in TDC Song’s present network design.
7 (80) 1. Introduction
1.4 Scope
A complete IPTV solution consists of many elements and TDC Song is faced with the challenge of making numerous decisions that in the end will impact the customers IPTV experience. Due to the limited amount of time, the scope of this thesis will be restricted to the network that the company will use to transmit the service IPTV. It will not handle subjects like content rights, location of the streaming source in the network, security aspects or any specific IPTV equipment like set-up boxes or servers.
1.5 Methodology
The first step was to get knowledge about IPTV and the standards that exists to compress, transmit and display the video. To obtain this information a literature study was made. From that, conclusions was drawn about what multicast protocol to use for the tests. After that the tests were set up and performed in both laboratory and real life network environments. From this recommendations and conclusions was drawn.
1.6 Outline
This master thesis is written to a audience with a basic knowledge about data- and telecommunication. Chapter 2 gives a theoritical framework about IPTV and the quality demands required on the network to distribute IPTV services. Chapter 3 introduces multicast and describes the most common protocols used to communicate via multicast. Chapter 4 displays TDC Song’s network structure and equipment. Chapter 5 shows the setup for the tests. Chapter 6 includes results and discussions for each test. In chapter 7, conclusions can be found together with further work that would be interest to do in the area.
8 (80)
2 The fundamentals of IPTV
Today there exist several techniques to get TV transmitted to your home. It can for instant be distributed via satellite, cableTV network, terresterial or through a telecom operators IP network, which is the case with IPTV. TDC Song has decided to enter the private market under the name TDC and is today offering Internet and VoIP services to the customers. The company also wants to include IPTV to be able to offer a complete triple play packet, which is necessary to compete on the market.
The competition on the market is one of many factors that drive the development of IPTV forward. Other examples are mentioned below: Interactivity – for example voting on your favorite candidate in a TV program with a click on the TV remote instead of making a phone call. Individualized channel content – the possibility for customers to pay for the channels they want to see and not be forced to pay for an entire packet to get one particular channel. On-demand – offer the customer the possibility to see their favorite program when it suits them, without recording it first. For example watching the six o’clock news at eight o’clock. This is done by storing the programs on a server. Cost-effective – three services in one network. Channel space – the technology to offer more channels, e.g. local channels [Internet academy, 2005].
IPTV comes with advantages, like the ones described above, on-demand, high capacity, many channels, modern technique and interactivity. But like every other new technique IPTV also has some disadvantages. Because it is new it has not yet been standardized and has a complicated end-to-end delivery compared with for example satellite that only has transmitter → satellite → end customer. It will involve a big initial investment for the telecom operators with few customers at the beginning [Internet academy, 2005].
As the term IPTV suggests the technique consists of two parts, the Internet Protocol (IP) and Television (TV).
2.1 The Internet Protocol
The Internet Protocol (IP) is defined in Request For Comments (RFC) 791 maintained by Internet Engineering Task Force (IETF). IP specifies the packets format and addressing in the network and resides at the network layer of the Open Systems Interconnection (OSI) model, see appendix A. It offers an unreliable connectionless service for transporting data from source to destination in an interconnected network, which means that there is no guarantee that the delivery will be successful [Broadband Services Forum, 2005].
Every node in the network has its own IP address that is used to communicate with each other. It consists of a network number/identifier (netid) and a host number/identifier (hostid). To send packets of data from one host to another, it is IP with the help of other protocols that performs the routing and other harmonization functions. For example routing protocols are used, to set up a routing table. When a router receives a packet, it reads the destination netid from the packet header and uses its routing table to forward the packet on the correct route. If
9 (80) 2. IPTV
the size of the packet, that was received, is larger than the maximum frame size of the destination network, the IP in the destination gateway divides the block of data into smaller blocks. Each block is then forwarded in a separate packet to the IP address in the destination host, where they are reassembled to the original block again [Halsall, 2005].
There exist two versions of IP, IPv4 and IPv6. Version number four is still the dominating version of the Internet. The upgrades in version six consists of significantly more available addresses and improvements in areas of routing and auto configuration. IPv6 is forecasted to be the protocol used in the future [Ahlin, 2003].
2.2 Television
Television (TV) specifies the medium of the communication, which in this case is the transmission of pictures and sounds to the end-users located at the end of the access networks [Broadband Services Forum, 2005]. The TV technology is based on many scientist’s inventions and discoveries through the years, but John Logie Baird (1888-1946) from Scotland is often called the inventor of television [Utbildningsradion, 2005].
In Sweden, TV was first shown 1930 at Röda Kvarn in Stockholm and during the 40s some test broadcasts was performed at Kungliga Tekniska Högskolan (KTH), but the official start of TV was in September 1956. In 1962, the first live broadcast was sent over the Atlantic via a satellite and at the end of the 60s the color TV was introduced. Until the middle of the 80s there had only been two channels, SVT1 and SVT2, but 1987 TV3 started to broadcast through satellite and today there exist more than 30 channels that transmit digital and/or analog TV [Teracom, 2005].
Today analogue transmission is the most common technique used to transmit TV and Sweden, like most of Europe, transmits according to the Phase Alternating Lines system (PAL). Digital TV, on the other hand, sends according to another standard called Digital Video Broadcasting (DVB). The signal can be transmitted via satellite (DVB-S), cable (DVB-C) or terrestrial (DVB-T). With digital TV, compared to analog, more channels can be transmitted on equal amount of bandwidth and another advantage with the digital TV is the quality. The digital signal eliminates analog broadcasting artifacts like “snow” and static noise in audio, which results in a better quality. The Swedish government has taken a decision to go from analog towards digital TV and the conversion is planned to be finished in 2008 [Internet academy, 2005].
The government’s decision to go from analogue to digital TV opens up a new market for the telecom operators when the customers change.The telecom operators will compete for the customers against the other distributors of digital TV. As mentioned before, IPTV has not yet been standardized and the network is designed to transport data traffic and not sensitive media traffic. These are disadvantages compared to digital TV, but some attempts are done called transport of DVB services over IP (DVB-IPI). There are also advantages with IPTV compared to digital TV. IPTV has, theoretically, unlimited amount of channel capacity because one channel, at the time, is received. This is a advantage compared with digital TV where all channels are delivered in a bundle, at the same time, to the receiver. This reduces the local access bandwidth demand. The new High Definition Television (HDTV) will give better picture quality and digital sound. The technique requires more bandwidth per channel and is
10 (80) 2. IPTV
therefore easier to adapt to IPTV systems since the channels are distributed individually. Traditional digital TV system transmits the channels bundled together [Internet academy, 2005].
At the same time as operators invest in IPTV, distributors of cable/digital TV are investing in both Internet and Telephony. These two markets are now merging into one with more competitors.
2.3 System components
An IPTV system is made up of four major elements:
Video head end Core/Distribution IP network Access network Home network
Figure 2-1 is a simplified model to get an overview of the elements that is involved in distributing IPTV.
Video head Core/Distribution IP network Access network Home network
Access Core network network TV Router/Switch Router/Switch Streaming Server
Figure 2-1 A simplified distribution model for IPTV [Broadband Services Forum, 2005].
At the video head end the TV content is received from a content provider through for example a satellite (see figure 2-2) and formatted for transmission over the network [Broadband Services Forum, 2005]. The channels are encoded into a digital video format, like MPEG-2 or MPEG-4, at the encoder and one Multiple Program Transport Stream (MPTS) consisting of several channels is sent over the asynchronous serial interface (ASI) to the IP streamer [Paulsen, 2003].
ASI, MPTS is Content transmitted to the provider IP streamer Receiver/Encoder
Streaming server Figure 2-2 Receiver to streaming server [Internet academy, 2005].
11 (80) 2. IPTV
ASI is not a video standard-based signal. It is only an interface, which means that it is the format for how the data is carried. It is often referred to as the digital video broadcasting- asynchronous serial interface (DVB-ASI) and is designed to transport MPEG-2 streams in today’s IPTV solutions. Figure 2-3 shows an example of four compressed program streams that are multiplexed into a 35 Mbps MPTS and transmitted from the ASI interface to a 270 Mbps link [Paulsen, 2003].
12 Mbps program MPEG-2 encoder
6 Mbps program MPEG-2 encoder 270 Mbps ASI carrier 35 Mbps MPTS ASI MUX INTERFACE 3 Mbps program MPEG-2 encoder
12 Mbps program MPEG-2 encoder
Figure 2-3 Example of a MPTS carried out of an ASI interface [Paulsen, 2003]
The MPTS stream reaches the IP streamer, which is in charge of separating the MPTS stream to individual Single Program Transport Streams (SPTS), one for each channel. The channels are then encapsulated into IP and sent out through the IP interface. These channels are often multicast streams (se figure 2-4), but may also be unicast. Multicast and unicast is described in chapter 3. The last device before the channels are transported out to the network is the Crypto gateway, where the channels are encrypted to increase the security [Internet academy, 2005].
These different channels are transmitted as A MPTS (ASI) that includes for individual channels belonging to unique multicast example SVT1, SVT2 and TV4 groups (SPTS)
Figure 2-4 IP streamer [Internet academy, 2005].
The encoded video streams are then transported over the service provider’s (in this case TDC Song’s) IP network. At the end of the distribution network, the IP network is connected to the access network, which is the link from the service provider to the individual household. Telecom providers are usually using Digital Subscriber Line (DSL) technology, see appendix A, to serve individual households and some have also started to use fiber. The home network
12 (80) 2. IPTV
distributes the IPTV service and at the end point, the set-top box (STB) is connected to the television set. In the STB, the channel is decrypted to be displayed on the TV.
It is easier for the service provider to ensure Quality of Service (QoS) for the consumers, because IPTV services often operate over a private network and not on the public Internet. This is an important factor to be able to offer the needed video quality [Broadband Services Forum, 2005]. QoS is described further in section 2.7. The focus of this thesis is on the core and access network of the model showed in figure 2-1.
2.4 Video compression
Video compression is accomplished by making use of the similarities or redundancies that exist in a video signal. An additional goal is to reduce the irrelevant data in the signal, which means that only the features that are important is coded. In this way valuable bits will not be wasted. A video sequence consists of a series of video frames or images. Each frame can be coded as a separate image, but because neighboring video frames are typically very similar, a higher compression can be achieved by using that similarity [Apostolopouos et al., 2002].
There exist some video compression standards that offer a number of benefits, like for example, interoperability between encoders and decoders made by different companies. The Moving Pictures Expert Group (MPEG) is a standard that was established by the International Organization for Standardization (ISO) in 1988. It was created to develop a standard for compressing moving pictures (video) and related audio. The first standard, MPEG-1, was finalized in 1991 and gives a Video Home System (VHS) quality video and audio at 1,5 Mbps. After further work an extension was released called MPEG-2. It was developed for applications toward digital television and is the compression standard used in this thesis. A third standard, MPEG-3 was originally developed for higher bit rate applications like HDTV, but it was acknowledged that those applications could be addressed into MPEG-2, so there exist no MPEG-3. The latest standard, MPEG-4, was designed to provide improved compression efficiency and error resilience features and will probably gain wide acceptance in the future [Apostolopouos et al., 2002].
The video compression is performed in two ways, movement and color. If a frame has fields with similar colours, the colours are replaced with one color and if a sequence of frames has very little movement the still parts are equal. A compressed video consists of three different frames (see figure 2-5) [Ydrenius, 2000].
13 (80) 2. IPTV
Figure 2-5 I-, P- and B-pictures and their predication reference [Ydrenius, 2000].
I-frames = real pictures, encoded independently of other frames. P- frames = predictive coded pictures, dependent on the previous picture (either I- or P-frame). B-frames = bidirectional pictures, resembles the P-frame but is independent on both the preceding and the succeeding I- or P-frame [Ydrenius, 2000].
When an IPTV user change a channel, an I-frame has to be received at the end-user before the whole video picture can be displayed. Therefore, the time it takes to change the channel (zapping) can never be less than the time between two I-frames in the stream. In most of the video streams, an I-frame is transmitted every other second [Internet academy, 2005].
The output bit-rate of an MPEG-2 encoder can be constant or variable. Most real-time MPEG-2 encoders are designed to execute in a constant-bit-rate (CBR) mode. These streams are often good-quality sequences. Many MPEG-2 encoding applications are real-time and the video signal has to be encoded with no significant look ahead. These applications are encoded with a constant bit rate. However, there exist non-real-time applications where the video sequence first can be analyzed and the results can be used to optimize the encoding process. One example is Digital Video Disk (DVD), which is encoded to a variable-bit-rate (VBR) output stream. This means that the MPEG-2 encoder can produce a video sequence with a constant visual quality over time. In test nine, both a CBR encoded MPEG-2 stream as well as a VBR encoded were transmitted. See chapter five and six for more information and results [Gonzales et al., 1999].
Today, MPEG-2 is the standard compression method for transmitting video, but the development of the new standard MPEG-4 is moving quickly and is expected to take MPEG- 2’s place as soon as the content providers approve the quality. MPEG-4’s main advantage is that it requires less bandwidth per channel.
2.5 Media Streaming Protocols and Standards
Above IP in the OSI model (described earlier in this chapter) reside the end-to-end transport protocols, where Transport Control Protocol (TCP) and User Datagram Protocol (UDP) are the most important [Apostolopouos et al., 2002]. Later in this section, the media delivery and the control protocols situated above the transport protocol are explained.
14 (80) 2. IPTV
2.5.1 Transport Control Protocol and User Datagram Protocol
The Transport Control Protocol (TCP) offers a reliable transport service, where it guarantees delivery via the use of retransmissions and acknowledgements. The User Datagram Protocol (UDP) on the other hand is only a user interface to IP, which means that it is unreliable and connectionless. It uses checksum and port numbering for demultiplexing traffic sent to the same destination [Apostolopouos et al., 2002].
According to (Apostolopoulos John, 2002), there are some differences between TCP and UDP that affects streaming applications: TCP operates on a byte stream while UDP is packet oriented. TCP delivery is guaranteed via retransmissions, but these retransmissions causes further delays. UDP does not guarantee delivery, but for the packets that are delivered the delay is less and easier to predict. TCP provides flow control and congestion control. UDP provides neither, which provides more flexibility for the application to determine the appropriate flow control and congestion control procedures. TCP requires a back channel for the acknowledgements. UDP does not require a back channel.
Web, e-mail and file transfers are in the most cases delivered using TCP/IP since guaranteed delivery is more important than delay or jitter (described in 2.6.1), but in the case of media streaming the uncontrolled delay of TCP is undesirable and IPTV is generally transmitted using UDP/IP [Apostolopouos et al., 2002].
2.5.2 Real-time Transport Protocol and Real-Time Control Protocol
The Internet Engineering Task Force (IETF) has developed the Real-time Transport protocol (RTP, RFC 1889) and Real-Time Control Protocol (RTCP, RFC 3550) to support the transmission of streaming media. These protocols provide the functionalities that support real- time services [Apostolopouos et al., 2002].
RTP was designed for real-time data transfer and does not guarantee QoS (see section 2.7) or reliable delivery. It offers support for applications with time constraints, like for example IPTV, by providing a standardized framework for time stamps, sequence numbering and payload specifications. The protocol can also detect lost packets [Apostolopouos et al., 2002]. The standard way for media streaming, determined by DVB-IPI, is to use RTP/UDP for the data and send the control messages using RTCP/TCP or RTCP/UDP. This standard is not widely used today in commercial systems. The companies use theit own unique solutions to distribute IPTV.
RTCP was developed for the control messages and provides feedback on quality of data delivery. The feedback includes for example number of lost packets, inter-arrival jitter (described in 2.6.1) and delay. RTCP sends periodic feedback packets at least every five seconds and uses only five percent of the total session bandwidth. For instance the source can use the information to adapt its bit rate [Apostolopouos et al., 2002].
RTP gives a transport layer for carrying the multimedia streams, but it does not specify how the data will be organized inside this transport layer. There exist two different solutions today.
15 (80) 2. IPTV
One is inherited from the previous digital broadcasting networks (satellite and cable). Video and audio is encapsulated into Transport Streams (TS). TS is defined in the MPEG-2 systems standard and gives synchronization, signaling and security. The proposed solution consists in encapsulating the TS packets into RTP packets like in an old digital broadcasting network. Present equipment deployed for IPTV, coming from the satellite or cable world using TS encapsulation, decreases the initial costs of deployment. But it also brings an additional overhead to the network, lacks flexibility and scalability (all the information for a stream must be presented in the same TS, for example it would be difficult to have multiple audio tracks for a single movie).
The other solution, which is relatively new, consists in encapsulating the video data directly inside the RTP packet without TS. It consumes less bandwidth, permitting more flexibility and scalability. The disadvantage may be that it requires changes in broadcasting equipment. Both approaches are available and satisfactory. The Digital Video Broadcasting (DVB) forum has issued a standard for the first solution with TS and the Internet Streaming Media Alliance (ISMA) has issued specifications for the other approach without TS [Fleury, 2005].
2.5.3 Real-Time Streaming Protocol and Session Initiation Protocol
There are two session control protocols, Real-time Streaming Protocol (RTSP, RFC 2326) and Session Initiation Protocol (SIP RFC 3261). RTSP is often used for video streaming to establish a session and it supports VCR functions like play, pause and record. It is generally used for sessions in Video on Demand (VoD) systems and most of the VoD servers support RTSP today. SIP is more commonly applied for Voice over IP (VoIP) [Apostolopouos et al., 2002].
2.5.4 Session Description Protocol
The Session Description Protocol (SDP, RFC 2327) provides information describing a session. The information can for example explain whether it is a video or audio, the specific codec and bit rate. SDP is often used by RTSP for content description and it is also used with the Session Announcement Protocol (SAP, RFC 2974) to announce the availability of multicast programs [Apostolopouos et al., 2002].
2.6 Quality of Service
The demands that exists on a complete IPTV solution is according to Internet Academy 2005): End-to-end quality of service Effective use of bandwidth High availability Short time for changing channels (zapping) Authentication Conditional Access Protection against trespassing
16 (80) 2. IPTV
Quality of Service and effective use of bandwidth, displayed in the list above, are relevant for this thesis, because the focus lies on the network and not on the entire IPTV solution. Some might also consider zapping to be a matter of the network, however since the zapping time depends on how often an I-frame is transmitted rather than on the delay in the network, it will not be included in this master thesis (see video compression 2.4). It might be possible to implement a solution where a I-frame is transmitted independently of the multicast stream. This might change the users opinion of the zapping time because the user receives a standard picture when they push on the remote control instead of a black screen.
The distributor of IPTV has to know the end consumers vision of quality, which means that IPTV should have a good picture- and sound-quality, be user-friendly and have short response times. This suggests that the telecom provider should: Receive the TV content from the content provider with good quality Have flawless coding Have flawless transmission on the IP network [Internet Academy, 2005]
This means for the network provider that parameters like jitter, packet loss and bandwidth is quality parameters that should be controlled for a flawless transmission. That is one of the challenges with IPTV since the Internet Protocol is a best-effort service with no guarantees considering jitter, packet losses or bandwidth. These characteristics are unknown and time varying [Apostolopouos et al., 2002].
2.6.1 Jitter
Packets may experience different end-to-end delays when they are transmitted between identical end-hosts, referred to as jitter. The reason why this is a problem is because the receiver must receive, decode and display frames at a constant rate. Late frames due to jitter can be useless and cause problems in the reconstructed video in form of jerks, which leads to an unacceptable quality [Apostolopouos et al., 2002].
To address this problem it is common to have a few seconds buffer at the end-user before playback starts. The buffer gives some important advantages. It successfully extends the presentation deadlines for the media samples and can therefore almost eliminate playback jerkiness caused by delay jitter. The extended deadline also allows for error recovery through retransmissions and because video is sensitive to errors this can greatly improve the quality. The extra time can also be used to cover up errors using interleaving and error correcting codes. Like everything else the buffer also comes with a cost, it requires more storage space and additional delay before playback can start when for example a user have changed to another channel. Therefore, it is important to consider how large the buffer should be. It is a balance between eliminating jitter jerkiness without increasing the delay too much [Apostolopouos et al., 2002].
Internet Academy (2005) illustrated an example where they generated a TV-channel with different levels of jitter, transmitted through a STB and displayed it on a TV-set. The levels of jitter where: 1. 0.01 s 2. 0.1 s 3. 0.5 s 4. 1.0 s
17 (80) 2. IPTV
In example one and two the jitter could be eliminated with the help of the buffer and had no affect on the TV picture. In example three and four the picture suffered from a little jerkiness, but it was not disturbing and disappeared quickly. Today, TDC Song delivers VoIP as a service and it has a jitter tolerance range of 0,02 - 0,03 second. This implies that VoIP is more sensitive to jitter compared to IPTV, because IPTV with the help of a buffer, can have jitter up to 0,1 second with good picture quality. Since the company has assured that the network can handle the jitter requirements for VoIP service with good quality, IPTV should not be a problem [Apostolopouos et al., 2002].
2.6.2 Packet loss
Wired packet networks like TDC Song’s are afflicted by packet loss in the sense that an entire packet is erased and these losses can have a very destructive effect on the video quality. These losses are often situated in the access network where many services uses the limited bandwidth and not in the core where the bandwidth is higher.
Internet Academy (2005) illustrated an example where they generated a TV-channel with different levels of packet loss, transmitted throw a STB and displayed it on a TV-set. The levels of packet loss where: 1. 0.01 % 2. 0.1 % 3. 0.5 % 4. 1.0 %
Already in example one, where the packet loss was only 0.01 percent, the disturbance from the packet loss where visual in small areas of pixels that displayed wrong colours and the picture had an unacceptable quality. In example two the areas just grew in size and returned more frequently. For example three and four, the picture was totally blurry and unusable.
The DVB-IPI believes that an end customer should have maximum one visible fault per hour. To further understand what that demand means, consider a typical TV channel that transmits 500 packets/second and one lost packet gives a visible fault [Internet Academy, 2005].
500 packets · 3600 seconds = 1 800 000 packets per hour.
If the company delivers 40 channels then only one packet in 72 million is allowed to disappear. This example also shows how important it is to have a network of good quality with almost no packet loss.
To eliminate these effects the network is designed with error control. There are four classes for error control: retransmission, forward error correction (FEC), error concealment and error-resilient video coding [Apostolopouos et al., 2002].
Retransmission involves the use of a back channel to inform the sender of which of the packets were received correctly and which should be retransmitted. This approach uses the available bandwidth effectively but the additional delay is often not acceptable when it comes to streaming video. There are some schemes to address this problem. Delay-constrained scheme, where packets are only retransmitted if they can arrive before their deadline, or priority-based where important packets are sent before less important. With these approaches
18 (80) 2. IPTV
scheduling problems appear, concerning which packet should be transmitted next, and additional delay that is not appropriate for real time services like IPTV [Apostolopouos et al., 2002].
In FEC, specialized redundancy is added to recover from errors. If the source transmits N packets where K packets are data and N-K packets are redundant packets. For certain codes, provided that any K of the N packets is correctly received, the original data can be recovered, but on the other hand FEC increases the necessary bandwidth with a factor of N/K. FEC does not require a back-channel and might give a lower delay, but there are some disadvantages too, like the overhead data that is present even when there are no losses and the latency related with the reconstruction of the packets [Apostolopouos et al., 2002].
When it comes to error concealment, the goal is to estimate the lost information in order to conceal the error. Video has a correlation along the spatial and temporal dimensions, which is used for video compression. If the correlation is unexploited it can be used to estimate the lost information by using the correlation and perform some form of spatial or temporal interpolation. In a packet switched network the entire packet is either lost or received correctly, hence spatial interpolation can’t be used because there is no spatial information left (all the pixels in the frame are lost). So only temporal information can be used and in the most cases the lost frame is estimated as the last correctly received frame causing the picture to freeze momentarily [Apostolopouos et al., 2002].
Error resilient video coding designs the video compression algorithm and the compressed bit stream to be resilient to specific sorts of errors. One problem is the loss of bit stream synchronization and refers to the case when an error causes the decoder to lose track of what bits correspond to what parameter. To overcome this problem, the solution is to provide mechanisms that enable the decoder to quickly isolate the problem and resynchronize to the bit stream. The simplest approach is to use resync markers. Unique and easy to find entry points are placed in the bit stream, therefore if the decoder loses sync, it can look for the next entry point and start again after that point. The resync marker can be placed in different ways. In MPEG-1 and MPEG-2, the markers are placed at strategic locations in the compressed video hierarchy, for example in picture and slice headers. This means that resyncs are placed every fixed number of blocks. MPEG-4 instead provides the capability to place the resync markers periodically after fixed number of bits [Apostolopouos et al., 2002].
Losses in a packet network like TDC Song’s have an important structure that can be exploited. Either a packet is correctly received or it is discarded, which means that the boundaries for lost information are exactly determined by the packet boundaries. This has led to the design of a packet payload to minimize the effect of the losses. The idea is called Application Level Framing (ALF) and MPEG-4 supports it [Apostolopouos et al., 2002].
To prevent packet losses the network can be implemented with traffic isolation and priority to provide QoS. The video can be coded into different layers, one base layer and one or more enhancement layers. This method is called scalable coding and prioritizes the video data and supports intelligent discarding of the data. For example, the enhancement data can be lost or discarded while still maintaining usable video quality. The different prioritizes can be exploited to enable reliable video delivery by the use of unequal error protection (UEP). It protects important information more than data that can be lost without affecting the video. Therefore, scalable coding is a good match for networks, which support different qualities of service [Apostolopouos et al., 2002].
19 (80) 2. IPTV
2.6.3 Bandwidth
The available bandwidth between two points in the network can vary in time, depending on the load on the network. If the sender transmits faster than the available bandwidth congestion may occur, which leads to packet loss and the quality of the video decreases. On the other hand if the sender transmits slower, the receiver produces sub-optimal video quality [Apostolopouos et al., 2002].
Congestion is rather common in communication networks and happens when the traffic load exceeds the designed limit of the network. It may lead to decreased throughput, packet losses, higher delay and jitter, which all have a negative effect on the video quality. One way to deal with this problem is to increase the bandwidth in the network, but that investment is very expensive so it is more of an ongoing process than a solution. Another method is to implement traffic isolation so that packets that are more important, for example VoIP and IPTV, has priority in the routers and will travel through the network faster and thus with a reduced amount of lost packets. This will be at the cost of less important packets like web browsing on the Internet. There has been some work done to provide QoS support to face these difficulties with streaming media [Apostolopouos et al., 2002].
2.6.4 Traffic isolation
Traffic isolation permits the service provider to offer different classes of quality service to their customers. Today, two main methods are used depending on the type of network service. The most common and simplest service is Layer 2 Ethernet transport, which means that the service provider offers Ethernet as the transport and doesn’t have to test for higher protocols. To provide priority, Virtual Local Area Network (VLAN) tagging is used. If the service provider offers services up to layer 3 (IP) Type of Services (TOS) or Differentiated Services Code Points (DSCP) are used for priority. This is more complex, because layer 3 services involves more parameters that need to be configured, like for example a firewall. [Demyttenaere and Legault, 2005].
To provide priority on layer 2, the Institute of Electrical and Electronics Engineers (IEEE) has developed the 802.1 Q/p. It allows a service provider to attach special tags (VLAN IDs) to all the incoming frames. Therefore, the service provider can have many customers that use the same physical circuit, while still maintaining a logical separation between them. The priority field in the VLAN tag is used for priority and by using this field, the service provider can offer different classes of quality to their customers. The IEEE VLAN standard (802.1 Q/p) consists of adding 4 bytes to the Ethernet frame, see figure 2-6. The first two bytes are the type protocol identifier and identifies the frame as a tagged frame. The other two bytes are the VLAN tag and identifies the frame as belonging to a specific group on the network. When the frames go through the Ethernet network, the different switches on the path will read the VLAN tag and determine where the frame should be delivered. The first three bits in the VLAN tag identify the priority of the frame [Demyttenaere and Legault, 2005].
20 (80) 2. IPTV
Figure 2-6 One Ethernet frame and one IEEE 8021p/Q tagged frame [Demyttenaere and Legault, 2005].
Currently, two standards exist to provide priority on layer 3 and as mentioned they are called TOS (RFC 791) and DSCP (RFC 2475). These standards use the same field in the IP packet header to identify the level of service for the packet. ToS was the original standard but it is often replaced by DSCP, because it offers more flexibility in configuring different QoS parameters for customers [Demyttenaere and Legault, 2005].
The Type of Service (TOS) field is an 8-bit field in the IP datagram, see figure 2-7. The first three bits are the Predence field that prioritizes packets within a queue. Packets with the highest priority value are transmitted first. The other five fields, delay, throughput, reliability, cost and future, also act as routing criteria [Demyttenaere and Legault, 2005].
Differentiated service (Diffserv) is a model in which traffic is treated with relative priorities based on the same ToS field in the IP datagram. Diffserv increases the number of definable priority levels by reallocating bits of an IP packet for priority marking. The first six bits of the ToS field are defined as the DSCP and there exist a number of class models for DSCP values explained in RFC 2697, RFC 2698 and RFC 2598. The last two bits in the ToS field are not used for QoS. Instead, the ECN field is used for explicit congestion notification (RFC 3168) [Demyttenaere and Legault, 2005].
Figure 2-7 The Type of Service field and the Differentiated Services Code Point
21 (80) 2. IPTV
2.6.5 Scheduling and policing
When the traffic is isolated from each other through traffic isolation, scheduling and policing are applied to provide QoS in the networks are scheduling and policing. Scheduling is concerned with which packet will be transmitted next onto a link. When packets belonging to different network flows reach a router, they are multiplexed and queued for transmission at the output buffers connected with a link. The way that the queued packets are selected for transmission on the link is called the link-scheduling discipline and the most important ones are First-In-First-Out (FIFO), priority queuing, round robin queuing and weighted fair queuing [Kurose and Ross, 2005].
Figure 2-8 displays a FIFO queue in operation. Packets arrive at the link output queue and wait if the link is busy transmitting another packet. If there is not enough buffering space in the queue to hold the arriving packet, the queue’s packet-discarding policy decides if the packet is dropped (lost) or if another packet should be removed from the queue to make space for the arriving packet. FIFO selects to send the packets in the same order as they were received [Kurose and Ross, 2005].
Figure 2-8 FIFO queue [Kurose and Ross, 2005].
In priority queuing the different packets arriving at the output link are classified into priority classes at the output queue, see figure 2-9 with two priority classes. The packets priority can depend on a marking either carried in its packet header, its source or destination IP address, its destination port number or some other criteria. In figure 2-9, packet 1 arrives and because the link is idle it gets transmitted directly. During the transmission, packets 2 and 3 arrive and are queued into low- and high-priority queues. When packet 1 is transmitted, packet 3 (high- priority) is selected for transmission over packet 2 (low-priority). At the time when packet 2 is transmitted, packet 4 (high-priority) arrives, but once a transmission of a packet has begun it is not interrupted so packet 4 has to queue [Kurose and Ross, 2005].
Figure 2-9 Priority queue [Kurose and Ross, 2005].
22 (80) 2. IPTV
The round robin queuing discipline also sorts packets into classes with priority queuing, but instead of having a strict priority of service among classes, a round robin scheduler alternates service among the classes. The simplest form with two priority classes transmits first a class 1 packet, then a class 2 packet, then again a class 1 packet and so on (see figure 2-10) [Kurose and Ross, 2005].
Figure 2-10 Two-class round robin queue [Kurose and Ross, 2005].
Another concept of round robin queuing is Weighted Fair Queuing (WFQ) showed in figure 2-11. Arriving packets are classified and queued in respective right queue depending on service. The feature that differs WFQ from round robin is that each class may have a different amount of service in any interval of time. Each class i is given a weight wi . During any interval of time as long as there are class i packets to transmit, class i will be guaranteed to receive a fraction of the bandwidth equal to:
wi / ∑ w j
Where the sum is taken for all classes that also have packets queued for transmission. For a link with a transmission rate R, class i will always have a throughput of at least:
⋅ R wi / ∑ w j
Figure 2-11 Weighted fair queuing [Kurose and Ross, 2005].
The other mechanism for QoS is policing, it handles the regulation of the rate at which a flow is permitted to insert packets into the network. There exist three policing criteria: average rate, peak rate and burst size [Kurose and Ross, 2005].
23 (80) 2. IPTV
Average rate gives the network a change to limit the long-term average rate (packets per interval) at which a flow’s packets can be sent. The critical matter in average rate is the interval of time over which the average rate will be policed. For example is an average rate of 100 packets per second more constrained than 6000 packets per minute, even though both have the same average rate over a long enough interval of time. This is because the second constraint could allow a flow to send 1000 packets in a given second-long interval (as long as it don’t send more than 6000 packets per minute), while the first cannot have that behaviour [Kurose and Ross, 2005].
Peak rate limits the maximum number of packets that can be transmitted over a shorter amount of time. From the example described above, the network may police the average rate to 6000 packets per minute, while restricting the flow’s peak rate to 1500 packets per second. The network might also want to limit the maximum number of packets, the burst of packets, which can be transmitted over a very short interval of time. That is called burst size. The burst size restricts the number of packets that can be sent into the network at the same time as the interval length approaches zero [Kurose and Ross, 2005].
The leaky bucket is an example that can be used to explain these policing limits. Figure 2-12 shows a leaky bucket with a bucket that can hold up to b tokens (regulates the burst size). New tokens are generated at a rate of r tokens per second (limits the average rate at which packets can enter the network). If the bucket has less than b tokens new token is added and otherwise it is discarded. A packet must first remove a token from the bucket before it is sent onto the network. If the bucket is empty, the packet will either wait for a token or it can also be dropped. To regulate the peak rate, two buckets are needed [Kurose and Ross, 2005].
Figure 2-12 Leaky bucket [Kurose and Ross, 2005].
24 (80)
3 Multicast
Users on the network can communicate in different ways like unicast, broadcast or multicast. In unicast communication packets are transmitted to one receiver. Therefore, in the IPTV case, one individual stream would be transmitted to every end-user that wants to watch TV, regardless of where they are located in the network. This mean that packets with the same content might travel on the same links several times consuming unnecessary amount of bandwidth. Broadcast communication is a one-to-all transmission, where the packets are sent to all nodes on the network. This is also not an efficient way since some parts of the network might not want to have the IPTV stream [Forouzan, 2003].
Multicast is a communication form that consists of a one-to-many transmission. The sender transmits the packets to a multicast IP address that users, which want to receive the packets, have to join. This eliminates that duplicate packets travels on the same link and restricts the stream to network segments that want to receive it. That is why multicast is the communication technique that has been chosen for IPTV and it will be described closer in the following chapter. Figure 3-1 shows the different protocols that can be used for multicast transmission to deliver the IP packets [Forouzan, 2003].
Multicast Source BR MSDP RP MBGP, DR RP BGMP Core IGMP BR Distribution Snooping, CGMP DR D R IGMP DR DVMRP
MOSPF DR PIM-DM PIM-SM CBT
Figure 3-1 Overview of the different parts in a multicast solution [Cisco Systems, 2003].
There are two problems that arise when using multicast communication, the first is how to identify the receivers of the multicast packet and the second is how to address the packet to these receivers. In unicast communication the network use the IP address of the receiver to deliver the packet to the correct destination. In broadcast, the packet is delivered to all nodes, no destination address is needed [Kurose and Ross, 2005].
In the case of multicast there are multiple receivers. One alternative is to have the multicast packets carry all the IP addresses of the receivers. That might work with a small number of receivers, but it would not scale well if a group consisted of hundreds or thousands users because the amount of addressing information would be more than the actual data.
25 (80) 3. Multicast
Furthermore, it requires that the sender know the identities and addresses of all the receivers and in some cases this requirement might be undesirable [Kurose and Ross, 2005].
To go around these drawbacks a multicast packet is addressed using address indirection, which means that a single identifier is used for the group of receivers. The packet is copied and delivered to all the multicast receivers related with that group. The IP address used is a class D multicast address and the group of receivers connected with a class D address is called a multicast group [Kurose and Ross, 2005].
It is quite simple to understand the concept of the multicast group, but it raises a lot of questions and some of them are mentioned in Kurose and Ross (2005):
How does a group get started and how does it terminate? How is the group address chosen? How are new hosts added? Can anyone join the group or is membership restricted? Do group members know the identities of other group members? How do the network nodes interoperate with each other to deliver a multicast packet to all group members?
The answers to all these questions involve the Internet Group Management Protocol (IGMP).
3.1 Internet Group Management Protocol
The Internet Group Management Protocol (IGMP) defines how to join or leave multicast groups and provides information about existing groups. The function of the protocol is to operate between the host and its directly attached router, see figure 3-2 [Kurose and Ross, 2005]. IGMP supplies the ways for a host to inform its attached router that an application, for example IPTV, running on the host wants to join a specific group by sending a Host Membership Report message. Each group represents in this case one TV channel [Kurose and Ross, 2005]. IGMP is today the most common used protocol for switching channels according to Broadband Services Forum (2005).
Figure 3-2 IGMP Query and report sent between the end-host and the attached router [Kurose and Ross, 2005].
26 (80) 3. Multicast
3.1.1 IGMPv1
IGMPv1 is defined in RFC1112 and figure 3-3 displays the message format.
Figure 3-3 IGMPv1 message format [Zheng, 2001].
The version field in the message corresponds to the version of the protocol, in this case version one. The type field can consist of two different types of messages: Type 1, Host Membership Query (sent by multicast routers) Type 2, Host Membership Report (sent by hosts) [Zheng, 2001].
The unused field must be set to zero and the checksum field includes the checksum for the IGMP message. Hosts use the group address field to report their membership in a specific multicast group and in a query message, the field is all zeros and means nothing [Zheng, 2001].
The multicast router transmits Host Membership Query messages periodically to decide which hosts groups have members on its directly attached networks. The Time-To-Live (TTL) field is set to one so other multicast routers do not forward the message. When a host receives a Query message it responds by transmitting a Host Membership Report for each group to which it belongs. Host Membership Reports suppress redundant messages by using a random back-off timer. The host suppress its response and resets the timer to a new random value, if a host hears another Report for the same group during the timeout period. A multicast router does not need to know the number of members in a group, only that one exits. This leads to a reduced amount of traffic on the subnetwork [Zheng, 2001].
When a host wants to join a group it immediately transmits a Report for the group instead of waiting for a query message and if a member wants to leave a group it simply stops responding to the query messages. This means that the leaving process is only determined by a timeout, which leads to a long delay. The timeout for a router that uses IGMPv1 is usually 3 times the polling interval (the time interval between two Host Membership Query messages). Even if the hosts on the subnetwork have left the group, the router will keep on forwarding the data. If there existed a leave group message to inform the router that members are leaving, the leaving delay could be reduced. IGMPv2 was developed to address this problem [Zheng, 2001].
3.1.2 IGMPv2
IGMPv2 (RFC 2236) improves IGMPv1 and is backward compatible at the same time. The message format for IGMPv2 is displayed in figure 3-4. The version field and type field from IGMPv1 are combined into one type field. Some examples of different types are shown in table 3-1. The checksum and Group Address are the same as in IGMPv1.
27 (80) 3. Multicast
Figure 3-4 GMPv2 message format [Zheng, 2001].
Type Ox11 (Group Address is zero) General membership query Type Ox11 (Group Address ≠ zero) Specific group membership query Type Ox16 Membership report Type Ox17 Leave group Type Ox12 Membership report (IGMPv1) Table 3-1 Type numbers for different types of messages sent in IGMPv2 [Zheng, 2001].
There are some differences between IGMPv1 and IGMPv2: IGMPv2 has an explicit leave message that can reduce the delay. The host sends a leave message to the all routers group address, 224.0.0.2. The designated router responds with a Group-Specific Query message to the subnet where the leave message came from and if no Host List Report is generated as a response the subnet is removed. IGMPv2 includes a new Group-Specific Query message that the router uses to send query messages to a specific multicast group rather than to all groups on the subnet as in IGMPv1. When there is several routers on the same subnet, the one with the lowest IP address is automatically selected to be multicast querier, responsible for sending the Host Membership Query messages. In IGMPv1 it is the multicast routing protocol that decides the querier [Zheng, 2001].
3.1.3 IGMPv3
The main improvement with IGMPv3 (RFC 3376) is that it has support for Group-Source Report messages, which means that a host can select to receive traffic from a specific source of a multicast group. This makes it possible for receivers to control which source is allowed to send to them. There are two types of Group-Source Report. Inclusion Group-Source Report, where the host can specify the IP address of the specific sources it wants to receive data from and Exclusion Group-Source Report that specifies the IP addresses of the sources that the host does not want to receive data from. In IGMPv1 and IGMPv2 is the information from all sources for that group forwarded to the subnetwork when a host joins a multicast group. By selecting sources in IGMPv3, the multicast protocols get some help to conserve bandwidth by not constructing unwanted branches in the multicast tree. The Leave-Group message in IGMPv2 has also been modified to allow a host to specify the IP address of any source-group it wishes to leave [Zheng, 2001].
Today, IGMPv2 is the version that is most commonly used, but most experts believe that IGMPv3 will replace it in the future.
28 (80) 3. Multicast
3.2 Multicast Routing algorithms
IGMP defines how hosts communicate with their designated router, but it does not state how to deliver the multicast traffic between the routers, how the routers exchange membership information or how they make a copy of every data unit to arrive to all group members. That is done by multicast routing protocols. They are in charge of constructing the multicast delivery trees and performing multicast packet forwarding. This part describes the routing algorithms that are applied in multicast routing protocols [Zheng, 2001].
3.2.1 Flooding
Flooding is the simplest algorithm, when a router receives a packet it just forwards it to all interfaces except the one, which it was received from. The router has no routing table to uphold and the algorithm is uncomplicated to implement, but there are some disadvantages. It is very inefficient and not scalable, because it produces many duplicate packets and uses all available paths along the network. To avoid that packets are circling around for an eternity the algorithm uses the TTL (time-to-live) field. Whenever a packet pass a router the TTL field is decreased by one and when it reaches zero the packet is thrown away [Zheng, 2001].
3.2.2 Multicast distribution trees
To be able to understand IP multicast it is important to have knowledge about multicast distribution trees. In unicast, traffic is routed through the network along a single path from the source to the destination, but when it comes to multicast, the source is transmitting to a changing group of hosts represented by a multicast address. Multicast distribution trees are used to describe the path that the multicast traffic flows through the network to reach all receivers. There are two kinds of multicast trees, source trees and shared trees [Williamson, 2000].
The source tree is the simplest form of distribution tree. The source of the multicast traffic is the root, which branches form a spanning tree through the network to the end-users. This tree applies the shortest path through the network and is therefore also known as a shortest path tree (SPT). In the spanning tree algorithm there are only one active path between two routers. Once the spanning tree has been set up, the packets can travel along the tree and reach all end hosts. One problem with the spanning tree is that it concentrates traffic on the root paths of the tree, which can cause a bottleneck in the case of high traffic. Spanning tree is an improvement over flooding since it stops uncontrolled multiple forwarding of packets throw the network [Williamson, 2000].
Figure 3-5 displays an SPT for multicast group 224.1.1.1 with the root at the source (Host A). Two receivers are placed at Host B and Host C. The notation (S, G) that is written in the picture specifies a SPT where S is the IP address of the source and G is the multicast address of the group. There exist a separate SPT for every individual source transmitting to each group [Williamson, 2000].
29 (80) 3. Multicast
Figure 3-5 Shortest Path Tree (SPT) from Host A. (S, G) = (192.1.1.1, 224.1.1.1) [Williamson, 2000].
Shared trees are different from source trees that have their root at the source. They use a single root located at a selected point in the network. The root is called Rendezvous Point (RP) or Core depending on the multicast routing protocol. In a shared tree, sources must send its traffic to the root for the traffic to reach all the end-users. Shared trees can be divided into two sorts, bidirectional and unidirectional. In the case of a bidirectional tree, the traffic can flow up and down the tree to reach all end-users. In figure 3-6 the packets, from Host B, flows both up the tree to the root (router D) and down the tree to Host A [Williamson, 2000].
Figure 3-6 Bidirectional shared tree [Williamson, 2000].
Unidirectional-shared trees only let multicast traffic to flow down the shared tree from the root to the end-users. This means that the source needs a way to get the traffic to the root to be forwarded down the tree. One technique is that the root joins a SPT rooted at the source to drag the traffic to the root. This is displayed in figure 3-7. The root has joined a SPT to Host B and drags the traffic down (dashed arrows), which will then be forwarded to the other receivers (solid arrows). Protocol Independent Multicast (PIM), described later in 3.3.3, uses this method. Another way of forwarding the traffic from the source to the root is for the first- hop router to unicast the traffic directly to the root. The CBT multicast routing protocol uses this technique [Williamson, 2000].
30 (80) 3. Multicast
Figure 3-7 Unidirectional shared tree with SPT to get the traffic to the root [Williamson, 2000].
3.2.3 Reverse Path Forwarding
Almost every IP multicast routing protocol applies some form of Reverse Path Forwarding (RPF) or incoming interface check to decide whether to forward or drop an incoming multicast packet [Williamson, 2000]. The multicast router must include a routing table with the shortest path to all destinations. The RPF algorithm uses the packet source address to avoid data from traveling around in loops [Zheng, 2001]. Once a packet arrives at the router, it examines the source address to establish whether the packet arrived from an interface that is on the reverse path back to the source. If this is the case, the RPF check is successful and the packet is forwarded, otherwise it is discarded. Figures 3-8 and 3-9 describe two examples. In figure 3-8 the multicast packet from source 151.10.3.21 is received on interface S0 and when the router check the multicast routing table, the reverse path back to the source is S1, not S0, so the RPF check fails and the packet is discarded. In figure 3-9 the RPF check is a success cause the packet is received on interface S1 and the packet is forwarded to all the other interfaces on the outgoing interface list, which does not have to be all interfaces on the router [Williamson, 2000].
Figure 3-8 RPF Check fails [Williamson, 2000]. Figure 3-9 RPF Check succeeds [Williamson, 2000].
31 (80) 3. Multicast
3.3 Multicast Routing Protocols
Routing protocols are applied to get optimized routes from the source to the end-users in a multicast group [Williamson, 2000]. The five most common are described in the sections 3.3.1 to 3.3.5.
3.3.1 Distance Vector Multicast Routing Protocol
The first multicast routing protocol used in the Internet was the Distance Vector Multicast Routing Protocol (DVMRP, RFC 1075). It applies source-based trees with reverse path forwarding and pruning. Each router computes the next hop on its shortest path back to each possible source with the help of a distance vector algorithm [Kurose and Ross, 2005].
Neighbor Discovery is important in DVMRP because DVMRP routers must maintain a database of DVMRP neighbours. This is especially significant when the protocol is operating over multi-access networks like Ethernet and FDDI since the network can have many DVMRP routers. To do this, DVMRP Probe messages are periodically transmitted to the All DVMRP Router group address (224.0.0.4) [Williamson, 2000].
Source network routing information is exchanged periodically every 60 seconds by sending a Route Report between DVMRP Neighbors. The Route Report includes entries that announce a source network and a hop-count that is used as a routing metric. The routing information stored in the routing table is used to build the source distribution tree and to perform multicast forwarding (RPF checks). The source distribution trees are built by the DVMRP routers from truncated broadcast trees based on the metrics in the routers DVMRP route tables. The routers signal their upstream router (the neighbor with the best metric to a source network) that they are downstream to be able to build a truncated broadcast tree. Truncated broadcast is the distribution tree that is applied to deliver multicast traffic from a specific source network to all other locations on the network whether or not there exist any group members. A source starts to transmit and the multicast data is flooded down the tree to all points of the network and the DVMRP routers need to prune the traffic if the data is unwanted. To prevent multicast loops, the routers use RPF check [Williamson, 2000].
Truncated broadcast trees are built even if there exist no active receiver on the distribution tree and DVMRP implements a Flood-and-Prune mechanism to deliver the traffic to all routers in the network. To protect network resources, the leaf routers without any directly connected receivers transmits Prune messages up the tree to stop the flow of unwanted traffic, which leads to a SPT. The big disadvantage of DVMRP is that the source distribution tree that came from pruning goes back to a truncated broadcast tree as soon as the Prunes has timed out (normally after two minutes) and the unwanted traffic is flooded down the truncated tree again [Williamson, 2000]. DVMRP is therefore not a suitable multicast protocol to use for IPTV.
32 (80) 3. Multicast
3.3.2 Multicast Open Shortest Path First
Multicast Open Shortest Path First (MOSPF, RFC 1584) is a multicast extension of the link- state unicast routing protocol OSPF. The protocol permits multicast traffic to be forwarded within an OSPF unicast network using shortest path trees (SPTs). All routers in the OSPF network must not be operating MOSPF for multicast packets to be forwarded. The routers that are configured to work as MOSPF routers perform multicast routing in addition to performing OSPF routing [Williamson, 2000].
The main addition to the OSPF data format to support multicast was the definition of a new link-state advertisement (LSA) that is implemented to flood information about group membership throughout the network. Every group membership LSA includes the multicast group address (link-state ID), the advertising router ID and a list of router interfaces (identified by IP addresses) that have members for this group [Williamson, 2000].
When the databases in all area routers have been synchronized, the combination of group membership LSAs along with router and network LSAs provide each MOSPF router with enough information to construct SPTs for all (source, group) pair within the area. The router uses a Dijkstra algorithm to construct these single multicast SPT that has the root at the source-network, see figure 3-10 [Williamson, 2000].
Figure 3-10 MOSPF SPTs for networks N3 and N4 [Williamson, 2000].
These SPTs are applied for delivering multicast traffic inside the area as long as the group membership information remains static. If there are changes to the group membership or if the network topology changes (perhaps a link goes down), the SPTs must be recalculated with the Dijkstra algorithm [Williamson, 2000].
The biggest advantage to MOSPF is according to Williamson (2000) that it shares OSPF’s capability to respond rapidly to changes in network topology because it uses link-state routing methods to compute multicast distribution trees. This capability, on the other hand, comes at
33 (80) 3. Multicast
the cost of rapidly increasing router CPU resources as the numbers of source-networks increase. This means that highly dynamic networks, where group membership and/or the network topology changes frequently, suffer from an increased number of Dijkstra computations required to reconstructing the SPTs. So MOSPF is most likely best suited in networks where the network administrators have absolute control over factors like location of the sources, number of sources, number of groups and group membership [Williamson, 2000].
Since this is not the case in IPTV, the administrator cannot for example know when a customer wants to turn on the TV and join a specific group, therefore MOSPF is not suitable for distributing IPTV.
3.3.3 Protocol Independent Multicast - Dense mode
Protocol Independent Multicast (PIM) is, as the name relveals, IP routing protocol independent. This means that it does not matter which unicast routing protocol is used to fill the unicast routing table. PIM simply uses the available information to perform the RPF check function instead of having a separate multicast route table. PIM does not send or receive multicast route updates like other protocols, because it does not have its own routing table, which makes its overhead considerable reduced [Williamson, 2000].
PIM uses, like DVMRP, a Neighbor Discovery technique to find PIM neighbors. To establish this, a PIM multicast router multicasts a PIM Hello message (every 30 seconds) to the All- PIM-Routers (224.0.0.13) multicast address on every multicast-enabled interface. The PIM Hello message include a Holdtime value (often 90 seconds) that lets the receiver know when to end the neighbor adjacency associated with the sender if no further PIM Hello messages are received. The messages are also used to select the Designated Router (DR) for a multi- access network by remembering the router on the network with the highest IP address. This PIM router becomes the Designated Router for the network [Williamson, 2000].
PIM-Dense Mode (PIM-DM, RFC 3973) is a dense-mode protocol that uses shortest path trees (SPTs) to deliver the multicast traffic to the receivers in the network. These trees are built, as soon as a multicast source starts to transmit, by using a flood-and-prune mechanism. Instead of doing like DVMRP, which uses it own multicast routing table and a Poison Reverse mechanism to primarily construct a spanning distribution tree, PIM-DM uses the PIM Neighbor information to construct a similar source distribution tree [Williamson, 2000].
In the beginning, the neighbors are considered to be on the SPT with the incoming interface in the direction of the source (based on the unicast routing table) and all the other PIM-DM neighbors are downstream from this source. This first SPT is called a Broadcast Tree because the router transmits the traffic to all neighbors similar to a broadcast, see figure 3-11 [Williamson, 2000].
34 (80) 3. Multicast
Figure 3-11 PIM-DM distribution tree (initial flooding) [Williamson, 2005].
In figure 3-11, the source is transmitting through Router A and B and the traffic is flooded to their downstream PIM-DM neighbors Routers C and D. This figure shows the initial flow before any pruning on redundant paths have taken place, like the two incoming paths to Router C. The tree becomes a minimal spanning tree of all PIM-DM routers as soon as the pruning has been performed. Once a PIM-DM router has received a multicast packet, the packet is RPF checked by using the information in the unicast routing table. If the check is successful, the packet is forwarded [Williamson, 2000].
The figures below displays how PIM-DM sends prune messages to erase redundant paths. In figure 3-12 Router C transmits a Prune message to Router B because traffic is arriving on the non-RPF interface for the source (assumed that the link A-C is better then the link B-C). Later in figure 3-13, Router B responded to the Prune by pruning the link to C and Router I sends a Prune to Router E because it is a leaf router without directly connected receivers. Router E responds and prunes the link to Router I and because Router E now has no connected receivers and the downstream links are pruned it also sends a Prune up to Routers C and D (figure 3-14). But because receiver 1 is connected to the same interface, Router C and D ignore this Prune. Then in figure 3-15, Router G, with no directly receivers, sends a Prune message on the Ethernet to Router F. However, because Prune messages are multicast to the All-PIM-Router group address, Router H overhears it and since it as a directly connected receiver it sends a PIM Join message to override the Prune [Williamson, 2000].
35 (80) 3. Multicast
Figure 3-12 Pruning of non-RP interface [Williamson, 2005]. Figure 3-13 Pruning step 1 [Williamson, 2005].
Figure 3-14 Pruning step 2 [Williamson, 2005]. Figure 3-15 Prune override [Williamson, 2005].
When a PIM router receives a Prune message on a multi-access network a 3-second Prune- delay timer is set. If no overriding Join message arrives to cancel the timer, the Prune happened. This 3-second delay can increase when unwanted multicast traffic is flowing across multiple multi-access networks. Figure 3-16 displays a series of routers linked together via multi-access networks, for example Ethernet. A multicast source starts sending traffic that is flooded to Router E, which is a leaf router without any directly connected receivers, so it transmits a Prune message. Router D waits the normal 3-second Prune-delay time and at the end Router D prunes the interface and transmits its own Prune message to Router C. This continues up until Router A gets the Prune with a total Prune delay of 12 seconds and because PIM Prunes only stay alive three minutes, this will start all over again when the Prune at Router A times out [Williamson, 2000].
Figure 3-16 Prune-delay [Williamson, 2005]
36 (80) 3. Multicast
Look back at figure 3-15, where source traffic is transmitted only to the part of the network where there exist end-users. Onto the Ethernet where Receiver 1 resides, both Router C and D are delivering traffic (duplicate traffic). PIM-DM uses an Assert technique to shut off to only one flow, which is triggered if a router receives a multicast packet via an interface from the outgoing list related to that source. When that takes place, the router transmits a PIM Assert message from the outgoing interface (se figure 3-17) that resolves which router will carry on forwarding the traffic. It contains the routers metric to the source in the multi-access network, in this case C and D, examines the metric to find out which router has the best metric back to the source and in case of a tie, the router with the highest IP address will continue forwarding the traffic [Williamson, 2000].
Figure 3-17 Assert [Williamson, 2005].
PIM-DM has the possibility to scale better than DVMRP if the unicast network is properly designed and uses hierarchical IP Address assignment. That is because PIM-DM applies the underlying unicast routing table for RPF checks and does not send separate multicast routing updates like DVMRP. But they suffer from the same flood-and-prune behavior that can make unwanted traffic to flood periodic through the network. Another disadvantage is that networks with a large number of active groups will lead to a lot of multicast routing states that must be maintained in the routers [Williamson, 2000]. These disadvantages heavily affect the network, therfore PIM-DM should not be used as the multicast protocol for transmitting IPTV.
3.3.4 Protocol Independent Multicast - Sparse Mode
Protocol Independent Multicast Sparse Mode (PIM-SM, RFC 2362) uses like PIM-DM the unicast routing table to carry out the RPF check function instead of having a separate multicast route table. It also uses the same mechanisms for Neighbor Discovery and Asserts. It is also protocol independent, therefore it does not matter which unicast protocol is used [Williamson, 2000].
37 (80) 3. Multicast
PIM-SM uses a model where multicast traffic is only transmitted to the parts of the network that request it. This is done via PIM Joins that are sent to the root node of the unidirectional – shared tree. The root node in PIM-SM is the Rendezvous Point (RP) in the case of a shared tree or the first-hop router that is directly connected to the multicast source in the case of a SPT. All routers that have a directly connected receiver join the shared tree to receive the traffic. While the Join is going up the tree, routers set up multicast forwarding state to be able to forward the requested multicast traffic down the tree. When a receiver leaves a group, a router sends a PIM Prune to prune the unwanted traffic. Important to notice in this Explicit Join model is that forwarding state in the routers is set up as an effect of these Joins and this is very different from the flood-and-prune protocols like PIM-DM where the receiving of multicast packets sets up the forwarding state [Williamson, 2000].
Figure 3-18 Shared tree join step 1 [Williamson, 2005]. Figure 3-19 Step 2 [Williamson, 2005].
Figure 3-20 Step 3 [Williamson, 2005]. Figure 3-21 Step 4 [Williamson, 2005].
Figure 3-18 displays a Shared Tree Join where Receiver 1 has joined the multicast group G by using the IGMP Report. In this example, Router C had to create a (*, G) state entry in its multicast routing table for the group, since Receiver 1 is the first host to join group G. In this case, * means all sources. Next Router C sets the Ethernet interface in the outgoing interface list for the multicast group, see solid arrow in figure 3-19, and in addition Router C has to sent a PIM Join toward the RP to join the tree (dashed arrow in figure 3-19) because of the new entry (*, G) it had to create. The router applies the unicast routing table to decide which interface leads to the RP and when the Join is received by the RP, it also has to construct an (*, G) entry and adds the link to Router C to the outgoing interface list. As figure 3-20 shows, a shared tree for the multicast group G has now been created from the RP to Receiver 1 (the
38 (80) 3. Multicast
solid arrows) and multicast traffic from group G that reaches the RP can be transmitted down the shared tree to Receiver 1. When one more host wants to join the multicast group G (see figure 3-21), it sends an IGMP Report to its designated router. Router E then constructs a (*, G) state entry, inserts the Ethernet interface in its outgoing interface list (solid arrow) and sends a (*, G) Join toward the RP (dashed arrow). As the Join reaches Router C, it discovers that it already exits a (*, G) state for group G and Router C just adds the link to Router E to the outgoing interface list for the (*, G) entry. This results in a shared tree [Williamson, 2000].
Figure 3-22 Shared tree prunes 1 [Williamson, 2005]. Figure 3-23 Shared tree prunes 2 [Williamson, 2005].
PIM-SM uses the Explicit Join model (described earlier) to construct the distributions trees and prunes to take them down when they are no longer needed. The figures 3-22 and 3-23 above describe an example when Receiver 2 (from figure 3-21) leaves the multicast group G. The host sends an IGMP Leave to Router E and because Receiver 2 is the only member to group G on Router E’s Ethernet interface, the interface is removed from the outgoing interface list and the list is empty. When the list is empty, it means that the router no longer needs the multicast traffic, it sends a (*, G) Prune message toward the RP. Router C receives the Prune and removes the link to Router E and the Prune is not sent any further because Router C still has a directly connected host [Williamson, 2000].
Since PIM-SM uses Explicit Join, multicast is better constraint to the parts of the network where there is receivers that actually wants the traffic. PIM-SM does not suffer from inefficiency due to flood-and-prune, which exists in DVMRP and PIM-DM. That makes PIM- SM better suited for IPTV [Williamson, 2000].
Another advantage with PIM-SM, that other sparse mode protocols (like Core-Based Trees described in the next section) does not have, is that it can use the Explicit Join, not only to join the shared tree with the root at RP, but also to join the SPT with the root at a specific source. When PIM-SM uses this feature the multicast traffic is routed directly to the receivers without going throw the RP. This reduces the network delay and potential congestion at the RP. The disadvantage is that it takes up a lot of router resources, because routers must construct and keep (S, G) entries in their multicast routing tables along the (S, G) SPT [Williamson, 2000].
The PIM Joins and Prunes have during the examples above been described as two different message types, but in the reality there exist only one PIM Join/Prune message type. Each PIM Join/Prune message that is transmitted includes both a Join list and a Prune list and a router can Join/Prune multiple sources and/or groups with one PIM Join/Prune message by adding
39 (80) 3. Multicast
multiple entries in the lists. This method significantly improves the efficiency of the periodic refresh mechanism since only a single message is needed to refresh an upstream router’s state [Williamson, 2000].
PIM-SM is according to Williamson (2000) the best choice for an intra-domain multicast routing protocol for most general-purpose multicast networks. Furthermore, it can exist exceptions with special purpose networks that run specific networks applications under the complete control of the networks administrators, but even in those cases, the PIM-SM protocol might be the best suited, but other protocol could work effectively as well.
The protocol is effective to use for the large amount of capacity that IPTV means because it does not flood the network with data. Furthermore, the protocol has effective ways to build SPTs, which will make the IPTV stream to travel on optimal paths. This will help the company to use the bandwidth in a effective way.
3.3.5 Core-Based Trees
Core-Based Trees (CBT, RFC 2201) were designed because there existed a concern about the scalability of multicast as the number of active groups in the network grew. So a primary goal with the protocol was to reduce the multicast state in the routers. To meet this goal CBT is designed as a sparse mode protocol, similar to PIM - Sparse mode, except it uses bidirectional-shared trees to deliver the multicast traffic to portions of the network where receivers have joined. These bidirectional-shared trees are rooted at a Core router and permits traffic to flow in both directions. The routers that already are on the shared tree do not have to do anything specific to forward the locally sourced multicast traffic to the Core. The first-hop CBT router just transmits the traffic up the tree. Figure 3-24 shows a CBT with several hosts (M1-M7) that are joined to the tree. Member M3, in the example, is both a source and a member of the group and is therefore called a member source [Williamson, 2000].
Figure 3-24 Traffic flow on CBTs [Williamson, 2005].
40 (80) 3. Multicast
One disadvantage with this protocol is that routers with nonmember sources attached (i.e routers that is not on the shared tree) must still send traffic sent by these locally attached non- member sources to the Core via an IP-in-IP tunnel so the traffic can flow down the tree to the receivers. Unlike PIM – SM, CBT does not have a way to eliminate the encapsulation of this traffic [Williamson, 2000].
The difference between CBT and PIM - Sparse Mode is the unidirectional nature of CBT, which makes the traffic flow up and down the tree. Instead, PIM – SM uses SPTs between the rendezvous point (RP) and the source to get the traffic to the RP to be forward down the shared tree [Williamson, 2000].
Another issue with CBT is that it uses the notation of a shared tree only to minimize state in the routers, which means that it doesn’t support SPTs. This leads to the fact that CBT does not have the capability to cut over to SPTs. Even though this achieves the goal of reducing the amount of multicast state in the routers, traffic can suffer from increased delay, which isn’t acceptable when dealing with IPTV. This increase can occur if the Core is suboptimal located and the traffic can flow throw a suboptimal path to the receivers, see figure 3-25 [Williamson, 2000].
In figure 3-25, member M8 has caused Router G to join the CBT via a path through Router B. M8 is a source transmitting multicast traffic onto network N7, which are being forwarded up the tree to the Core. M3 is getting this stream via the path through G-B-A-F, even though there exist a direct link to Router F, which would be a more optimal path from M8 to M3. Sadly, CBT does not have the capability for Router F to join a SPT for source M8 and therefore the delay is increased [Williamson, 2000].
Figure 3-25 Suboptimal traffic flow [Williamson, 2005].
41 (80) 3. Multicast
3.4 Inter-Domain Multicast Routing
The multicast routing protocols described earlier focus on intra-domain routing, but to extend the IP multicast to the entire network, inter-domain multicast routing protocols are used. Many operators use the two protocols, Multiprotocol Border Gateway Protocol (MBGP) and Multicast Source Discovery Protocol (MSDP). They are used by many companies and give reasonably scalable inter-domain multicast routing solutions. The Internet Engineering Task Force (IETF) has also developed two protocols that will scale to even larger numbers, Border Gateway Multicast Protocol (BGMP) and Multicast Address Set-Claim (MASC) [Williamson, 2000].
When inter-domain multicast was first talked about it was generally agreed by many service providers that some sort of sparse mode protocol was essential, because dense mode protocols have a flood and prune behavior that is undesirable in an inter-domain multicast solution. In early discussions, it became apparent that the PIM-SM protocol was the preferred multicast protocol, but it caused some problems because it is challenging to interconnect multiple sparse mode domains [Williamson, 2000].
Williamson (2000) mention some requirements that the inter-domain multicast protocol had to meet: An explicit Join protocol inside the domain for efficiency Use of an existing (unicast) operations model for multicast peering Flexibility regarding the location of rendezvous point.
3.4.1 Multiprotocol Border Gateway Protocol
One of the problems with that the service providers wanted to address was to minimize the learning curve for dealing with extra operational burden of multicast peering and have the same set of highly flexible peering controls for multicast routing that exist in their present Border Gateway Protocol (BGP) used to route unicast traffic. To meet these concerns, the service providers used the extension to BGP defined in RFC 2283, to transmit multicast routing information that could be used for Reverse Path Forward calculations [Williamson, 2000].
MBGP consists of two new multiprotocol BGP attributes: MP_REACH_NLRI and MP_UNREACH_NLRI, which are carried inside BGP update messages and used to exchange reachability information for different address families. Within the attributes the Address Family Identifier (AFI) and Subsequent Address Family Identifier (Sub-AFI) are applied to identify the protocol for which the reachability information is applicable [Williamson, 2000].
AFI is set to one if the network uses IPv4 and the Sub-AFI values used are shown in table 3-2. With this information BGP can carry both unicast routing and multicast RPF information in the same updates. Moreover, it is also possible to configure BGP to present different paths for unicast and multicast traffic flows. This is important if an operator wants to build unrelated multicast and unicast networks [Williamson, 2000].
42 (80) 3. Multicast
Table 3-2 IPv4 (AFI=1) Sub-Address Family Identifiers [Williamson, 2005].
Figure 3-26 below shows an example of different unicast/multicast traffic flow between two domains. Router B has been configured to announce both unicast and multicast information to its neighbor MGBP router, router A. The BGP update consists of an old-style NLRI attribute, saying that network 192.192.25.0/24 is available via a next hop of 192.168.100.2, which tells router A that it must send any unicast traffic via the top link shown in the figure. It also includes a new style MP_REACH_NLRI attribute that indicates that this information is to be used for multicast RPF calculations for multicast sources in the 192.192.25.0/24 network [Williamson, 2000].
Figure 3-26 Unicast/Multicast MBGP [Williamson, 2000].
The combination of PIM-SM and MBGP meets the requirements for deploying native multicast, but there are more aspects to take into consideration like allowing independent RPs with flexible location. To meet these conditions Multicast Source Discovery Protocol (MSDP) was developed [Williamson, 2000].
3.4.2 Multicast Source Discovery Protocol
The idea with MSPD is that an RP in a PIM-SM domain has knowledge about all active sources in its domain. If this RP is peered with another RP in another domain using MSDP, the first RP can send MSDP Source Active (SA) messages to the second. This means that every PIM-SM domain has its own independent RP that is MSPD peered together to connect the different domains, see figure 3-27 [Williamson, 2000].
43 (80) 3. Multicast
Figure 3-27 MSDP [Williamson, 2000].
Figures 3-28 and 3-29 below display an example of how MSDP works. One receiver in Domain E joins the multicast group 224.2.2.2 and at this point the source that sends to the group is placed in Domain A. The RP in Domain A have learned about the local source through PIM-SM and starts transmitting SA messages containing the source address, group address and the IP address of the originating RP address to its MSDP peers. The messages are Reverse Path Flooded by all MSDP nodes and to avoid looping the sources RP address in the SA message is used to decide if an incoming SA message was received on the right interface [Williamson, 2000].
Figure 3-28 MSDP, step 1[Williamson, 2000]. Figure 3-29 MSDP, step 2[Williamson, 2000].
As soon as the SA message reaches Domain E, the RP checks its route table after active receivers for the multicast group 224.1.1.1 and in this case founds one, so the RP transmits a (S, G) Join to the source 192.1.1.1. When the Join reaches the source first-hop router, a branch of the (S, G) source tree has been built [Williamson, 2000].
MSDP solves the initial challenge of connecting together PIM-SM domains, but there exist some issues about how far it can scale because all active sources sends periodically SA messages [Williamson, 2000].
44 (80) 3. Multicast
3.4.3 Border Gateway Multicast Protocol
Just like the unicast routing protocol, Border Gateway Protocol (BGP), Border Gateway Multicast Protocol (BGMP) operates on top of TCP. It constructs a shared bidirectional tree and selects the root domain by using a hierarchical multicast address allocation method that permits domains to request blocks of multicast addresses. Currently the Multicast Address Set-Claim (MASC) protocol explained in the next section performs that task [Williamson, 2000].
BGMP is based on the concepts of CBT and PIM-SM. That is mainly because these protocols has rendezvous points, so there will be no network wide flooding of data that exist in DVMRP, MOSPF and PIM-DM. Group members must actively join the shared tree, so the data will only reach the part of the network that requires it. The root in BGMP involves a complete domain and not only an individual router, as in the case with the other protocols [Wittman and Zitterbart, 2001].
With BGMP, there is a single bidirectional shared tree for every multicast group that is active and the tree covers all domains that include senders or receivers of that group. One of these domains becomes the root domain and will function as the root of the bidirectional-shared tree. The other domains sends Joins and Prunes to the root domain, like the routers in a PIM- SM network do. The big difference is that in BGMP the constructed tree is bidirectional and traffic can flow both up and down the tree [Williamson, 2000].
Figure 3-30 displays a BGMP shared tree and Domain B has allocated a multicast group range that includes address 224.2.2.2 and as a result it is selected as the root domain for that group. Domain E, F and G consist of receivers that have to join the group. The Border Routers for those domains sends BGMP Joins to the root domain. In figure 3-31 a multicast source for the group has gone active in Domain D. The intra-domain multicast routing protocol inside of the domain, for example PIM-SM, routes the traffic internally (dashed arrows) to the BGMP Border Routers (BR) that are on the shared tree of domains. These Border Routers forwards the traffic up and down the bidirectional tree to the other domains (solid arrows) and when the traffic reaches the Border Routers in Domains E, F and G the intra-domain protocol once again forwards the traffic internally (dashed arrows) to the receivers [Williamson, 2000].
Figure 3-30 Root Domain [Williamson, 2000]. Figure 3-31 Shared Tree of Domains [Williamson, 2000].
45 (80) 3. Multicast
3.4.4 Multicast Address Set-Claim
Multicast address allocation is an area where improved techniques have been required. IETF has worked to provide dynamic multicast allocation services and one of those new protocols are Multicast Address Set-Claim (MASC) that uses a hierarchical address allocation method. Figure 3-32 illustrates how MASC works. A top MASC server is placed at a chosen location and this root server is responsible for the allocation of the global multicast address range into smaller blocks of addresses to the next lower level of MASC servers. The first level servers send a Set-Claim message that includes a requested range of multicast addresses to the root MASC server. If the range is available, the root sends an acknowledgment and marks the range as allocated in its database, but if the range is not available the root sends an alternative range of addresses to the requester. When a MASC server has claimed a range of addresses it can use them in its internal network or allocate smaller blocks to lower-tier servers. The protocol that is used when an end-station requests a multicast address is the Multicast Address Dynamic Client Allocation Protocol (MADCAP) also defined by the IETF [Williamson, 2000].
Figure 3-32 MASC Hierarchy [Williamson, 2000].
It should be noticed that MASC is a very nontrivial protocol that must be designed carefully to avoid massive fragmentation of the limited resources of multicast addresses. If this fragmentation does occur it leads to complex distributed collection problem of non-used addresses and that is the reason why the design of MASC is moving slowly according to [Williamson, 2000].
3.5 Multicast at Layer 2
Equipment that performs Layer 2 LAN switching has gone from expensive to more cost- effective technology in the last couple of years. The designers have spoken about “switches good, routers bad” and have used an approach called “flat earth”, where the routing functions are moved to the farthest end of the network. This method results in a network with hundreds or even thousands of nodes in a single subnet. The reason why they have used this approach is by changing to high-speed, switched LANs, Ethernet collisions was eliminated and there was little or no call for routing. This has changed the structure of the networks to be more flat and led to large LAN switching topologies [Williamson, 2000].
46 (80) 3. Multicast
Even though switched LANs have reduced the Ethernet collision problem, another problem has been detected because the designers overlooked the effects of multicast on these extremely flat networks. There has been some effort done to deal with the scaling of multicasting in the switched LAN environments [Williamson, 2000].
3.5.1 LAN Switches
When a frame reaches a switch, the switch needs to decide to which port the frame should be forwarded. It does this by looking up the Media Access Control (MAC) address of the destination in a MAC address-forwarding table. To get a table, the switch needs to be taught the Layer 2 MAC addresses of the nodes and the ports to which the nodes are related. It does this by examining the source MAC address of frames transmitted between nodes on the LAN and remembers on which port these frames arrived. When a node’s MAC address and port have been learned, it is stored in the forwarding table [Williamson, 2000].
Earlier, the main CPU in the switch carried out all the switching tasks. The CPU received a frame on one port, looked up the destination MAC address in the table and copied the frame to the right output port. To get a lookup process that was quicker, most of the earliest switches stored the forwarding table in a content-addressable memory (CAM table) and used a pointer to the preferred entry, see figure 3-33. As the demand for performance grew, a special Switching Engine was developed to make the switching-decisions instead of the CPU [Williamson, 2000].
Figure 3-33 Simple Layer 2 LAN Switch [Williamson, 2000].
When a switch receives a frame with no match in the CAM table, it floods the frame out on all ports except the source port. This occurs when the destination MAC address is a broadcast, multicast or has not yet been learned. The situation when the address has not been learned causes no problem. Eventually the switch will “hear” the destination node send a frame and add the information in the table, which will stop the flooding. Broadcast frames must always be flooded out on all ports, except the incoming. The problem arises with multicast. There is generally no way for a switch to know on which ports multicast members exist [Williamson, 2000].
47 (80) 3. Multicast
Some solutions have been developed to constraint multicast flooding in the LAN switch environments. The methods that have been defined are Internet Group Management Protocol Snooping (IGMP Snooping), Cisco Group Management Protocol (CGMP) and IEEE’s GARP. The two first is widely used and is explained below, but IEEE’s GARP is a fairly new approach and will not be examined because it requires changes to end-stations hardware and software [Williamson, 2000].
3.5.2 Internet Group Management Protocol Snooping
In IGMP Snooping the LAN switch listens to the communication between the host and the router. The switch has a multicast CAM table, and when it hears an IGMP Report from a host for a particular multicast group, it adds the host’s port number to the related CAM table entry. In the same manner, if the switch hears an IGMP Leave message from a host, it removes the host’s port number. This appears to be a simple solution, but depending on the architecture of the switch, IGMP Snooping can be difficult to implement without degrading the performance of the switch [Williamson, 2000].
With a simple Layer 2-only switch that doesn’t have any Layer 3 hardware to assist with IGMP Snooping the performance can experience some problems. Figures 3-34 and 3-35 demonstrate an example from [Williamson, 2000]. It consists of a simple Layer 2-only switch that is performing IGMP Snooping.
Figure 3-34 IGMP Snopping, Join 1 [Williamson, 2000]. Figure 3-35 IGMP Snopping, Join 2 [Williamson, 2000].
1. Host 1 wants to join multicast group 224.1.2.3 and multicasts an IGMP Membership Report to the group with a MAC destination address of Ox0100.5E01.0203. At this time there are no entries in the table, so the report is flooded to all ports, also to port zero to the switch’s CPU. 2. The CPU receives the IGMP Report and sets up a CAM table entry that includes the port numbers of Host 1, the router and the switch’s internal CPU. This means that multicasts frames addressed to Ox0100.5E01.0203 will no longer be flooded to other ports. 3. Host 4 wants to join the same group and sends an IGMP Membership Report. The switch forwards it to port 0, 1 and 2 based on the CAM table and when the CPU receives the message, port 5 is added to the table.
48 (80) 3. Multicast
The reason way port 0 is included in the CAM table is that the Switching Engine will continue to pass IGMP messages to the switch’s CPU. Otherwise the CPU would not have heard the IGMP Report from Host 4. This means that all messages sent to the multicast group Ox0100.5E01.0203 will also be sent to the CPU and it will cause performance problem [Williamson, 2000].
Figure 3-36 displays another example where the performance of the switch can decrease. Host 1, from the previous example, wants to send a 1.5 Mbps MPEG video stream to the group. The host transmits the stream to the multicast group with a destination MAC address of Ox0100.5E01.0203 and the CPU will receive the entire stream. This will increase the workload and lead to reduction in switch performance, since the CPU has to look at every multicast frame to find occasionally IGMP packets [Williamson, 2000].
Figure 3-36 Multicast Traffic transmitted throw a Switch’s CPU [Williamson, 2000].
The failure that might happen is in the form of dropped packets in both multicast and unicast traffic. This means that the Switching Engine continues to forward all traffic without drops, even though the CPU begins to drop packets because it cannot keep up with the incoming traffic stream. In result the CPU can miss IGMP packets, which can affect the Join and Leave delays, which are important when dealing with IPTV because a user does not want to wait a long time for a channel change. According to Williamson (2000), the switch can work just fine in a limited demo environment and therefore it is important to test the switch with heavy multicast traffic [Williamson, 2000].
A solution is to redesign the Switching Engine to use new ASICs and CAM tables that can look deeper into the frame at the Layer 3 information before making a switching decision. This means that the CAM table can be programmed to only forward frames with IGMP messages to the CPU for processing. When the switch is Layer 3 attentive, each entry in the CAM table can be loaded with further Layer 3 information that modifies the Switching Engine’s actions. This means that the 1.5 Mbps MPEG stream no longer has to go through the CPU and the CPU can handle the few frames of IGMP traffic per second with no problem [Williamson, 2000].
In the previously explained examples, the routers port number has been automatically added to the port list in the CAM table entry because routers must receive all multicast traffic for all
49 (80) 3. Multicast
groups. So the question is, how did the LAN switch know to include port 1? One answer is that the switch heard a previous IGMP General Query from Router A and remembers that a router is linked to port 1. The problem with this is that if there are more routers connected to the switch, only one are allowed to act as a IGMP Querier, so the remaining routers will not be detected by the switch. A better way is to not only listen to IGMP Queries to detect routers but also listen for special routing protocols [Williamson, 2000].
With the earlier explained examples it might seem simple to apply IGMP Snooping, but the cases described are simple with a single router connected with a single switch with a single host per port. It gets more complicated when multiple multicast routers are used or when multiple hosts are connected to a single switch port via a shared hub. It is important to examine whether the switches used in the network have the Layer 3 – aware hardware, in order to maintain the performance of the switch [Williamson, 2000].
3.5.3 Cisco Group Management Protocol
Dino Farinacci and Alex Tweedly acknowledged in 1996 that there should exist an alternative solution to IGMP Snopping so they developed the lightweight protocol Cisco Group Management Protocol (CGMP). It allows the Layer 2 group membership information to be communicated from the router to the switch, however this is only compatible on Cisco routers and switches [Williamson, 2000].
CGMP messages include a type code field followed by a list of Group Destination Address (GDA) and Unicast Source Address (USA), each identifying a host and the group that the host joins or leaves. The messages are sent to a specific well-known MAC address, Ox0100.0cdd.dddd. The switches can receive the CGMP message by listening after that specific address. It is easier to uphold group membership state in the switch with CGMP than with IGMP Snopping, because individual ports are removed from the CAM table only after receiving a delete port message from a router [Williamson, 2000].
Table 3-3, lists some CGMP messages. The first two messages is used by the router to tell CGMP switches when a host joins or leaves a group. The third and fourth messages allow the router to notify CGMP switches that the station whose MAC address is in the USA field is a router and to either set (Join) or clear (Leave) the related port as a router port. The LAN switch has to know which ports have routers on the other side of the link and include these ports in every multicast CAM table so the router gets all multicast traffic. The last two messages are used for maintenance functions by the router [Williamson, 2000].
Table 3-3 CGMP messages [Williamson, 2000].
50 (80) 3. Multicast
When a host wants to join a multicast group, see figure 3-37, it transmits an IGMP Membership Report that is passed through the switch to the router for normal IGMP processing and sets up its internal IGMP state for the group. If the router has CGMP enabled on the received interface it also translates the IGMP Report into a CGMP Join message and sends it back to the switch via the well-known CGMP multicast address. The switch receives the message and searches the CAM table after an entry for the multicast group specified in the GDA field and if it is not found the switch creates the entry and adds all router ports. Then the switch searches the CAM table again for the entry that matches the unicast MAC address from the USA field and copies the port number from this CAM table to the multicast CAM table created earlier [Williamson, 2000].
Figure 3-37 Basic CGMP operation [Williamson, 2000].
The performance impact of applying CGMP on a switch is low compared to the impact of IGMP Snooping on a switch that does not have Layer-3 hardware. This is because the switch only has to process low-rate CGMP messages from the router instead of processing all multicast frames transmitted. CGMP can be implemented on low-cost LAN switches, but there is one drawback, the switches have to be a Cisco switch [Williamson, 2000].
51 (80)
4 TDC Song’s network
The network used to deploy IPTV is important, since the service is enabled by the available network technology. Content delivery requires bandwidth, performance and security not only in the last mile (the access network), but also in the core and distribution network [Broadband Services Forum, 2005]. In this master thesis, the bandwidth and performance of the network has been examined. The security issue has been left out since it is beyond the scope of this master thesis due to time constraints.
TDC Song’s network is large and complicated because it includes networks from several former separate companies, i.e. Song Networks, Arrowhead, Global One and WinEasy. These networks consist of equipment from different vendors and have been connected together to form one big network. It is not possible to describe the entire network in this master thesis, so the core together with two DSL rings have been chosen to represent the whole network. One ring is situated in Stockholm and the other one in Göteborg. For more information about the equipment displayed, see appendix B.
4.1 Core network
The core network in Sweden consists of ten Gigabit Switch Routers (GSRs) from the Cisco 12000 serie. They are placed as figure 4-1 show. The cities Luleå, Östersund, Sundsvall and Örebro each have one GSR where as the larger cities Stockholm, Göteborg and Malmö have two. These routers are connected to each other by links with a bit rate of 2,5 Gbps. To reach the end-users, the GSRs are linked to the distribution and access networks through Provider Edge (PE) routers, which is described in more detail in the next section. The router connected to the GSR is called PE router because it “talks” MultiProtocol Label Switching (MPLS) with the GSR and IP with the equipment connected on the other side. If TDC Song wants to reach customers that are located all over Sweden, the IPTV stream will be transmitted in the entire core at all times to reduce the wait time for the customers.
Luleå
Östersund
Sundsvall
Örebro Stockholm
Distribution/Access Network Göteborg
GSR 1200 Figure 4-1 TDC Song’s backbone. PE router Distribution/Access Cisco 7304 Network 2,5 Gbps Malmö
52 (80) 4. TDC Song’s network
4.2 Distribution network
The IPTV stream has to be distributed from the core to the parts of the network that have customers connected. This can be done in TDC Song’s network by sending the stream through the PE routers onto DSL rings. The rings consist of switches and Digital Subscriber Line Access Multiplexers (DSLAMs), where the customers are connected to the DSLAM to be able to receive the packets. Two examples are described below.
TDC Song have a lot of 155 Mbps links connected from the GSRs to PE routers, but these links will not be able to carry the entire IPTV stream of 50 channels (5 Mbps/channel) i.e 250 Mbps. The bandwidth of these links has to be upgraded if the company wants to transmit all IPTV channels in those parts of the network.
One interesting question when it comes to the distribution and access networks is how far out in the network the entire IPTV stream should be enabled before a customer joins by turning on the TV set. This is important if it effects the time it takes to change between channels (zapping). Should the entire stream be situated in the core, the DSL rings or should it perhaps be transmitted all the way to the DSLAMs? This was supposed to be examined with a join and leave delay test, however because the test equipment failed to work the test was not performed.
4.2.1 Stockholm
The first example of how a DSL ring is designed in TDC Song’s network is shown in figure 4-2. This ring is situated in Stockholm and has been used for the network tests described in the next chapter. The two GSRs in Stockholm from the core network in figure 4-1 is displayed in the figure below as the two routers with a red 2,5 Gbps link connecting them together. They are linked to separate PE routers (Cisco 7304) that form a ring with switches (Extreme Summit48i) and DSLAMs (Paradyne 8820). The end customers are connected on the other side of the DSLAM via for example an xDSL modem (see appendix A). Figure 4-2 is a simplified model. In the real ring, each switch has a DSLAM connected. The largest DSLAMs in TDC Song’s network can have up to 864 customers connected.
10BASE-T/ 1000BASE-TX 1234 9101112 1000BASE-X 49 49R 50 50R Su mm it tm 49 49R
50 50R 5678 13141516 AMBER = ACTIVE 17181920 25 26 27 28 33 343536 41424344 GREEN = LINK OK FLASHING GREEN = DISABLED
1 2 3 4 5 6 7 8 9 10 11 12 Pa 48 13 14 15 16 17 18 19 20 21 2 23 24 Pb 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 4 45 46 47 48 21222324 29 30 31 32 37 383940 45464748 GSR 1200
PE router 7304
10BASE- T/1000BASE- TX 1234 9101112 1000BASE- X 49 49R 50 50R tm Summit 49 49R 10BASE-T/1000BASE-TX 50 50R 1234 9101112 1000BASE-X AMBE R = ACTIVE 5678 13 14 1516 49 49R5050R tm GREEN = LINK OK 17 18 19 20 25262728 33 34 3536 41 42 4344 Summit FLASHINGGRE EN = DI SABLED 49 49R 50 50R
1 2 3 4 5 6 7 8 9 10 1 12 AMBER =AC TIVE 5678 13 14 1516 P a 17 18 1920 25 262728 33343536 41 42 4344 13 14 15 16 17 18 19 20 21 22 23 24 48 GREEN =LI NK KO P b FLASHING GREEN =DI SABLED 25 26 27 28 29 30 31 32 3 34 35 36 M 1 2 3 4 5 6 7 8 9 10 1 12 37 38 39 40 41 42 43 44 45 46 47 48 P a 48 21 22 23 24 29303132 37 38 3940 45 46 4748 13 14 15 1617 1819202122 23 24 P b 25 26 27 2829 3031323334 35 36 M 37 38 39 4041 4243444546 47 48 21 22 2324 29 303132 37383940 45 46 4748 Extreme Summit48i
10BA SE-T/1000BASE- TX 12 34 9101112
1000BASE- X 49 49R 50 50R tm Summit 49 49R 50 50R Paradyne DSLAM 8820 AMBE R = ACTIVE 56 78 13 141516 17 181920 GREEN = LINK OK 252627 28 33 34 3536 41 424344 FLASHING GREEN = DI SABLED
1 2 3 4 5 6 7 8 9 10 1 12 Pa 13 14 15 16 17 18 19 20 21 22 23 24 48 Pb 25 26 27 28 29 30 31 32 3 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 21 222324 29303132 37 38 3940 45 464748
2,5 Gbps
10BA SE-T/1000BASE- TX 12 34 9101112
1000BASE- X 49 49R 50 50R tm
49 49R Summit
50 50R
AMBE R = ACTIVE 56 78 13 141516 17 181920 GREEN = LINK OK 252627 28 33 34 3536 41 424344 FLASHING GREEN = DI SABLED
1 2 3 4 5 6 7 8 9 10 1 12 Pa 13 14 15 16 17 18 19 20 21 22 23 24 48 Pb 25 26 27 28 29 30 31 32 3 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 21 222324 29303132 37 38 3940 45 464748 Gigabit Ethernet (1 Gbps) Fast Ethernet
10BASE- T/1000BASE- TX 1234 9101112 (100 Mbps) 1000BASE- X 49 49R 50 50R tm Summit 49 49R
50 50R
AMBE R = ACTIVE 5678 13 14 15 16 17 18 19 20 GREEN = LINK OK 25262728 33 34 3536 41 42 43 44 FLASHI NG GREEN = DIABLE S D
1 2 3 4 5 6 7 8 9 10 1 12 P a 13 14 15 16 17 18 19 20 21 22 23 24 48 P b 25 26 27 28 29 30 31 32 3 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 21 22 23 24 29303132 37 38 3940 45 46 47 48
To end-users (xDSL)
Figure 4-2 DSL ring in Stockholm.
53 (80) 4. TDC Song’s network
4.2.2 Göteborg
The DSL ring in Göteborg is constructed with Cisco switches instead of Extreme switches, see figure 4-3. The GSRs in Göteborg in figure 4-1 are connected to the PE routers (Cisco 7304) that are linked to the 10 Gigabit routers (Cisco 7606). The ring is built with Ethernet switches (Cisco 4948) and the links between the switches is upgraded to 10 Gbps instead of 1 Gbps. To all Cisco switches is an Extreme switch (Summit48i) connected with eight Fast Ethernet links. On the other side is a DSLAM (Paradyne 8820) connected with a 1 Gbps link to the Extreme switch.
4948 4948 GSR 1200 7304 7606 Cisco router 7606/ 7304 (PE router)
10BASE- T/1000BASE-TX 1234 9101112 1000BASE- X 49 49R 50 50R Summittm 4949R
5050R
5678 13141516 AMBER = CTIA VE 17 181920 25 262728 33343536 41424344 GREEN = INLK OK FLASHING GREEN = ISDABLED
1 2 3 4 5 6 7 8 9 1011 12 P a 13 14 15 16 17 18 19 20 212223 24 48 P b 25 26 27 28 29 30 31 32 333435 36 M 37 38 39 40 41 42 43 4 454647 48 4948 21 222324 29 303132 37383940 45464748 Extreme Summit48i
Paradyne DSLAM 8820 7304 7606 Fast Ethernet (100 Mbps) 4948 4948 Gigabit Ethernet 8X Fast (1 Gbps) Ethernet Gigabit Ethernet (10 Gbps)
10 BAS E- T/1 000BAS E- TX 1234 9101112 1000 BASE -X 49 49R 50 50R tm Summit 49 49R
50 50R
5678 13 14 1516 AMBE R = ACTIVE 17 18 1920 GREEN = LINK OK 25 26 27 28 33 34 35 36 41 42 4344 FLASHI NG GREEN = DISABLED
1 2 3 4 5 6 7 8 9 10 11 12 P a 48 13 14 15 16 17 18 19 20 21 22 23 24 Pb 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 21 22 2324 29 30 31 32 37 38 39 40 45 46 4748 2,5 Gbps
To end-users (xDSL)
Figure 4-3 DSL ring in Göteborg.
54 (80) 4. TDC Song’s network
4.3 Access network
Private customers are connected to the DSLAM via xDSL, often ADSL or ADSL2+ (see Appendix A). The xDSL link (copper pair) connects the DSLAM to a modem, which is situated at the customer. This is displayed in figure 4-4. This is the weakest link in the network, because of the limited amount of bandwidth.
Figure 4-4 A DSLAM connected to a modem by an xDSL link.
TDC Song wants to offer Internet, VoIP and IPTV on the same physical link to the customer. This can be done logically in two ways. Either, the services can be distributed together in one single VLAN or they can be logically separated to one VLAN per service. In both scenarios it is vital to add traffic isolation, so important packets have a high priority. This has been previously explained in chapter two.
Today the company uses the Thomson 716 modem, with one single VLAN, to deliver all traffic to the customer on the other side of the modem. Another solution is displayed in figure 4-5. The traffic for each service is transmitted logically in separate VLANs instead of one single VLAN. This gives the service provider an easier way to prioritize the traffic by building up a hierarchy where each VLAN has different priorities on layer 2.
Paradyne DSLAM 8820 Thomson 716
xDSL VLAN1 (Internet) VLAN2 (VoIP)
VLAN3 (IP T V)
Figure 4-5 A DSLAM connected to a modem. On the link is each service delivered on a separate VLAN.
This solution has many advantages. The main advantage is that the company can restrict where in the network the TV traffic is transmitted, by creating a virtual private network (VPN) for the TV streams. The Internet and TV traffic will be transmitted on the same physical link but will have a different class of QoS. This cannot be done with the solution used today, because the traffic is not divided logically. Another advantage with separate VLANs is that the traffic can be prioritized at layer 2 switches. This is a benefit because most of the Internet traffic does not reach up to layer 3 (PE routers), therefore to be able to prioritize TV over Internet it has to be done at layer 2. The disadvantage with this solution is that separate VLANs are not supported by the modem the company uses today. To use this solution the company needs to invest in new modems.
55 (80) 4. TDC Song’s network
4.4 Traffic
TDC Song offers several different services to their customers today. For example Internet access, VoIP, VPN and traditional telephony. The traffic is often isolated and prioritized depending on what Quality of Service the customer has bought and in the last years the company has implemented functions to priorities VoIP services over regular Internet traffic to reduce the jitter that affect VoIP negative.
TDC Song has no statistics that displays how much bandwith each service uses. Instead the statistics shows the entire utilization in the network. The link, in the core, that is used most has a utiliazation of 56 %, which is negative because the network cannot handle a link failure. The company are today increasing the bandwidth in the core to handle this problem. Both the distribution network in Stockholm and Göteborg has a utilazation of about 30 % and if the entire IPTV stream goes through these networks the utiliazation will increase above 50 %, which is negative for the network design. The company has started to invest in larger link bandwidth in Göteborg and should do the same in Stockholm to be able to distribute IPTV if the stream is 250 Mbps.
56 (80)
5 Test environment
The multicast tests were mainly performed in a laboratory environment. MDSP and PIM sparse mode were the chosen multicast protocols for the tests, because the multicast is not flooded in the entire network and PIM sparse mode can build SPTs to get an optimal path.
Test one, two and three consisted of finding out the right configurations for PIM sparse mode, set up a multicast stream and watch it at the receiver end. After that, performance tests on the equipment were carried out in test four, five, six, seven and eight. Test nine was done in TDC Song’s live network. The configurations used to enable MSDP, PIM sparse mode and IGMP snooping are displayed in appendix C.
To measure the performance of the equipment, packet loss and the CPU load was examined. Packet loss was choosen because it was stated in the literature study as the most important quality parameter for IPTV (see chapter two). CPU load was looked at because it shows at what percent the router has to work to deliver the packets. Jitter was not examined because packet loss has more negative impact on the video quality. TDC Song has also designed the network to manage to have low jitter even if the IPTV stream will increase this jitter. All the equipment presented in chapter four, except Cisco 7606 and Cisco 4948, were included in the tests.
5.1 Laboratory test
In the first three tests, a video stream was transmitted from one computer to another. The two PCs used the VLC Media Player 0.8.2 to send and receive a coded MPEG-4 video. The video stream was transmitted as a multicast stream with UDP as the transport protocol. The goal with the tests was to receive the stream and to be able to watch it on the other side.
During the following tests, a traffic generator called SmartBit 600 was used to test the performance of the equipment in a laboratory environment. The SmartBit generated multicast traffic between the different elements. The computers and network equipment that has been used for each test is described briefly within this chapter, see appendix B.
5.1.1 Test 1
Test environment: PC/VLC – Switch (Extreme Summit48i) – PC/VLC
Multicast protocol: IGMP Snopping (layer 2)
10BASE- T/1000BASE- TX 12 34 9101112
1000BASE-X 49 49R5050R tm Su mm it 4949R
5050R
AMBER =AC TIE V 56 78 13 14 15 16 17 181920 GREEN =LI NK OK 25 26 27 28 33 34 3536 41 42 43 4 FLASHINGGREEN =DI SABLED
1 2 3 4 5 6 7 8 9 10 11 12 P a 13 14 15 16 17 18 19 20 21 2 23 24 48 P b 25 26 27 28 29 30 31 32 33 34 35 36 VLC M VLC 37 38 39 40 41 42 43 4 45 46 47 48 21 222324 29 30 3132 37 38 3940 45 46 47 48 Streaming: MPEG-4 video (avi format)
Stream output method: Figure 5-1 Test 1: PC – switch – PC UDP
57 (80) 5. Multicast test
The switch (Extreme Summit48i) used IGMP Snooping to forward the multicast traffic, see figure 5-1. The video stream was transmitted from the first PC, by the media program VLC, to the multicast group 239.0.0.1. The second PC used VLC to join the multicast group to be able to receive and watch the stream.
5.1.2 Test 2
Test environment: PC/VLC – Switch (Extreme Summit48i) – PC/VLC
10BASE-T/000BASE- 1 TX 1234 9101112 1000BASE- X 49 49R 50 50R Sum mit tm 4949R
5050R
5678 13141516 AMBER = CTIA VE 17 181920 25 26 27 28 33 34 35 36 41424344 GREEN = INLK OK FLASHINGGREE N = ISAD BLED
1 2 3 4 5 6 7 8 9 10 1 12 P a 48 Multicast protocol: 13 14 1516 1718 1920 21 22 23 24 P b VLC 25 26 2728 2930 3132 3 34 35 36 M VLC 37 38 3940 4142 4344 45 46 47 48 21 222324 29 30 3132 37 38 39 40 45464748 PIM Sparse mode (layer 3)
Streaming: MPEG-4 video (avi format) Figure 5-2 Test 2: PC – switch – PC Stream output method: UDP
The purpose with this test was to send routed multicast through the switch (Extreme Summit48i) displayed in figure 5-2. It was configured with PIM sparse mode and the time-to- live (TTL) value at VLC was increased (it is one by default). The switch was set to act as the RP for the multicast traffic. The video stream was transmitted from the first PC with the help of VLC like in test 1.
5.1.3 Test 3
Test environment: PC/VLC – Router (Cisco 7304) – Switch (Extreme Summit48i) – PC/VLC
Multicast protocol PIM sparse mode (layer 3)
10BASE-T/1000BASE-X T 1234 9101112
1000BASE-X 49 49R 5050R S ummit tm 49 49R
50 50R
AMBE R = CTIA VE 5678 13 14 1516 17181920 GREEN = INKL OK 252627 28 33 343536 41 42 4344 FLASHIG N REENG = ISABLED D 1 2 3 4 5 6 7 8 9 10 11 12 P a 48 13 1415 16 1718 19 2021 2 23 24 P b VLC 25 2627 28 2930 31 3233 34 35 36 M VLC 37 3839 40 4142 43 4445 46 47 48 Streaming: 21222324 29303132 37 383940 45 46 4748 MPEG-4 video (avi format)
Stream output method: Figure 5-3 Test 3: PC – router – switch – PC UDP
To be able to test routed multicast, the PIM Sparse mode protocol was enabled both in the router and in the switch, see figure 5-3. The router (Cisco 7304) was configured to act as the RP and its IP address was set in the switch (Extreme Summit48i) as RP for the multicast tree. The video stream was transmitted from the PC through the elements so it could be received and watched on the PC on the other side.
58 (80) 5. Multicast test
5.1.4 Test 4
Test environment: SmartBit – Router (Cisco 3640) – SmartBit
Multicast protocol PIM sparse mode (layer 3) SmartBit
Streaming: Multicast packets Figure 5-4 Test 4: SmartBit – router – SmartBit Stream output method: None
The test was setup to examine the performance of the router (Cisco 3640) displayed in figure 5-4. The SmartBit generated multicast packets in one direction (point-to-point) during 30 seconds. The packet size was set to 128 bytes and the protocol that was used to transport the packets was not specified (set as none).
5.1.5 Test 5
Test environment: SmartBit – PE Router (Cisco 7304) – Switch (Extreme Summit48i) – PE Router (Cisco 7206) – SmartBit
Multicast protocol PIM sparse mode/IGMP Snopping (layer 3/2)
10BASE -T/ 1000BASE-TX 1234 9101112
1000B ASE-X 49 49R 50 50R tm Summit 49 49R
50 50R
AMBER = ACTIVE 5678 13 14 15 16 GREEN = LINK OK 17 18 19 20 25 262728 33 343536 41 42 43 44
FLASHINGGR EEN = DISABLED
1 2 3 4 5 6 7 8 9 10 11 12 P a 48 13 14 15 16 17 18 19 20 21 22 23 24 P b 25 26 27 28 29 30 31 32 3 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 21 22 23 24 Streaming: SmartBit 29 303132 37 383940 45 46 47 48 Multicast packets Figure 5-5 Test 5: SmartBit – router – switch – router – SmartBit. Stream output method: None
This test was done to examine the performance of the routers (Cisco 7304/7206) that are used in TDC Song’s backbone network as PE routers, see figure 5-5. The SmartBit generated multicast traffic with a packet size of 128 bytes in one direction (point-to-point) for 30 seconds at each value (started at 10 Mbps).
59 (80) 5. Multicast test
5.1.6 Test 6
Test environment: SmartBit –– Router (Cisco 7304) – Switch (Extreme Summit48i) –– SmartBit
10 BASE -T/1000B ASE- TX Multicast protocol 12 3 4 9101112
1000 BASE -X 49 49R 50 50R Summittm 49 49R
50 50R AM BER = ACTIVE 56 7 8 13 14 1516 17 18 1920 GREEN = LINK OK 25 26 27 28 33 34 35 36 41 42 4344 FLASHI NG GREEN = DISABLED
1 2 3 4 5 6 7 8 9 10 11 12 P a 48 13 14 15 16 17 18 19 20 21 22 23 24 P b 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 PIM sparse mode/IGMP Snopping SmartBit 21 22 2324 29 30 31 32 37 38 39 40 45 46 4748 (layer 3/2)
Streaming: Multicast packets Figure 5-6 Test6: SmartBit – router – switch – SmartBit. Stream output method: None
In test 6, the performance of the router (Cisco 7304) and the switch (Extreme Summit48i) was examined, see figure 5-6. The router was configured with PIM sparse mode and set to be the RP. IGMP Snopping was enabled in the switch. A multicast stream (from 100 Mbps to 1 Gbps) was transmitted through the equipments to see how much traffic they could manage. Two tests were performed for 30 seconds per value. In the first test, the packet size was 128 bytes and in the second 1400 bytes.
5.1.7 Test 7
Test environment: PC/VLC – Switch (Extreme Summit48i) – DSLAM (Paradyne) – Modem (Thomson 716) – PC/VLC, with Router (Cisco 7304) connected to the switch as RP
Multicast protocol: PIM Sparse mode/IGMP Snopping (layer 3/2)
Streaming: MPEG-4 video (avi format)
Stream output method: UDP
10BA SE- T/ 1000BA SE-TX 1234 9101112
1000B ASE- X 49 49R 5050R VLC Summittm VLC 49 49R
50 50R AMBE R =ACTI VE 5678 13141516 17 181920 GREEN =LI NKOK 25 26 27 28 33343536 41424344 FLASHI NGGREEN =DI SABLED
1 2 3 4 5 6 7 8 9 10 11 12 Pa 48 13 14 15 16 17 18 19 20 21 22 23 24 Pb 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 21 222324 29 30 31 32 37383940 45464748
Figure 5-7 Test 7: PC – switch – DSLAM – modem – PC
60 (80) 5. Multicast test
In test 7, a DSL setup was tested. The first computer was linked with a switch (Extreme Summit48i) that had a router (Cisco 7304) as RP and the second computer was connected through a modem (Thomson 716) and a DSLAM (Paradyne 8820) to the same switch (see figure 5-7). The link between the DSLAM and the modem was asynchronous (ADSL2+) with an uplink speed of 1 Mbps and a downlink speed of 27 Mbps.
PIM sparse mode was configured in the router and the switch. IGMP Snooping was enabled in the DSLAM and IGMP Proxy was enabled in the modem for routing. In the modem, Network Address Translation (NAT) was used. This can be applied in home networks to hide internal IP addresses. A MPEG-4 stream was transmitted from the first computer and received at the other end.
5.1.8 Test 8
Test environment: SmartBit – Switch (Extreme Summit48i) – DSLAM (Paradyne) – Modem (Thomson 716) – SmartBit
Multicast protocol: IGMP Snooping (layer 2)
Streaming: Multicast packets
Stream output method: None
10BASE-T/1000BASE-TX 123 4 9101112 1000BASE-X 49 49R 50 50R tm
49 49R Su mmit
50 50R
AM B ER = A CTI V E 567 8 13 14 15 16 1 7 18 19 20 GREEN = LNK I O K 25 26 27 28 3 3 34 35 36 41 42 43 44 FL ASH I NGGREEN = DSABLED I
1 2 3 4 5 6 7 8 9 10 11 12 SmartBit P a 48 13 14 15 16 17 18 19 20 21 22 23 24 P b 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 2 1 22 23 24 29 30 31 32 3 7 38 39 40 45 46 47 48
Figure 5-8 Test 8: SmartBit – switch – DSLAM – modem – SmartBit
To further test the DSL setup, PIM sparse mode was shut off in the router and switch, IGMP Snooping was disabled in the DSLAM and IGMP Proxy was disabled in the modem. The switch, DSLAM and modem just acted as a bridge on layer two to forward the packets without routing. Figure 5-8 displays the setup. The multicast packets were also configured to go through a multicast VLAN and the NAT function was disabled in the modem. To find the maximal bit rate without any packet losses, the test rate was started at 10 Mbps and increased if there was no packet loss. Each value was run for 30 seconds. The test was run several times with different packet sizes.
To see if multicast required more of the equipment than unicast, the setup was also examined by transmitting unicast packets with a packet size of 128 bytes.
61 (80) 5. Multicast test
In the next test, PIM sparse mode was implement in the switch and the router (Cisco 7304) was connected as in test 7 to act as RP. In the first round, IGMP Snopping was disabled in the DSLAM where as the second time it was enabled. In the last test, IGMP Proxy was also enabled in the modem. The stream was transmitted with a packet size of 128 bytes. Each rate was tested for 30 seconds.
5.2 Live network test
TDC Song’s core was configured to use the inter-domain protocol MDSP for the network tests. In the remaining parts of the network, PIM - sparse mode was applied. The tests consisted of streaming a MPEG-2 video stream through the DSL ring in Stockholm. The stream was observed on the other side in order to see how the human eye experienced the quality of the picture depending of how the actual data rate in the stream changed.
5.2.1 Test 9
Test environment: PC/VLC – Router (Cisco 7606) – Router (Cisco GSR 12000) – Router (Cisco 7304) – Switch (Extreme Summit48i) – DSLAM (Paradyne) – Modem (Thomson 716) – PC/VLC
Multicast protocol: Cisco 7304
10B ASE-T/1000BASE -TX 12 3 4 9101112 1000 BASE- X 49 49R 5050R Summi t tm 4949R
5050R
56 7 8 13 14 15 16 AM BER = ACTIVE 17 181920 GREEN = LINK OK 25 26 27 28 33 34 35 36 41 42 43 44 MSDP/PIM sparse mode/IGMP Snooping FLASHIG N GREEN = DISABLED 1 2 3 4 5 6 7 8 9 10 1 12 P a 48 13 14 15 16 17 18 19 20 21 2 23 24 P b 25 26 27 28 29 30 31 32 3 34 35 36 M 37 38 39 40 41 42 43 4 45 46 47 48 layer 3/2 21 222324 29 30 3132 37 38 39 40 45 46 47 48
10BASE -T/ 1000BASE- TX 1234 9 101112
1000B ASE- X 49 49R 50 50R Summittm 49 49R 50 50R
5678 13 14 15 16 AMBER = ACTIVE Streaming: 17 18 19 20 GREEN = LINK OK 25262728 33 343536 41 42 43 44
FLASHING GREEN = DISABLED
1 2 3 4 5 6 7 8 9 10 11 12 P a 48 13 14 15 16 17 18 19 20 21 22 23 24 P b 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 21 22 23 24 MPEG-2 video (VBR/CBR) Cisco 7606 29303132 37 383940 45 46 47 48
10 BASE- T/1000BA SE- TX 1234 9101112 1000BASE -X 49 49R 50 50R Su m m i t tm 49 49R
50 50R
AMBER = ACTIVE 5678 13 14 1516 17 18 19 20 GREEN = LI NK OK 25 26 27 28 33 34 35 36 41 42 4344 FLASHI NGGREEN = DI SABLED
1 2 3 4 5 6 7 8 9 10 11 12 P a 48 13 14 15 16 17 18 19 20 21 22 23 24 P b 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 Stream output method: 21 22 23 24 29 30 31 32 37 38 39 40 45 46 4748 VLC 10 BASE- T/1000BA SE- TX 1234 9101112 1000BASE -X 49 49R 50 50R tm Su m m i t 49 49R
50 50R
AMBER = ACTIVE 5678 13 14 1516 17 18 19 20 25 26 27 28 33 34 35 36 41 42 4344 GREEN = LI NK OK FLASHI NGGREEN = DI SABLED
1 2 3 4 5 6 7 8 9 10 11 12 P a 48 13 14 15 16 17 18 19 20 21 22 23 24 P b 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 21 22 23 24 29 30 31 32 37 38 39 40 45 46 4748 Cisco 7606 UDP
10BASE -T/ 1000BASE- TX 1234 9 101112 1000B ASE- X 49 49R 50 50R Summit tm 49 49R
50 50R
5678 13 14 15 16 AMBER = ACTIVE 17181920 GREEN = LINK OK 252627 28 33 34 35 36 41 42 43 44 FLASHING GREEN = DISABLED 1 2 3 4 5 6 7 8 9 10 11 12 P a 48 13 14 15 16 17 18 19 20 21 22 23 24 P b 25 26 27 28 29 30 31 32 33 34 35 36 M 37 38 39 40 41 42 43 44 45 46 47 48 GSR 1200 21222324 29303132 37 38 39 40 45 46 47 48 PE router 7304/ Cisco 7304 router 7606
10BASE-T/1000BASE-TX 1234 9101112 1000BASE-X 49 49R5050R Summittm 49 49R 50 50R
5678 13 141516 AMBER = CTAIVE GREEN = INLK OK 17 181920 25 26 27 28 33343536 41 424344
FLASHING GREEN = ISDABLED
1 2 3 4 5 6 7 8 9 101112 P a 13 14 15161718 19 20 21222324 48 P b 25 26 27282930 31 32 33343536 M 37 38 39404142 43 4 45464748 21 222324 29 30 31 32 37383940 45 464748 Extreme Summit48i Paradyne DSLAM 8820 Thomson 716 2,5 Gbps Gigabit Ethernet (1 Gbps) Fast Ethernet (1 Mbps) VLC ADSL2+
Figure 5-9 Test 10: PC – router – GSR – router – switch – DSLAM – modem – PC.
62 (80) 5. Multicast test
Figure 5-9 displays the network used for test 9. One GSR was configured with MDSP and was set to act as RP. The remaining GSR, the other routers (Cisco 7606/7304) and the switches (Extreme Summit48i) was configured with PIM sparse mode. In the DSLAM (Paradyne 8820) IGMP snooping was activated. The modem had neither IGMP proxy or NAT enabled and acted as a bridge for the traffic. The MPEG-2 stream shown in figure 5-10 was transmitted and observed at the receiver end. VLC was used to transmit and receive the stream. The data rate of the stream changed in time depending on how much information that had to be sent to display the change in the picture. The test was performed to examine if it was possible to see any difference in the picture quality with the human eye when the data rate reached a peak. Figures 5-10 shows how the network usage, and therefore also how the data rate for the stream, changed over time for the transmitted stream.
Figure 5-10 Network utilization for a MPEG-2 stream.
In the last test, a MPEG-2 stream (with a CBR at 5 Mbps) was transmitted from TDC in Denmark to the GSR in Stockholm. The stream was received with VLC in the same manner as before. The video sequence was observed to see if some visual defects appeared.
63 (80)
6 Result and Discussion
In this chapter, the results for each test are presented together with discussions. The tests that are almost identical are discussed under the same headline.
6.1 Test 1, 2 and 3
Test 1, 2 and 3 were implemented to learn more about multicast, especially IGMP and PIM sparse mode. Test 1 and 3 worked well, the stream was transmitted, received and displayed correctly on the other side.
In test 2 on the other hand, the stream was received by the switch (Extreme Summit48i) but not forwarded to the second PC. Therefore, the video was not displayed at the end-user. The system was troubleshot by checking that PIM sparse mode was up and running in the switch and that the RP was set. The multicast protocol was up, but it was discovered that the Summit48i could not find the RP and it could not be set to act as its own RP, so the multicast traffic had nowhere to be forwarded according to the routing table and was dropped.
When the problem with the switch was discovered, it was reasonable that the switch could not act as RP since it is a switch and not a router. This will not affect TDC Song’s network because they have routers in the core network that can act as RP so the multicast traffic can flow through the distribution network where the switch is situated.
The first three tests gave basic knowledge about how to configure multicast and the three points below are important to implement to get it to work: Make sure that there exist unicast routing Set up multicast routing Set RP static
6.2 Test 4
In test 4, the performance of the router (Cisco3640) was examined. Already at 5 Mbps, the CPU was working at 100 percent and the packet losses were large and unacceptable. These losses will have a negative affect on the IPTV quality. The result of the test showed that the 3640 could not handle the amount of multicast traffic that IPTV requires since only one channel needs approximately 5 Mbps and TDC Song wants to offer 50. The IPTV stream will not be able to be transmitted on paths where this particular router is installed.
This will mean that TDC Song have to redesign the network where this particular router is situated. This can be expensive and the company has to evaluate if the redesign is a good investment. Another solution is to direct the IPTV stream so it does not go through paths where the Cisco 3640 is placed. This is a possible solution if there are no IPTV customers situated on these paths.
64 (80) 6. Result and discussion
6.3 Test 5
Test 5 included a performance test of the routers (Cisco 7304 and 7206). Diagram 6-1 displays the packet loss for the entire test settings and diagram 6-2 shows the CPU of the routers.
15
10
5
lossPacket (%) 0 0 10 55 77,5 80,3 81 83,1 88,8 Multicast stream (Mbps)
Diagram 6-1 Packet loss for test 5
80 70 60 50 Cisco 7206 40 Cisco 7304 CPU (%) 30 20 10
0 1 101928374655 Time (sec)
Diagram 6-2 CPU for Cisco routers 7304 and 7206
Diagram 6-1 shows that the test setup managed to transmit 77,5 Mbps without any packet loss. After that the SmartBit tried to send 89 Mbps and the multicast stream lost nine percent of the packets. The traffic generator then tried to find a value between 77,5 Mbps and 89 Mbps without any packet loss and as the diagram displays this value was 81 Mbps.
When the bit rate was 77 Mbps, the CPU in 7206 (displayed in diagram 6-2) was working at up to 70 percent of its capacity. At the same time, the CPU in 7304 was only working at one percent. This indicates that the bottleneck is situated at the 7206 router and that it discards packets. It can handle small amounts of multicast traffic without packet loss, but since TDC Song wants to have 50 channels (5 Mbps/channel) the router should manage at least 250 Mbps multicast at the same time as it handles Internet and IP telephone traffic. This means that the multicast trees in the network should not be built up with 7206 as a node.
The 7206 router could manage more multicast than the 3640 router that was tested in the previous test. This indicates that the 7206 router can handle that a few channels are distributed through it. This means that the company can choose to split the IPTV stream and transmitted
65 (80) 6. Result and discussion
some channels on path with the 7206 router. It can, on the other hand, be more difficult to manage several small streams of multicast than just one large. If the company wants to distribute the entire stream on these paths the network has to be redesigned which will mean an initial cost in new equipment.
The 7304 router on the other hand seemed to manage the multicast stream with no problems and had a CPU usage of only one percent of its capacity, hence it should be suitable to use for transmitting the multicast traffic to the IPTV viewer. The 7304 router was tested in a new setup, in test 6, to see if it could manage the entire stream of 250 Mbps without packet loss.
6.4 Test 6
The results from the first scenario, when the packet size was 128 bytes are displayed in table 6-1 below. It shows that there were no packet losses and that the Parallel Express Forwarding (PXF) worked at about half of the rate transmitted through the link. PXF is a multiprocessor technology developed by Cisco to enable high forwarding performance.
Multicast stream Packet loss, 7304 Packet loss, PXF, 7304 (%) (Mbps) (%) Summit48i (%) 100 0 4 0 300 0 14 0 500 0 25 0 700 0 36 0 1000 0 50 0 Table 6-1 Packet loss and PXF when the packet size was 128 bytes.
The CPU was maximal working at 10 percent when the load was 100 percent (1Gbps). In the second scenario, the size of the packets was changed to 1400 bytes. There were still no packet loss and the PXF value when the data rate was 500 Mbps changed from 25 percent to two percent. So the PXF value seems to depend on the size of the packets. The two test scenarios in test 6 showed that both the router and switch could manage to transmit up to 1 Gbps multicast without any packet loss or extensive load on the CPU.
The test showed that the router can handle multicast traffic well when only multicast is distributed, but what happens when other services are added? This is a unknown factor that have not been tested. It can change the performance of the router when it is situated in the live network instead of the laboratory environment. The router has to be able to manage the multicast stream at the same time as it handles unicast services like VoIP and webbrowsing. These factors can effect the test results and can put a heavy load on the routers CPU, which can lead to packet loss.
66 (80) 6. Result and discussion
6.5 Test 7 and 8
In the first scenario, the MPEG-4 stream was received and watched on the second computer without any problems at the beginning, but after 270 seconds, the stream was shut off. It seemed as a timeout timer reached zero and that the IGMP messages was swallowed somewhere, so the stream was cancelled, however it was not clear if it was the DSLAM or the modem that caused the problems.
To further test the setup, the PIM sparse mode was shut off in the router and switch, IGMP Snooping was disabled in the DSLAM and IGMP Proxy was disabled in the modem. The switch, DSLAM and modem just acted as a bridge on layer 2 to forward the packets without routing. The diagrams 6-3, 6-4 and 6-5 below show the packet loss for different packet sizes.
45 40 35 30 25 20 15
Packet loss (%) loss Packet 10 5 0 5,5 6 6,5 7,7 10 Multicast stream (Mbps)
Diagram 6-3 Packet loss with a packet size of 128 bytes.
80 70 60 50 40 30 20
(%) loss Packet 10 0 10 15,6 21,5 32,5 55 Multicast stream (Mbps)
Diagram 6-4 Packet loss with a packet size of 512 bytes.
67 (80) 6. Result and discussion
60
50
40
30 20 lossPacket (%) 10 0 10 20 23 24 27 32 55
Multicast stream (Mbps)
Diagram 6-5 Packet loss with a packet size of 1024 bytes.
The diagrams show that the bit rate is different depending on the size of the packets that was transmitted. When the packet size was 1024 bytes, a 23 Mbps multicast stream can be transmitted through the DSL setup, but when the size is only 128 bytes not more than 5,5 Mbps can be sent on the same link. The results indicates that the bit rate depends on the packet size. A small packet size menas more packets to transmitted compared with a larger packet size that reduces the amount of packets. More packets requires more switching in the equipment and the bit rate without packet loss is limited by the switching performance.
To minimize the load on the network the packets should be as large as possible without exceeding the Maximum Transmission Unit (MTU). If the packets are larger than MTU, they will divide into more packets and the risk of losing packets increases because of the limitations in the switching performance of the equipment. MTU for Ethernet is 1500 bytes.
To see if there would be any difference between transmitting multicast packets compared to unicast packets, a unicast stream was sent with a packet size of 128 and the result is displayed in diagram 6-6 below.
80 70 60 50 40 30 20 Packet loss (%) loss Packet 10 0 10 15,6 19 20 21 32 55 Unicast stream (Mbps)
Diagram 6-6 Packet loss for a unicast stream with a packet size of 128 bytes.
The diagram shows that a 19 Mbps unicast stream can be transmitted without packet loss and compared with a stream of multicast packets with the same size, the rate was only 5,5 Mbps.
68 (80) 6. Result and discussion
The main reason why the results differed were because a unicast routing protocol was used in the setup while a multicast protocol was not used. The unicast traffic used the unicast routing protocol to enhance the switching performance, which increased the bit rate. In the next scenario, multicast routing was enabled to see if it had an affect on the switching performance.
When the setup was configured in the router and switch to use PIM sparse mode again to route the packets, 13,5 Mbps could be transmitted without packet losses compared to 5 Mbps without a multicast protocol. So the amount of multicast packets that could be transmitted increased when the multicast protocol was enabled, see diagram 6-7. This indicates that the switching performance of the equipment was enhanced.
The next scenario, when the IGMP Snooping was enabled in the DSLAM, gave the same result. That indicates that it was the IGMP Proxy and/or the NAT function in the modem that cancelled the stream in test 7. To be able to determine which function caused the problem, IGMP Proxy was enabled in the modem without NAT. This gave the same result as the previous test, so it was concluded that the NAT function somehow swallowed the IGMP messages.
The NAT function is important for the scalability of IP addresses that is a limited resource in Internet today. Home and company networks with more computers than one can have one public IP address to communicate with other networks and several private IP addresses in their own home/company network. This function is important to maintain despite the problems that it causes for the multicast stream. TDC Song has to find a solution where the modem can handle the NAT function simultaneously with the multicast stream.
120 100 80
60
40 Packet loss (%) loss Packet 20 0 10 12,8 13,5 14,2 15,6 32,5 55 Multicast stream (Mbps)
Diagram 6-7 Packet loss with a packet size of 128 bytes and PIM sparse mode enabled.
69 (80) 6. Result and discussion
6.6 Test 9
The first MPEG-2 stream, encoded as a VBR stream, was transmitted through parts of the network in Stockholm and when the network utilization went up, packets were lost. This appeared as small visual defects in the picture. In this test no buffer was used, which would probably reduce these defects if the packets were lost at the receiver, because it was only one stream with one receiver. The test showed that the packet losses are hard to predict when the stream is encoded with VBR, which is a main reason why VBR is not used for IPTV distribution.
In the last test, a MPEG-2 stream with CBR was sent from Denmark to Stockholm. The stream was received and observed with no defects and good quality. Both the DSLAM and the modem could handle the constant stream at 5 Mbps. The bandwidth requirements are easier to predict when the stream has a constant bit rate and to prevent packet loss in the access network, bandwidth can be reserved for TV.
70 (80)
7 Conclusion
An IPTV solution consists of many different elements that are important. This master thesis focus on the network part of the IPTV solution, which includes transmission technique, network design, network planning and network quality.
For TDC Song to be able to reach many customers with as little impact as possible on the network the company should use some form of multicast to transmit the IPTV stream. The theoretical study showed that the network should be configured with PIM Sparse mode as the intra-domain protocol and MSDP as the inter-domain protocol to connect the PIM Sparse mode domains together. The switches that can handle layer 3 routing should also be configured with PIM Sparse Mode and the other switches should use IGMP Snooping in order to enhance their performance. The mentioned protocols are also the protocols that were used in the performed tests.
The IPTV stream ought to use UDP as the transport protocol instead of TCP to avoid unwanted delay that might accur due to retransmissions. The channels should be encapsulated in TS streams because the technique is mature, well known and the present IPTV equipment supports it. This will mean a smaller initial investment compared to the technique where the video data are encapsulated directly inside the RTP packet without TS. The IPTV service is not in need of that technique’s extra scalability with more functions, for exampel several audio files to one program. That is very useful to apply when delivering Video on Demand when the users wants different languages to the same movie.
TDC Song’s core network is affected by the fact that it is a Nordic company with customers in Sweden, Norway, Denmark and Finland. The company has made a decision to configure one GSR in Sweden, one in Denmark and one in Norway to act as RP. They should use MDSP to communicate and the other GSRs should be configured with PIM Sparse Mode. This will not flood traffic in the entire network and the customer has to request the stream to receive it.
One test showed that the Extreme summit48i, located in the distribution network, cannot act as RP. On the other hand, it has no problem with handling multicast traffic up to 1 Gbps and should be configured with PIM Sparse Mode. According to the laboratory tests, no multicast traffic ought to be transmitted in the parts of the network where the Cisco routers 7206 or 3640 are situated, since their performance decrease and will cause packets to be dropped. The bandwidth should be increased on the links that today has a limit of 155 Mbps if the entire multicast traffic is supposed to go through these links to have the whole stream near the consumers, because 50 channels need approximately 250 Mbps. The downlink speed from the network to the DSLAMs should be upgraded from 100 Mbps to 1 Gbps to be able to handle the IPTV, VoIP and Internet traffic with the smallest congestion possible.
In the access network, the traffic should be sent in separate VLANs so the company can control where in the network the traffic is transmitted by implementing one separate VPN/service. This will mean an initial investment in new modems for triple play services, but the traffic will be easier to monitor and control.
A buffer in the Set-Top Box should be enough to eliminate any jitter the network may cause. To be able to handle packet losses and the limited bandwidth, the network should be designed
71 (80) 7. Conclusion
with a separate VLAN per service. This will make it possible for the company to prioritize IPTV by using VLAN tags to give Quality of Service.
7.1 Further work
Due to time limitations, some tests have not been able to be performed. For example, it would be interesting to test how the routers, switches and DSLAMs would handle more customers than just one. Another aspect that would be interesting to test is the zapping time and jitter variation during heavy load on the network.
72 (80)
References
[Ahlin, 2003] Ahlin, Karl (2003), Quality of Service in IP Networks, Linköping: Department of Electrical Engineering. LiTH-ISY-EX-3323-2003
[Apostolopoulos et al., 2002] Apostolopoulos John, Tan Wai-tian, Wee Susie (2002) Video Streaming: Concepts, Algorithms, and Systems. http://www.hpl.hp.com/techreports/2002/HPL- 2002-260.pdf (Acc. 2005-08-30)
[Bethlehem, 2005] Bethlehem, Danna (2005). Implementing TV over IP on DSL and Fiber Networks. http://www.optibase.com/Objects/Solutions/whit e%20papers/tv%20over%20ip%20formatted.pdf (Acc. 2005-08-23)
[Broadband Services Forum, 2005] Broadband Services Forum, BSF (2005). IPTV Explained http://www.broadbandservicesforum.org/IPTVE xplained.pdf (Acc. 2005-10-07)
[Cisco Systems, 2003] Cisco Systems (2003) Deploying Interdomain IP Multicast. http://www.nanog.org/mtg-0306/pdf/mcbride.ppt (Acc. 2005-11-08)
[Demyttenaere & Legault, 2005] Demyttenaere, Matthew and Legault, Sophie (2005) Quality of Service for Ethernet. http://documents.exfo.com/appnotes/anote134- ang.pdf (Acc. 2005-12-05)
[Fleury, 2005] Fleury, Jean-Francois (2005) IPTV: The need for standards. http://www.isma.tv/technology/white- papers/Paper-IBC- FleuryJF_finalPROTECTED.pdf (Acc. 2005-12-05)
[Forouzan, 2003] Forouzan, A. Behrouz (2003) TCP/IP Protocol Suite. New York. McGraw-Hill Companies. Second Edition. ISBN: 0-07-119962-4
73 (80) References
[Gonzales et al., 1999] Gonzales, A. C and Rajagopalan, R and Westerink, H. P (1999) Two-pass MPEG-2 variable-bitrate encoding. http://www.research.ibm.com/journal/rd/434/wes terink.pdf (Acc. 2005-12-05)
[Halsall, 2005] Halsall, Fred (2005), Computer Networking and the Internet, Harlow. Pearson Education. Fifth Edition. ISBN: 0-321-26358-8
[Internet Academy, 2005] Internet Academy (2005) IPTV kurs.
[Kurose and Ross, 2005] Kurose, F. James and Ross, W. Keith (2005), Computer networking. A top-down approach featuring the Internet, Amherst and Brooklyn. Addison-Wesley. Third Edition. ISBN: 0-321-26976-4
[Paulsen, 2003] Paulsen, Karl (2003) Asynchronous Interfaces For Video Servers. http://www.tvtechnology.com/features/Media- Server-Tech/f_media_server.shtml (Acc. 2005-11-21)
[RAD Data communication, 2003] RAD Data communication (2003) The seven layers model. http://www2.rad.com/networks/1994/osi/layers.h tm (Acc. 2005-12-05)
[Teracom, 2005] Teracom (2005) Radio- och Tv-historia. http://www.teracom.se/?page=246&artionde=19 30 (Acc. 2005-10-25)
[Williamson, 2000] Williamson, Beau (2000), Developing IP Multicast Networks Volume 1, Indianapolis. Cisco Press. ISBN: 1-57870-077-9
[Wittmann & Zitterbart, 2005] Wittmann, Ralph and Zitterbart, Martina (2001), Multicast Communication. Protocols and Applications, San Francisco. Morgan Kaufmann Publishers ISBN: 1-55860-645-9
74 (80) References
[Utbildningsradion, 2005] Utbildningsradion (2005) Television. http://www.ur.se/television/326 (Acc. 2005-10-25)
[Zheng, 2001] Zheng, Qing-Xiong (2001), Secure multicast for Video Stream, Linköping: Department of Electrical Engineering. LiTH-ISY-EX-3104
75 (80)
Appendix A - Networking fundamentals
The Open Systems Interconnection model
The Open Systems Interconnection (OSI) model is a standard reference model for communication between two end-users in a network. Each layer only uses the functions of the layer below. The model consist of seven layers (see the figure A-1 ):
Figur A-1The OSI model [RAD data communication, 2003].
Digital Subscriber Line
The Digital Subscriber Line (DSL) is a group of technologies that offers data transmission over the copper wires used in the last mile of a local telephone network to reach the end-users. The implementation of DSL made it possible for an ordinary telephone line to provide digital communication without interfering with the voice service [Forouzan, 2003].
The common name often used for DSL technologies is xDSL and below are some examples:
ADSL - Asymmetric Digital Subscriber Line, the data can flow faster in one direction than the other (asymmetric). The downstream rates starts at 256 kbps and reaches up to 8 Mbps within 1,5 km from the DSLAM (central office). The upstream rates begin at 64 kbps and can go as high as 1024 kbps. ADSL 2+ - a faster variant of ADSL that can reach rates at up to 27 Mbps within 1,5 km from the central office. SDSL - Symmetric Digital Subscriber Line has the same upstream data rate as downstream (symmetric). It has data rates from 72 kbps up to 2,3 Mbps. VDSL - Very high bit-rate Digital Subscriber Line can offer data transmission up to a theoretical limit of 52 Mbps downstream and 12 Mbps upstream. SHDSL - Symmetric High-speed Digital Subscriber Line can reach data rates up to 4,6 Mbps over two pairs of wires [Forouzan, 2003].
76 (80)
Appendix B - Network and test equipment
Router
A router is a computer-networking device that performs routing, which means that it forwards packets containing data to their destination. The router acts as a connection between two networks and the routing takes place at layer 3 in the OSI model [Forouzan, 2003]. The routers used in this master thesis are all developed by Cisco:
GSR 12000 is a gigabit switch router that performs Internet routing and switching at gigabit speed. PE router 7304 is often used at the customer network edge, where service provider and enterprises link together. It can be used for enterprise campus or Internet gateway applications or be positioned by service providers as a high-end CPE router for managed service offerings. Router 7606 is designed for deployment at the network edge and has a total throughput of 160 Gbps.
Switch
A switch is a device that forwards the packets depending on the related MAC address. This is done at layer 2 in the OSI model. Some switches, for example the Extreme Summit48i, are also intelligent enough to route packets on a layer 3 level. The switches in this master thesis is presented below [Forouzan, 2003]:
Extreme Summit48i is a switch designed for the network edge. It has 48 10/100 BASE-T Ethernet ports and two Gigabit Ethernet ports. Cisco 4948 is a 10 Gigabit Ethernet switch that has 48 10/100/1000BASE-T ports with four alternative ports that can contain 1000BASE-X.
Digital Subscriber Line Acess Multiplexer
The Digital Subscriber Line Access Multiplexer (DSLAM) connects the DSL lines to the core of the network via routers and switches. When distributing IPTV the DSLAMs should support multicast transmission. If it does not, the switch or router must replicate each channel for each request. This can lead to congestion at the DSLAM input. If it supports multicast, it receives one stream for each channel and replicates each stream for each end point [Bethlehem, 2005].
Paradyne 8820 is the DSLAM that has been used in this master thesis. It supports several xDSL technologies, like ADSL, ADSL2+, SHDSL and SDLS and it can also handle transmissions of data, voice and video.
77 (80) Appendix B
Modem
A modem is a device that modulates a carrier signal to encode digital information and demodulates the signal to decode the transmitted information. In other words, a modem produces a signal that can be sent and decode received signals to reproduce original digital data. Thomson 716 is the modem that has been used in this master thesis. It supports ADSL connectivity while providing Voice over IP functions for home and office users [Forouzan, 2003].
Computer
In the laboratory:
Transmitting computer, Sniffer Technologies. Processor: 1,2 GHz Mobile Intel ® Celeron ™ CP RAM: 512 MB Software: Microsoft Windows 2000, Service Pack 4
Receiving computer, Compaq Evo 620. Processor: 1,4 GHz Pentium M RAM: 512 MB Software: Windows XP
In the network:
Transmitting computer, Linux Processor: 550 MHz 4 processor RAM: 1 G Software: Linux debian 2.6
Receiving computer, Compaq Evo 620. Processor: 1,4 GHz Pentium M RAM: 512 MB Software: Windows XP
Media player
The Video LAN Client (VLC) is a multimedia player for various audio and video formats, like MPEG-1, MPEG-2, MPEG-4 and DivX, as well as for DVDs and various streaming protocols. It can also be used as a server to stream in unicast or multicast (IPv4 or IPv6).
SmartBit
SmartBit is a performance analysis system that is developed by Spirent Communications. It can test 10/100/Gigabit and 10 Gigabit Ethernet, ATM, fiber and frame relay networks and devices. Network infrastructure can be tested, simulated, analyzed, troubleshoot and certified with the SmartBit and it supports for example IP Multicast, TCP/IP, IPv6 and routing.
78 (80)
Appendix C - Configuration
Cisco router that is RP: ip multicast-routing distributed ip pim rp-address 213.88.170.100 override ip pim accept-rp 213.88.170.100 int loopback 200 descr RP anycasted address ip address 213.88.170.100 255.255.255.255 ip pim sparse-mode int loopback 201 descr MSDP peering interface ip address 213.88.170.102 255.255.255.255 ip pim sparse-mode router isis passive-interface loopback200 passive-interface loopback201 ip msdp peer 213.88.170.101 connect-source loopback201 ip msdp peer 213.88.170.103 connect-source loopback201 ip msdp mesh-group imsdp 213.88.170.101 ip msdp mesh-group imsdp 213.88.170.103 ip msdp cache-sa-state
Cisco router that is not RP ip multicast-routing ! add "distributed" on GSR ip pim rp-address 213.88.170.100 override ip pim accept-rp 213.88.170.100 ip pim sparse-mode ! on interfaces connecting routers needing multicast.
79 (80) Appendix C
Extreme switch create access-profile "c-rp" type ipaddress configure access-profile "c-rp" add 5 permit ipaddress 224.0.0.0/4 enable pim configure pim add vlan "lo7" sparse configure pim crp static 213.88.170.100 "c-rp" 254 show pim rp-set
Paradyne DSLAM config igmp-snooping enable config igmp-snooping disable config igmp-proxy enable config igmp-proxy disable
Modem
Web browser: 192.168.1.254 Mark the square: igmp proxy
80 (80)