Iptv Course

IPTV Broadcasting, Protocols and Switching

Notes:

Silicon-IPTV-Broadcast -1

Course Objectives When you have completed this course you will be able to • Understand the equipment and software used to deliver IPTV and VoD services • Describe the architecture of a these modern TV services • Compare Cable, over-air terrestrial, satellite and Internet delivery systems • Appreciate the trend in the technologies • Understand addressing schemes for IP network prefix configurations • Examine resilience for MAC/IP mappings for reliable redundancy switching • Select the best routing and switching strategy for server and delivery networks • Analyze protocols used to carry multimedia and troubleshoot services problems • Appreciate how multicast routing protocols function • Specify requirements for firewall transit of video services • Compare how DiffServ, DSCP, RSVP, WFQ, MPLS and 802.1P/Q can provide quality of service • Select the most appropriate quality of service option © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -2

Notes:

Silicon-IPTV-Broadcast -2

Course Materials • Course Notes — Copies of all slides and supplemental presentation material

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -3

Notes:

Silicon-IPTV-Broadcast -3

Course Contents • Chapter 1

Television Architecture and Evolution

• Chapter 2

Broadband Distribution Systems

• Chapter 3

IP Delivery of Multimedia Services

• Chapter 4

Layer 2 Addressing

• Chapter 5

Layer 3 Addressing

• Chapter 6

Routing

• Chapter 7

Multicasting

• Chapter 8

Management of Devices With SNMP

• Chapter 9

Next Generation Network Technology

• Chapter 10

Customer Home Network

• Chapter 11

Industry Trends

• Chapter 12

Summary and Evaluation © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -4

Notes:

Silicon-IPTV-Broadcast -4

Course Schedule Each day, the course will follow this schedule: Start class

9 a.m.

Morning break

10:15 a.m. (approximately)

Lunch

Noon

Resume class

1 p.m.

Afternoon break(s)

As needed

Adjourn

4:30 p.m.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -5

Notes:

Silicon-IPTV-Broadcast -5

Logistics • Restrooms/toilets • Drinking fountains, coffee and soft drink machines, snacks • Restaurants • Messages/phones • Security • Emergency measures • Use of equipment after class hours (if applicable) • Other important items

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -6

Notes:

Silicon-IPTV-Broadcast -6

Course Instructor • Background and education • Current position • Experience

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -7

Notes:

Silicon-IPTV-Broadcast -7

Attendee Introductions • Your name • Organization name • Current position • Experience in:— Television Technology — Networking and LANs — Telecommunications Technology • Expectations

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -8

Notes:

Silicon-IPTV-Broadcast -8

Chapter 1

Television Architectures and Evolution

Notes:

Silicon-IPTV-Broadcast -9

Chapter Objectives In this chapter we will • Examine what the major TV systems in the world are • Explore how the various systems have evolved • Compare various system capabilities • See how digital and analogue systems differ

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -10

Notes:

Silicon-IPTV-Broadcast -10

Television Architectures and Evolution

What is Television Today? Analogue and Digital Compared Delivery Systems: What are they Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -11

Notes:

Silicon-IPTV-Broadcast -11

Human Vision • What we see as essentially white light is a band of energy • Individual colours map on to particular wavelengths • The eye can be fooled into seeing white by using 3 primary colours • Other colours can be formed by mixing these in proportion

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -12

The light that lights up our world and allows us to see that world is solar energy in what is known as the visible region of the Spectrum. This visible region is a very narrow segment of this spectrum extending from ~ 440nm in the extreme blue (near ultra violet) to ~ 690 nm in the red region--with green in the middle @ ~ 555 nm. Human vision is such that what appears as white light is really composed of weighted amounts of a continuum of so-called Black Body energy. Tungsten lamps have a similar spectral distribution. Sodium, Mercury vapor, fluorescent (a variant of Mercury), etc., on the other hand, do not have this continuum of spectral energy, but are composed of several discrete wavelengths in proportions that "fool" the eye. Color cameras are designed to "see" three (overlapping) segments of this spectral continuum by the action of red, green and blue optical bandpass filters. The encoded color signal from the camera does not convey any real wavelength information relative to the original hue.

Notes:

Silicon-IPTV-Broadcast -12

Colour TV Camera • A colour TV camera filters the light into three primary bands — Orange for example at about 570nm would be make up from proportions of green and red

Wavelength in nm

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -13

If a predominantly orange color is imaged the red sensor will describe the light as some intensity of Red only. However, the green sensor will also image some part of this orange light and convey some intensity of what is essentially green light. This only works because the optical color filters are bandpass in nature and posses finite selectivity. If they were discrete monochromatic filters the color imaging system would fail. This points out the ratiometric nature of this imaging system, i.e., the overlapping gradual gradation of the color filters--all three filter have a weighted proportion of the visible spectrum. On the display side of this arrangement is a display device capable of producing only three narrow nearly discreet wavelengths of Red, Green, and Blue light. This is a result of electron bombardment of certain selected phosphors inside the CRT, each releasing a quanta of photons which are essentially "Monochromatic. "The wavelength of which is a function of each's atomic structure. This all works because human vision can be easily fooled when it comes to absolute color discrimination. Within reason, the actual color or hue of each of these three colors is not critical.

Notes:

Silicon-IPTV-Broadcast -13

Mixing Colours • Primary colours can be mixed in proportion to form white

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -14

The addition of colors in the correct proportion creates white; unlike paint which darkens, e.g., black is the addition of Yellow, Cyan and Magenta pigments. Yellow absorbs all but yellow light so it in fact absorbs blue removing it from what we see. In order to produce "White" light to the human observer there needs to be 11 % blue, 30 % red and 59% green (=100%). However, if you shifted, say the red light source to a longer wavelength, the white light would appear more toward cyan. White balance could be restored by changing the three color's weights, i.e. other than the original 11, 30, 59 percent ratios. Each phosphor is formulated as a compromise between its quantum efficiency and desired hue or color. An example of this is the fact that red phosphor requires more energy to cause it to "appear" equally bright to the human observer. Evidence of this can be seen when a CRT is over driven, the first color to bloom, is red. One point should be made: the human observer is very discriminating when it comes to flesh or skin tones.

Notes:

Silicon-IPTV-Broadcast -14

The Colour Pallet

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -15

The luminance of the image seen will affect the perceived colour as well. By adjusting the luminance, effectively the black to white level, at the same time as changing the proportion of different proportions of red, green and blue light the full range of colours needed to produce a television picture can be formed.

Notes:

Silicon-IPTV-Broadcast -15

Forming Television Picture Colour Test Pattern

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -16

In a test pattern different combinations of luminance level and colour mixes are used to provide the range of signals needed in a full picture. This allows flaws in the systems caused by malfunctions or incorrect adjustment of signal levels to be detected.

Notes:

Silicon-IPTV-Broadcast -16

PAL D1 test Pattern

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -17

On CRT displays it is difficult to maintain straight lines and focused colour mapping. Modern flat panel display systems are able to maintain this with less difficulty.

Notes:

Silicon-IPTV-Broadcast -17

Widescreen

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -18

Early TV systems had square or near square aspect ratios because this made best use of broadly circular CRT display efficiency. Human vision is more letter-box shape and 16x9 aspect rations.

Notes:

Silicon-IPTV-Broadcast -18

Digital Image Standards Compared

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -19

Improving the resolution and interlacing, displaying alternate lines in consecutive frames, provide better picture quality. Interlacing delivers better movement quality with limited increase in transmission bandwidth and complexity.

Notes:

Silicon-IPTV-Broadcast -19

Resolutions

Horizontal Vertical

Pexils

RGB Color Detail %

Television: NTSC

427

525

224,175

100/100/100

HDTV

1050

600

630,000

100/100/100

VGA

640

480

307,200

100/100/100

SVGA

800

600

480,000

100/100/100

Computer:

Camera: One Mega

1280

960

1,228,800

25/50/25

Two Mega

1600

1200

1.920,000

25/50/25

Three Mega

2048

1536

3,145,728

25/50/

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -20

Resolution means picture sharpness and is measured in lines of horizontal resolution. If you looked through a window with a giant Venetian blind and could observe a distant ladder and count 625 rungs on that ladder, then you could say you had a vertical resolution of 625 lines. If you couldn't count the rungs, because they were fuzzy or blocked by the slats of the Venetian blind, you would have less than 625 lines of vertical resolution. You could have someone bring the ladder closer and eventually you could count all the rungs. In reality we have 575 not 625 visible lines. It would seem that 575 scan lines would give you a vertical resolution of 575 discernable lines on our ladder. This is not really the case. If one scan line displayed one rung, the next scan line would need to show the space between the rungs, and the following line would show the next rung in order for the rungs on the ladder not to merge together. Put another way, if each scan line saw a rung, then the ladder would look like it was made of solid rungs with no spaces. Thus, an image that goes "rungspace-rung-space" is defined as 4 lines of vertical resolution and it took four scan lines to do it. Thus, 575 scan lines can show only 288 actual rungs on the ladder, but still the TV industry still calls the vertical resolution 625 lines! I have oversimplified. The vertical resolution available from 575 scan lines calculates to .7 x 575 = 403 lines of resolution. Why the .7? Imagine for a moment that you looked through your Venetian blind at the ladder and could see all the rungs inbetween the slats. Now if you moved your head up just a little bit, all of the rungs would be hidden behind the slats and you would see only the spaces between the rungs, erroneously coming to the conclusion that the ladder had no rungs.

Notes:

Silicon-IPTV-Broadcast -20

PAL

SYSTEM Line/Field Horizontal Frequency Vertical Frequency Colour Sub Carrier Frequency Video Bandwidth Sound Carrier

PAL B,G,H 625/50 15.625 kHz 50 Hz

PAL I

PAL D

PAL N

PAL M

625/50 15.625 kHz

625/50 15.625 kHz

625/50 15.625 kHz

525/60 15.750 kHz

50 Hz

50 Hz

50 Hz

60 Hz

4.433618 4.433618 4.433618 3.582056 3.575611 MHz MHz MHz MHz MHz 5.0 MHz 5.5 MHz

5.5 MHz 6.0 MHz

6.0 MHz 6.5 MHz

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

4.2 MHz 4.5 MHz

4.2 MHz 4.5 MHz

Silicon-IPTV-Broadcast -21

The PAL (Phase Alternating Line) standard was introduced in the early 1960's and implemented in most countries except for France.European The PAL standard utilizes a wider channel bandwidth than NTSC which allows for better picture quality. PAL runs on 625 lines/frame.

Notes:

Silicon-IPTV-Broadcast -21

Comparative Resolutions Name

Prog. or inter. p

Total lines

Active lines

Vert. res.

Horz. res.

1050

960

675

600

Opt. view dist. 2.5

p

1250

1000

700

700

2.4

16/9

9

i

1125

1080

540

600

3.3

16/9

20

NTSC i conv. NTSC prog. p

525

484

242

330

7

4/3

4.2

PAL conv. PAL prog

i

625

575

290

425

6

4/3

5.5

p

625

575

400

425

4.3

4/3

5.5

i

625

575

290

465

6

4/3

6

p

625

575

400

465

4.3

4/3

6

HDTV USA, analog HDTV Europe, analog HDTV NHK

SECAM conv. SECAM prog

525

484

340

330

5

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Asp. ratio 16/9

freq. MHz 8

4/3

4.2

Silicon-IPTV-Broadcast -22

The basic concept behind high-definition television is actually not to increase the definition per unit area ... but rather to increase the percentage of the visual field contained by the image. The majority of proposed analog and digital HDTV systems are working toward approximately a 100% increase in the number of horizontal and vertical pixels. (Proposals are roughly 1 MB per frame with roughly 1000 lines by 1000 horizontal points). This typically results in a factor of 2-3 improvement in the angle of the vertical and horizontal fields. The majority of HDTV proposals also change the aspect ratio to 16/9 from 4/3 -- making the image more "movie-like". The following table summarizes a few of the more conventional analogue HDTV proposals in comparison with existing TV system. The aspect ratio of the picture is defined to be the ratio of the picture width W to its height H. The optimal viewing distance (expressed in picture heights, H) is the distance at which the eye can just perceive the detail elements in the picture.

Notes:

Silicon-IPTV-Broadcast -22

Television Architectures and Evolution

What is Television Today? Analogue and Digital Compared Delivery Systems: What are they Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -23

Notes:

Silicon-IPTV-Broadcast -23

Why Digital? • Human eyes are analogue sensors and our ears hear analogue sounds • Both eyes and ears have a wide dynamic range — We can see in almost total darkness yet also in bright sunshine • But • To produce TV that matches this quality takes very high frequencies • We are limited by noise — Analogue signals can take any value so signal and noise look similar — Digital signals take discrete values (0 or 1) small variations can be removed — Similar quality in less bits with digital signals — Computers can compress more cheaply

Analogue

Digital

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -24

To transform a signal from analogue to digital, the analogue signal must go through the processes of sampling and quantization. The better the sampling and quantization, the better the digital image will represent the analogue image. Sampling is how often a device (like an analogue-to-digital converter) samples a signal. This is usually given in a figure like 48 kHz for audio and 13.5 MHz for video. It is usually at least twice the highest analogue signal frequency (known as the Nyquist criteria). The official sampling standard for standard definition television is ITU-R 601 (short for ITU-R BT.601-2, also known as "601"). For television pictures, eight or 10-bits are normally used; for sound, 16 or 20-bits are common, and 24-bits are being introduced. The ITU-R 601 standard defines the sampling of video components based on 13.5 MHz, and AES/EBU defines sampling of 44.1 and 48 kHz for audio. Quantization can occur either before or after the signal has been sampled, but usually after. It is how many levels (bits per sample) the analogue signal will have to force itself into. As noted earlier, a 10-bit signal has more levels (resolution) than an 8-bit signal.

Notes:

Silicon-IPTV-Broadcast -24

Digital Sampling • For picture quality to be maintained we must sample often enough • Nyquist proved (in 1929) that we must sample at least twice the highest frequency — To obtain audio with 20 kHz signal we sample at 44,100 samples per second — We may sample the video at 14 MHz • A full bandwidth digitally sampled PAL signal takes about 160 Mbit/s — This is impractical for transmission but contains lots of redundancy

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -25

Ratios such as 4:2:2 and 4:1:1 are an accepted part of the jargon of digital video, a shorthand taken for granted and sometimes not adequately explained. With single-channel, composite signals such as NTSC and PAL, digital sampling rates are synchronized at either two, three, or four times the subcarrier frequency. The shorthand for these rates is 2fsc, 3fsc, and 4fsc, respectively. With threechannel, component signals, the sampling shorthand becomes a ratio. The first number usually refers to the sampling rate used for the luminance signal, while the second and third numbers refer to the rates for the red and blue color-difference signals. A 14:7:7 system would be one in which a wideband luminance signal is sampled at 14 MHz and the narrower bandwidth color-difference signals are each sampled at 7 MHz. As work on component digital systems evolved, the shorthand changed. At first, 4:2:2 referred to sampling luminance at 4fsc (about 14.3 MHz for NTSC) and color-difference at half that rate, or 2fsc. Sampling schemes based on multiples of NTSC or PAL subcarrier frequency were soon abandoned in favor of a single sampling standard for both 525- and 625-line component systems. Nevertheless, the 4:2:2 shorthand remained. In current usage, "4" usually represents the internationally agreed upon sampling frequency of 13.5 MHz. Other numbers represent corresponding fractions of that frequency. A 4:1:1 ratio describes a system with luminance sampled at 13.5 MHz and color-difference signals sampled at 3.375 MHz. A 4:4:4:4 ratio describes equal sampling rates for luminance and color difference channels as well as a fourth, alpha key signal channel. A 2:1:1 ratio describes a narrowband system that might be suitable for consumer use and so on. Unlike 4:1:1, however, the samples in 525 line systems don't come from the same line as luminance, but are averaged from two adjacent lines in the field. The idea was to provide a more even and averaged distribution of the reduced color information over the picture.

Notes:

Silicon-IPTV-Broadcast -25

Compression • Compression is possible once we are in the digital domain • Video pictures are inherently full of redundancy if we have storage — In the majority of cases the next frame is largely the same as the last — By sending just the differences we can reduce bandwidth • Methods used today are dominated by Motion Picture Experts Group

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -26

Some people say that compressing video is a little like making orange juice concentrate or freezedried back-packing food. You throw something away (like water) that you think you can replace later. In doing so, you gain significant advantages in storage and transportation and you accept the food-like result because it's priced right and good enough for the application. Unfortunately, while orange juice molecules are all the same, the pixels used in digital video might all be different. Video compression is more like an ad that used to appear in the subway which said something like: "If u cn rd ths, u cn get a gd pying jb" or the kind of language used in SMS text messages. The real difference is perhaps the scale of the compression in that we can now deliver a viable picture in about 2% of the bandwidth of the original. A 2 Mbit/s video stream replacing a 166 Mbit/s original. The price we pay is quality. The notion of quality in any medium is inherently a moving target. We've added color and stereo sound to television. Just as we start to get a handle on compressing standard definition signals, high definition and widescreen loom on the horizon. There will never be enough bandwidth. There is even a Super High Definition format that is 2048x2048 pixels--14 times as large as NTSC. Perhaps former Tektronix design engineer Bruce Penny countered the quip best when he said, "Compression does improve picture quality. It improves the picture you can achieve in the bandwidth you have.”

Notes:

Silicon-IPTV-Broadcast -26

Television Architectures and Evolution

What is Television Today? Analogue and Digital Compared Delivery Systems: What are they Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -27

Notes:

Silicon-IPTV-Broadcast -27

Television Broadcasting Industry

Programme Production Film News TV Production

Content

Channels

Marketing and Delivery

Entertainment Government and Politics Religion Education Community

Distribution

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Over-the-air Cable Satellite Internet and IP

Delivery

Silicon-IPTV-Broadcast -28

Community antenna television (now called cable television) was started by John Walson and Margaret Walson in the spring of 1948. The Service Electric Company was formed by the Walsons in the mid 1940s to sell, install, and repair General Electric appliances in the Mahanoy City, Pennsylvania area. In 1947, the Walson also began selling television sets. However, Mahanoy City residents had problems receiving the three nearby Philadelphia network stations with local antennas because of the region's surrounding mountains. John Walson erected an antenna on a utility pole on a local mountain top that enabled him to demonstrate the televisions with good broadcasts coming from the three Philadelphia stations. Walson connected the mountain antennae to his appliance store via a cable and modified signal boosters. In June of 1948, John Walson connected the mountain antennae to both his store and several of his customers' homes that were located along the cable path, starting the nation’s first CATV system. John Walson has been recognized by the U.S. Congress and the National Cable Television Association as the founder of the cable television industry. John Walson was also the first cable operator to use microwave to import distant television stations, the first to use coaxial cable for improved picture quality, and the first to distribute pay television programming (HBO)

Notes:

Silicon-IPTV-Broadcast -28

Architecture of Cable TV Distribution

Programme Production Film News TV Production

Content

Channels Entertainment Government and Politics Religion Education Community

Distribution

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -29

The Head End: The control center of a cable television system. The headend receives incoming signals from satellites, television antennas and locally produced programs and amplifies, converts, processes, combines and transmits the signals through a cable network to subscribers. The headend includes antennas, preamplifiers, frequency converters, demodulators, modulators, processors, scrambling and descrambling equipment. The uplink sends programming signals to satellites to be relayed back to earth. Cable programmers have large uplinks, which are more powerful than, but similar to earth stations. Earth Stations receive satellite signals. This parabolic antenna is also known as a TVRO (Television Receive Only) antenna. A number of earth stations are located at the cable system to receive programming from dozens of services like MTV, ESPN and HBO. Also called "dishes" because of its shape, earth stations can be 15 meters or more in diameter, or as small as 18 inches. Millions of individuals and businesses also own dishes to receive programming directly from satellites. A network of coaxial cable and fiber optic cable used by cable providers to deliver programming to customers. A broadband cable system is capable of delivering analog and digital communication signals. The first segment, the trunk line system, connects the headend to the first bridging amplifiers or fiber optic nodes. Trunk lines can also include power supplies and other electronic components. The next segment, the feeder system, carries signals to individual neighborhoods. The last segment, the drop line part of the network, is coaxial cable which connects individual subscriber locations to the feeder trunk.

Notes:

Silicon-IPTV-Broadcast -29

Cable Distribution System

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -30

In a modern cable network other non-TV services might be added. In particular Internet access via cable modems within the set-top box or directly connected to it. By adding two way data access services independently of telephone networks the cable operator can both add new data services and uses the internetworking capability for telemetry control of programme access. The industry trend is towards greater and greater use of IP transport of both programmes and control services. Throughout the TV industry there is a transition towards IP taking place. This is moving at such a pace that many industry experts expect the majority of YV channels to be distributed over IP transports as their primary method by 2007.

Notes:

Silicon-IPTV-Broadcast -30

Expanded Television Services • Expanded services are those that go beyond the distribution of TV programs • Provision of Telephony services • Information services • Internet access • Interactive Gaming

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -31

In the end users do not make use of raw communications capacity but use services. The diversity of services now available have increased well beyond just TV.

Notes:

Silicon-IPTV-Broadcast -31

Telephony Services • Telephony is - or was - a high value service — Since 2001 there has been a reduction in voice prices — In 2004 UK fixed line voice revenues fell more than 25% • Cable operators can add this service • Easy additional revenue generation • Regulation is the biggest hurdle • Competition now with other Internet access • TV over phone lines is the next technology

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -32

At the time of relatively high telephony charges during the 1980s and 1990s the opportunity to add telephony to cable TV networks provided and opportunity for additional revenues for cable TV providers. Analogue cable networks were almost entirely unidirectional because the line amplifiers worked in one direction only. Building digital networks that have bidirectional capability, even if at different speed deliver greater flexibility.

Notes:

Silicon-IPTV-Broadcast -32

Cable Modems • Internet access can be provided via cable modems • Early broadband access via cable offered 500 kbit/s services • Lower initial price than ADSL broadband • Extended ADSL services at 1 Mbit/s, 2 Mbit/s and up to 4 Mbit/s — These are likely to be difficult for cable to match • VDSL at 10 Mbit/s and eventually up to 50 Mbit/s may replace cable — TV over IP is feasible along with all services in the long term

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -33

Once networks were bidirectional it became feasible to carry data. Normally this is used for access to the Internet. By using more bandwidth from network to user than in the reverse direction paterns of operation better match normal service use.

Notes:

Silicon-IPTV-Broadcast -33

Information Services • All TV distribution systems must provide information on programmes • The same technology can provide information on other things • May be possible to bill for some information — Sports results — Ticket bookings — Travel — Advertising

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -34

In the end all services can be viewed in one way or another as information.

Notes:

Silicon-IPTV-Broadcast -34

Interactive Gaming • Interactive gaming takes 3 major forms • Gambling — Event betting — Interactive poker and other games of chance — Lottery • Games played via dedicated head-end servers — Trivia quizzes played for entertainment — Arcade games using set-top box processing — Games uploaded into special gaming consoles • Peer-to-peer group gaming — Interconnected networked games from PC or gaming consoles – e. g. Network quake

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -35

On the early commercial Internet only services were found to be quickly profitable – sex and gambling. While these continue to be in demand interactive gaming has progressed beyond just gambling into areas of network entertainment. Some sectors of the market believe that this area will become the most important once televisions evolve into Internet attached media centres with lots of processing power.

Notes:

Silicon-IPTV-Broadcast -35

Television Architectures and Evolution

What is Television Today? Analogue and Digital Compared Delivery Systems: What are they Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -36

Notes:

Silicon-IPTV-Broadcast -36

Chapter Summary In this chapter, we have • Examined what the major TV systems in the world are • Explored how the various systems have evolved • Compared Various system capabilities • Seen how digital and analogue systems differ

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -37

Notes:

Silicon-IPTV-Broadcast -37

Chapter 2

Broadcast Distribution Systems

Notes:

Silicon-IPTV-Broadcast -38

Chapter Objectives When you have completed this chapter you have learned how to • Examine component parts of a TV distribution networks • Explore how the various systems options • Identify the key interfaces • Predict how the technology will evolve in the near future • Examine the encoding and compression standards

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -39

Notes:

Silicon-IPTV-Broadcast -39

Broadcast Distribution Systems

Cable TV Delivery Systems Terrestrial Delivery IP Delivery Encoding Methods Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -40

Notes:

Silicon-IPTV-Broadcast -40

Components of a Cable TV System Interface to programme, channel and content suppliers

Set-top box for conditional access, interfacing and decoding Headend: Control, switching, encoding and management

Fiber and coax cable distribution

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -41

Around the globe, cable TV operators are investing to upgrade their networks in order to offer additional TV channels and two-way interactive services such as high-speed Internet access and telephony. The main issues are:- How can these upgrades be designed to maximize bandwidth, reliability, quality and flexibility while remaining cost-effective? - How can the resulting platform remain as open to future expansion as possible? - What needs to be done in order to support further expansion into promising new markets, such as business voice and data services? Up to now, the large majority of subscribers are offered two basic types of services from their local cable TV company. For a fixed monthly fee, the cable TV company provided a few dozen TV channels that could be viewed "in the clear", which means directly on any standard TV set. This is called the "basic tier". Subscribers can also elect to pay additional fees to get access to "premium" channels. The premium channels require the use of a set-top decoder in order to be descrambled. From a network infrastructure standpoint, cable TV is delivered via an analog broadband distribution plant based on coaxial cable for end delivery to the subscriber and optical fiber for distribution. The transmission capacity of the network ranges between 330 and 860 MHz, with most modern plants operating at 550 MHz. This type of network architecture is by far the most widely used by cable TV operators and is called the Hybrid Fiber Coax (HFC) network.

Notes:

Silicon-IPTV-Broadcast -41

Traditional Cable TV Head End Components

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -42

The "headend" is the primary facility of any cable network. The headend's function is to collect all the basic and premium TV channels and combine them for delivery to subscribers over a single coax cable. TV channels are collected in three ways: using standard TV antennas to pick up signals "offair" the same way any TV set can pick them up, via satellite dish, or via direct fiber feed from local TV affiliates to maximize reception quality. Premium channels are also scrambled to prevent unauthorized viewing. The combined broadband signal is then sent to subscribers via the HFC network. Most HFC networks are designed so that optical fiber is deployed to pockets of around 500 homes, then converted to coax cable for delivery to the home. Along the way, the signal will be split and re-amplified several times using a "tree-and-branch" topology. Premium channel subscribers are provided with a special unit called a TV set-top converter to descramble the premium channels to which they have subscribed. Some premium channels are also controlled on a "pay-per-view" basis, where each particular broadcast on the channel is charged to the subscriber. Each individual TV channel is received using specific equipment. For satellite-fed channels, an "Integrated Receiver Decoder" (IRD) is used to convert the signal to its baseband NTSC or PAL form. At this point, the signal could be viewed on a TV set as NTSC/PAL is the standard signal that your TV set receives. Similarly, TV channels that are received "off-air" via an antenna are demodulated from their original carrier frequency and converted to NTSC/PAL by a Radio Frequency (RF) demodulator. All signals belonging to "premium" service tiers (mostly satellite-fed) are fed to a "scrambler" unit which encodes the signal to prevent its unauthorized viewing.Finally, each signal is fed into a bank of RF modulators where they are assigned a specific channel slot. The resulting modulated signals are fed into a passive RF combiner, which multiplexes all modulated signals together into a single broadband 330-to-860 MHz signal. This signal is then converted to optical and fed to subscribers via the HFC network.

Notes:

Silicon-IPTV-Broadcast -42

Enhanced Cable TV Network Services

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -43

The HFC TV plant described above poses two limitations to the modern-day cable TV operator. First, it can carry only up to 80 TV signals. The ability to carry more channels can provide substantial additional revenues by enabling the offering of additional premium TV channel packages. Second, bandwidth constraints limit the capability to serve the seemingly insatiable demand for high-speed Internet access, which promises even greater revenue growth. Cable's very high bandwidth can offer access speeds measured in megabits per second, or about 1000 times the speed of ordinary telephone modems. Once upgraded for high-speed Internet access, the cable TV network will also be able to carry telephone conversations, providing yet-another very significant revenue increase potential. In order to support more TV channels as well as high-speed Internet access and telephone services, the cable TV headend needs to be upgraded. At the headend, links to the mainstream telco network are required in order to support two-way Internet and voice services. These are provisioned using standard 34 Mpbs or 140 Mbit/s feeds. At the home, a new unit called the "cable modem" will be deployed to those subscribers that have ordered the provider's voice and/or Internet services. This unit will make the link between the coax cable plant and the subscriber's PC and/or telephone set. The technique used to provide for more TV channels is digital compression, which typically yields a fivefold increase in capacity. To that end, compressed TV signals are received via satellite receivers or local cable feeds and are converted to analog using advanced Quadrature-Amplitude Modulation (QAM) techniques and then fed into the cable plant via standard RF modulators. At the subscriber's home, a special digital TV set-top decompresses the signal, converts it to analog baseband and feeds it to the TV set.

Notes:

Silicon-IPTV-Broadcast -43

Enhanced Head End

Internet

Network Access

Extra Channels © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -44

The process of sending and receiving Internet data via the cable plant uses QAM digital modulation techniques as well. In the headend, Internet data received from the backbone via the telco network is fed to a standard TCP/IP router. This data is then converted to analog using 'cable modems', which use QAM modulation to convert the Internet data into an analog signal. This signal is then fed to the cable plant. At the home, the signal is received by a special 'cable modem', which is hooked to the coax cable on one side and to the subscriber's computer via Ethernet on the other side. Speeds can reach around 30 Mbps 'downstream', that is from the backbone towards the subscriber, and anywhere from 128 Kbps to 2 Mbps 'upstream', or from the subscriber towards the backbone. Such modems are called 'asymmetrical', since unlike standard telephone modems, their upstream and downstream bandwidths are different. Most cable modems on the market are fully interoperable between various manufacturers and comply to the MCNS-DOCSIS standard published by CableLabs, the cable industry's standardization body. The same technique can support the deployment of telephony via cable, and in fact most cable modem units also sport a standard telephone jack to be connected to the subscriber's phone set.

Notes:

Silicon-IPTV-Broadcast -44

Multiple Cable Operators

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -45

Most companies are referred to as Multiple Systems Operators (MSOs), since they operate dozens, sometimes hundreds of cable systems. Each individual cable TV distribution system is equipped with its own headend. Typically, a cable TV headend can serve between 20,000 and 60,000 subscribers. This means that a large metropolitan area would normally count between 5 to 15 independent cable TV systems. As each one of these systems is upgraded for digitally-delivered video, voice and data, it needs to upgrade the distribution plant to two-way, install the related equipment, and establish a local connection to the Internet via facilities leased from the telco network. This deployment approach, while simple to implement, presents several issues to the MSO. First, each individual headend needs its own set of Internet connection equipment, as well as its own connection to the Internet. The same is true for all equipment and connections required for the deployment of additional channels via compressed digital video feeds. There is no way to share Internet access bandwidth between the various headends, as none of the connections are shared. There is no mechanism in place to provide centralized management, which implies that each individual headend needs to be managed independently. Finally, no mechanism exists to provide for redundancy within a given headend. In short, the MSO operates its cable TV network as a collection of isolated islands, with no real value-added derived from any kind of interconnection and complete duplication for capital, operating and maintenance costs.

Notes:

Silicon-IPTV-Broadcast -45

Interconnected Head Ends

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -46

Standards-based optical fiber networks offer a much more compelling strategy for upgrading cable TV systems. The basic idea behind Regional Cable TV Headend Interconnection (RCHI) networks is that instead of developing independent islands, one headend in the network will serve as a primary hub to feed all the others. One headend is designated as the 'main' hub, and the others serve as 'remote' headends. In the example above, EastBurg serves as main, while CenterVille and NorthTown serve as remotes. All headends in the RCHI network are linked together using a 2.4 Gbps SONET/SDH OC48/STM16 digital fiber ring. SONET/SDH is the worldwide standard used by all telecommunications carriers in order to build interoperable fiber networks between central offices. In fact, SONET and SDH are similar standards used in different parts of the world, where SONET is used in North America, SDH is used in Europe and Latin America, and both being used in Asia. It is fair to say that all the fiber used by today's telco carriers carries video, voice and data according to the SONET/SDH standard, which is supported by dozens of equipment manufacturers on a completely interoperable basis. The ring architecture used by SONET/SDH provides complete protection against fiber cuts, which cause over 85% of network failures according to a recent NPRS study. SONET/SDH dictates that any fiber cut on the network will be result in traffic being rerouted in less than 50 milliseconds.

Notes:

Silicon-IPTV-Broadcast -46

SDH Connected Head Ends

Internet

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -47

A 2.4 Gbps SONET/SDH multiplexer is added at the main headend. On one side, this multiplexer provides supports various low-speed interfaces. The most popular for SONET are 45 Mbps DS3 and 155 Mbps OC-3. A typical 2.4 Gbps SONET multiplexer can provide interfaces for up to 48 DS3s or 16 OC-3s. Similarly, SDH uses 34 Mbps E3 and 155 Mbps STM-1 for low-speed interfaces, and the SDH multiplexer can provide interfaces for up to 64 E3s or 16 STM-1s. On the optical fiber side, both SONET and SDH provide direct connectivity for two or four fibers to link the main headend to any number of remotes. DS3/E3 and OC3/STM1 interfaces are almost universally supported by most digital video, voice and data equipment such as IP routers, cable modems and digital video satellite receivers. This means that all these devices can be directly connected to the SONET/SDH multiplexer as shown above, and then provided to the remote headends via fiber. In order to do the same with the basic and premium TV services, they must first be converted into DS3 or E3 format by using ABL VideoExpress™video codecs such as the DVT for NTSC or the VT34A3 for PAL.

Notes:

Silicon-IPTV-Broadcast -47

Head End Signal Reception • Digital Satellite Receiver • Encrypted and Direct Video Broadcast (DVB) modes of operation • 3 to 40 Mbit/s operation • Advanced Serial Interface (ASI) input and output — Most advanced units now support Gigabit Ethernet instead

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -48

Inputs to the Headend will come from satellite feeds from programme makers and channel feeds. Modern satellite receiver series employ the latest in MPEG-2/DVB digital technology. Exceptional end-user reception and signal quality is achieved by using robust QPSK satellite demodulation, forward error correction, and MPEG-2 decompression circuitry, all housed within a professional rack-mountable chassis. They process Standard Definition transport streams, including, encrypted signals and unencrypted DVB signals. The latest include the ability to process High Definition (HD) transport streams, via an ASI output, for external HD decoding. With additional key features such as Video Broadcast Interface (VBI) reinsertion.

Notes:

Silicon-IPTV-Broadcast -48

Encoding and Trans-coding • An important part of the Headend function is encoding TV signals • Feeds may arrive in one satellite modulation format and be re-coded to another for more efficient onward transmission • NTSC feeds may be converted to PAL • Encoding of analogue to MPEG-2 or even MPEG-4 may be required • The selection of the vendor for headend equipment is often based upon the quality of such codecs and trans-coding

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -49

The Integrated Receiver Transcoder (IRT) receives a modulated QPSK carrier and transcodes it into a more bandwidth efficient 64 QAM format. The unit accepts L Band input from a satellite downconverter and produces a signal appropriate to transmission in a 6 MHz television RF channel. The IRT decrypts and performs Forward Error Correction (FEC) on the incoming satellite data stream. It then clears information streams not intended for local cable transmission and inserts new information streams for this purpose. It prepares the signal for transmission across the terrestrial cable system by re-encrypting programs under local headend control. IRTs are linked via an Ethernet connection in a local headend LAN. The IRT provides local generation and insertion of program specific data, including tier level, purchaseability, price and rating codes. The unit can also be controlled via a management system. IRTs may be optionally daisy chainedtogether via the multidrop port and controlled remotely over the satellite link where no Ethernet connectivity exists. The IRT also provides an expansion interface port so that external devices can be cascaded to allow for processing beyond the capacity of a single IRT.

Notes:

Silicon-IPTV-Broadcast -49

Video Router • Acts as a switch between video feeds and output to cable • Requires enough inputs for all channels and backups • Sizes up to 1024 x 1024 possible • May support redundant operation • ASI interfaces are common — Latest systems may use Gigabit Ethernet • Conforms to SMPTE 291M or 292

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -50

Channels and feeds must be switched from input of the head end via transcoding to the correct format for distributions and then on to the distribution network. In the real world equipment fails from time to time and so redundancy provision is also required. This all demands a switch at the core of the headend capable of interconnecting, and switching all the feeds. This unit is called a video router. With the migration from ASI digital feeds to IP this component will become a gigabit switch carrying video feeds over IP. While technically possible, only the latest state-of-the-art systems are yet all IP. However during 2005 it is expected that several large systems will migrate in this direction. The whole cable TV industry is moving in the IP direction and so too will the routers. In the terminology of the Internet a “switch” has special hardware assistance to undertake high speed switching, while a router works at layer 3 of the OSI model and may have slower software store and forward control. These units in reality will be switches no routers, but often are formed from multi-layer switches. These not only have hardware to speed up the switching but also extensive software control for the flexibility of Internet protocols for streaming and security.

Notes:

Silicon-IPTV-Broadcast -50

Control Systems • Headend equipment must be controlled • Older systems use illuminated buttons • Latest units based on Windows PCs — Easy-to-use graphical user interfaces to configure equipment — Control conditional access and MPEG encoding rates — Broadcast equipment and receivers — Easy ‘drag and drop’ grouping feature for your receiver base — Graphical user interface to schedule receiver control and conditional access parameters on an — Immediate, one time, daily or weekly basis — On-line help — Password protection on user interfaces — Full redundancy and back-up options — Remote access of head-end control station

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -51

European companies currently lead the world in TV control systems. TANDBERG has a complete range of management system for both small and large MPEG-2 broadcast head-ends for configuration, system monitoring and redundancy. Ideally suited to controlling and monitoring satellite, cable and terrestrial super head-ends, especially where n+m multiplexing is required to save costs. Powerful remultiplexing capabilities make it perfect for digital turnaround applications. Cost effective device only control is available for the simpler regional head-end. These have recently been installed in the largest cable systems in the world and continue to dominate the control of state of the art headend control. The latest generation systems introduced in 2005 have the capability to work using all IP services. While the channel and studio side has been IP enabled on many systems for a year or so, now even distribution can be based on IP. The first All IP system deploying MP4 encoding for HDTV was installed in Europe during 2004. This is likely to spread throughout the whole industry over the next few years.

Notes:

Silicon-IPTV-Broadcast -51

Traditional Coaxial Cable Distribution Components

Splitter/Combiner

Tap

Attenuator Line Amplifiers

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Distribution Cable

Silicon-IPTV-Broadcast -52

RF cables are designed to carry RF signals from one point to another, not from one point to many. In other words, you can't run RF signals to multiple locations by wiring all the destinations in parallel. The reason is that the residential RF distribution scheme is based on 75 ohm terminated transmissions. Meaning that the transmitting side expects to see one, and only one, 75 ohm load on the other end of the cable. A splitter is a small device that has one input (the 75 ohm load) and 2 or more outputs, each driving a separate 75 ohm load. Essentially they are transformers that split the power in the input signal to multiple outputs, while maintaining the 75 ohm impedance. However, there is no free lunch! Every time you split an RF signal with a splitter, you drastically decrease the signal's strength. An RF signal only has so much power. Logic dictates that splitting this signal in two with a "passive" device will result in two signals that each have--at most--half of the original signal's strength. A combiner is simply a splitter hooked up backwards. It combines the channels on two or more separate cables onto one cable. The only drawback to this piece of magic, is that the cables being combined cannot have any channels in common with each other. The resulting signal on that channel would be trashed. Taps are similar to splitters, but are "wound crooked" so that the outputs are not equal in signal strength. The "through" output of a tap may only reduce the signal level by a very small amount, while the "tap" output is a small fraction of the signal level. Taps are primarily used in complex commercial distribution installations. Attenuators are simple "one in, one out" devices that reduce the signal strength. Attenuators come in various sizes and are useful when tuning up the video distribution system.

Notes:

Silicon-IPTV-Broadcast -52

Designing a Distribution System • The goal of design is to deliver good signal levels to each consumer • Cables, taps, splitters and combiners cause loss • Amplifiers increase signals but also add noise • Signal to noise ratio limits demodulation and thus the size of system Device

Loss (-dBmV)

2-Way Splitter/Combiner

4.0

3-Way Splitter/Combiner

6.5

4-Way Splitter/Combiner

8.0

8-Way Splitter/Combiner

12.0

100 ft RG6

4.0

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -53

The RF signal looses strength as it passes down the cable and through combiners and splitters. To counter this loss (or "attenuation") we use RF amplifiers. In the ideal RF distribution system, the signal level at each wall-plate should be about the same as the signal level coming in from the cable TV system or antenna. This ideal is called "unity gain." By applying a little math, and the table below, you can calculate the approximate losses and gains in your system to approach this goal. RF signal levels are measured in dBmV which is a logarithmic scale of signal relative to one millivolt. Since decibel values represent power levels, and are logarithmic, they can be calculated with simple addition and subtraction. The main thing to remember about dB (for short) values is that if the level drops below 0 dB (into the negative dB range), you are loosing actual signal information and no amount of amplification will be able to recover this lost information (picture quality.) In fact, amplifying a signal that is below 0 dB will usually make the picture worse since the noise is now being amplified and picked up. So you must insure that your signal levels never drop dangerously near 0 dB anywhere in your distribution system. This is why the main RF amplifier us usually connected near the input side of the distribution system; so the signal is boosted early, and never drops precariously low. The only way to actually measure the signal level is with an RF signal level meter specifically designed for this task. We ended up buying one (they go for $1000 up) that we rent out to our local customers that are having trouble tuning up their very complex systems. But most folks get by just fine by just doing the calculations up front. Cable TV companies are supposed to deliver around 15 dB of signal strength at the side of the house, but I've seen this range from below 0 to well over 25 dB. An antenna can deliver a wide range of signal strengths depending on the strength and distance of the stations. The optimum level at the wall-plate is between 8 and 15 dB

Notes:

Silicon-IPTV-Broadcast -53

Signal Transmission • Higher frequencies suffer more loss over coaxial calbes • This leads us to shift distribution from UHF down to VHF • The set top box can reverse the shift and deliver channels on their original frequency • Better performance can be obtained from digital coax and fiber

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -54

The signals provided in the cable cover a range of frequencies from 54-88 MHz (VHF/low channels 2 to 6), 88-108 MHz (FM radio), 174-216 MHz (VHF/high channels 7 to 13), to 470-806 MHz (UHF channels 14 to 69). Because cable doesn't carry actual UHF frequencies very efficiently (100 feet of RG-59 loses 80-90 percent of UHF), the UHF channels are converted by your cablevision company to a set of lower frequencies. This is why you need a converter box, or a "cable-ready" TV set. Whenever the signal is split, it becomes half as strong. It isn't like the three-way outlet of an extension cord where all the appliances receive the same voltage, as they would if connected directly to the wall. It's more like a farmer irrigating a crop by dividing a stream of water, every time it is split in two there is only half as much water. Connections from the splitter to wall outlets in your home are made with RG-59 coaxial cable. Putting the F-fittings on the ends of the cable is not difficult, but if you don't want to do this, just buy lengths of cable with the fittings already attached, and coil up any excess cable or stuff it into a wall cavity. The excess length may have a slight loss, but since it has been amplified anyway it won't make any noticeable difference. Unused outlets (outlets which are not connected to TV sets) used to require terminating resistors to prevent reflection of signals. This is something you might try if you find poor reception on only one or two channels using an older amplifier. The resistors are designed to plug directly into the unused outlets. Today you can find amplifiers that don't require terminators.

Notes:

Silicon-IPTV-Broadcast -54

Migration to Digital Fiber Systems • Optical systems also depend upon loss levels • Digital regeneration removes noise • Digital services can be delivered over larger area • More consistent quality is possible

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Digital Fiber Optic Transmitter

Silicon-IPTV-Broadcast -55

In the USA the The FCC has set the year 2006 as the deadline for broadcasters to switch from standard definition television (SDTV) to digital television (DTV) and high definition television (HDTV). Among the many advantages of this transition, transmission distance and repeaters (signal regenerators) do not affect the quality of digitized video. A visit to any major broadcast industry trade show, such as those sponsored by the National Association of Broadcasters (NAB) or Society of Motion Pictures and Television Engineers (SMPTE), reveals that cameras, tape decks, mixing boards, matrix switches, effects boxes, etc. operate the digital format. Fiber optics plays a big part in the move to the new television standards, providing the only viable means of signal transport by offering the bandwidth required for these television standards. Currently, analogue video signals can be carried over relatively long lengths of coax cable. With a bandwidth of only 4.5 MHz, analogue signals do not tax the limited bandwidth of coax cable, but even so, coax cable introduces a great deal of frequency dependent distortion requiring an equalization network. A digitized video signal's increased bandwidth usurps coax's ability to carry the new signal. A standard NTSC video signal typically requires a serial bit rate of 143.2 Mb/s. By contrast, highend HDTV standards require serial bit rates of 1,485 Mb/s. Coax cable can carry such high-speed digital data streams short distances, typically 300-600 meters for NTSC and 30-60 meters for HDTV. Fiber optics, on the other hand, can easily carry the full range of digital signals up to tens of thousands of meters. Figure 1 shows a typical digital fiber optic video transmitter.

Notes:

Silicon-IPTV-Broadcast -55

Fiber Optic Transmission

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -56

Some 10 billion digital bits can be transmitted per second along an optical fiber link in a commercial network, enough to carry tens of thousands of telephone calls. Hair-thin fibers consist of two concentric layers of high-purity silica glass the core and the cladding, which are enclosed by a protective sheath. Light rays modulated into digital pulses with a laser or a light-emitting diode move along the core without penetrating the cladding. The light stays confined to the core because the cladding has a lower refractive index—a measure of its ability to bend light. Refinements in optical fibers, along with the development of new lasers and diodes, may one day allow commercial fiber-optic networks to carry trillions of bits of data per second. Total internal refection confines light within optical fibers (similar to looking down a mirror made in the shape of a long paper towel tube). Because the cladding has a lower refractive index, light rays reflect back into the core if they encounter the cladding at a shallow angle (red lines). A ray that exceeds a certain "critical" angle escapes from the fiber (yellow line). STEP-INDEX MULTIMODE FIBER has a large core, up to 100 microns in diameter. As a result, some of the light rays that make up the digital pulse may travel a direct route, whereas others zigzag as they bounce off the cladding. These alternative pathways cause the different groupings of light rays, referred to as modes, to arrive separately at a receiving point. The pulse, an aggregate of different modes, begins to spread out, losing its well-defined shape. The need to leave spacing between pulses to prevent overlapping limits bandwidth that is, the amount of information that can be sent. Consequently, this type of fiber is best suited for transmission over short distances, in an endoscope, for instance.

Notes:

Silicon-IPTV-Broadcast -56

Fiber Types

Step Index Multimode Fiber

Graded Index Multimode Fiber

Single Mode Fiber

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -57

GRADED-INDEX MULTIMODE FIBER contains a core in which the refractive index diminishes gradually from the center axis out toward the cladding. The higher refractive index at the center makes the light rays moving down the axis advance more slowly than those near the cladding. Also, rather than zigzagging off the cladding, light in the core curves helically because of the graded index, reducing its travel distance. The shortened path and the higher speed allow light at the periphery to arrive at a receiver at about the same time as the slow but straight rays in the core axis. The result: a digital pulse suffers less dispersion. SINGLE-MODE FIBER has a narrow core (eight microns or less), and the index of refraction between the core and the cladding changes less than it does for multimode fibers. Light thus travels parallel to the axis, creating little pulse dispersion. Telephone and cable television networks install millions of kilometers of this fiber every year.

Notes:

Silicon-IPTV-Broadcast -57

Fiber Connectors

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -58

There is now a wide rance of connectors supported in the industry for fiber cables. ST and SC connectors are among the most well established within the industry.

Notes:

Silicon-IPTV-Broadcast -58

Fiber Cables

Indoor/Outdoor Tight Buffer

Indoor/Outdoor Breakout Cable

Aerial Cable/Self-Supporting

Armored Cable

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -59

Indoor/Outdoor Tight Buffer FIS now offers indoor/outdoor rated tight buffer cables in Riser and Plenum rated versions. These cables are flexible, easy to handle and simple to install. Since they do not use gel, the connectors can be terminated directly onto the fiber without difficult to use breakout kits. This provides an easy and overall less expensive installation. (Temperature rating -40ºC to +85ºC). Indoor/Outdoor Breakout Cable FIS indoor/outdoor rated breakout style cables are easy to install and simple to terminate without the need for fanout kits. These rugged and durable cables are OFNR rated so they can be used indoors, while also having a -40c to +85c operating temperature range and the benefits of fungus, water and UV protection making them perfect for outdoor applications. They come standard with 2.5mm sub units and they are available in plenum rated versions. Aerial Cable/Self-Supporting Aerial cable provides ease of installation and reduces time and cost. Figure 8 cable can easily be separated between the fiber and the messenger. Temperature range ( -55ºC to +85ºC) Armored Cable Armored cable can be used for rodent protection in direct burial if required. This cable is non-gel filled and can also be used in aerial applications. The armor can be removed leaving the inner cable suitable for any indoor/outdoor use. (Temperature rating -40ºC to +85ºC)

Notes:

Silicon-IPTV-Broadcast -59

Cable Construction Individual Fibers Distribution Cables Lightweight, flexible, small diameter cable design. Lower total installed costs. Color-coded 900 µm buffered fibers. 2 to 156 fiber counts Grouped Fibers

Breakout Cables Most rugged cable design. 2.5 mm subcable jacket for each fiber. Designed for direct lashing and "J" hook applications. 2 to 108 fiber counts

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -60

What's the best way to terminate fiber optic cable? That depends on the application, cost considerations and your own personal preferences. The following connector comparisons can make the decision easier. Epoxy & Polish Epoxy & polish style connectors were the original fiber optic connectors. They still represent the largest segment of connectors, in both quantity used and variety available. Practically every style of connector is available including ST, SC, FC, LC, D4, SMA, MU, and MTRJ. Advantages include: • Very robust. This connector style is based on tried and true technology, and can withstand the greatest environmental and mechanical stress when compared to the other connector technologies. • This style of connector accepts the widest assortment of cable jacket diameters. Most connectors of this group have versions to fit onto 900um buffered fiber, and up to 3.0mm jacketed fiber. • Versions are. available that hold from 1 to 24 fibers in a single connector. Installation Time: There is an initial setup time for the field technician who must prepare a workstation with polishing equipment and an epoxy-curing oven. The termination time for one connector is about 25 minutes due to the time needed to heat cure the epoxy. Average time per connector in a large batch can be as low as 5 or 6 minutes. Faster curing epoxies such as anaerobic epoxy can reduce the installation time, but fast cure epoxies are not suitable for all connectors. Costs: Least expensive connectors to purchase, in many cases being 30 to 50 percent cheaper than other termination style connectors. However, factor in the cost of epoxy curing and ferrule polishing equipment, and their associated consumables.

Notes:

Silicon-IPTV-Broadcast -60

Standard Single Mode Fiber Profile • Historically transmission at 1310 nm dominated • Characteristics of dispersion at 1500 nm needed addressing Attenuation

Standard Single-mode fiber Dispersion

+20

0.5

+10

0.4

0

0.3

-10

DWDM 0.2

-20

1300

1400 1500 Wavelength (nm)

Dispersion (ps/nmxkm)

Attenuatiom (dB/km)

0.6

1600

Single Channel Transmission at 1330 nm © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -61

The three principal windows of operation, propagation through a cable, are indicated. These correspond to wavelength regions where attenuation is low and matched to the ability of a Transmitter to generate light efficiently and a Receiver to carry out detection. The 'OH' symbols indicate that at these particular wavelengths the presence of Hydroxyl radicals in the cable material cause a bump up in attenuation. These radicals result from the presence of water. They enter the fiber optic cable material through either a chemical reaction in the manufacturing process or as humidity in the environment. The illustration shows the variation of attenuation with wavelength for, standard, single-mode fiber optic cable. There are 3 major windows for fiber. At about 700nm for multimode fibers silicon diodes similar to those used in a TV channel changer can be used to deliver low cost services over short ranges. For ranges of 5 km and above single mose fibers using transmitters at 1330nm or 1550 nm are used. In the 1550 nm band it is now possible to deploy different wavelengths over the same fiber with potentially up to 100 wavelengths. Eventually it is though likely that we will be able to deliver as many as 240 wavelengths each carrying 2.5 Gbit/s on each fiber.

Notes:

Silicon-IPTV-Broadcast -61

Simple Passive Fiber Network • Traditional fiber connection requires at least one fiber per subscriber — Couplers at each end attach transceiver • Heavy on fiber and transceiver costs but resilient solution

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -62

The Transmitter was typically designed using discrete electrical and Electro-optical devices. This very quickly gave way to designs based upon hybrid modules containing integrated circuits, discrete components (resistors and capacitors) and optical source diodes (light emitting diodes-LED's or laser diodes). The modulation function was generally performed using separate integrated circuits and everything was placed on the same printed circuit board. By the 1980's higher and higher data transmission speeds were becoming of interest to the data link architect. The design of the Transmitter while still generally customized became more complex to accommodate these higher speeds. A greater part of the Transmitter was implemented using VLSI circuits and attention was given to minimizing the number of board interconnects. Intense research efforts were undertaken to integrate the optical source diode and the transistor level circuits needed for modulation on a common integrated circuit substrate, without compromising performance. At present, the Transmitter continues to be primarily designed as a hybrid unit, containing both discrete components and integrated circuits in a single package. By the late 1980's commercially available Transmitter's became available. As a result, the link design could be kept separate from the Transmitter design. The link architect was relieved from the need to do high-speed circuit design or to design proper bias circuits for optical diodes. The Transmitter could generally be looked at as a black box selected to satisfy certain requirements relative to power, wavelength, data rate, bandwidth, etc. This is where the situation remains today.

Notes:

Silicon-IPTV-Broadcast -62

Active Fiber Distribution • Active distribution can significantly reduce fiber costs — Less fiber and fewer transceivers • Active plant outside local exchange reduces resilience

Last half Kilometre could be Copper Or fiber

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -63

To do a proper selection of a commercially available Transmitter you have to be able to know what you need in order to match your other link requirements. You have to be able to understand the differences between Transmitter candidates. There are many. We can not begin to approach this in total. However, we can look at this in a limited way. Transmitter candidates can be compared on the basis of two characteristics. Transmitter candidates can be compared on the basis of the optical source component employed and the method of modulation. By delivering multiple channels on a single distribution fiber we can reduce the range of the final fiber section and reduce the total number of fibers over most of the distribution. Near to the user, perhaps a few hundred meters away, a powered device will be deployed to deliver the final service. The last few hundred meters may be over fiber or over copper. Indeed by using UTP for the last few hundred meters it is possible to deploy xDSL technology.

Notes:

Silicon-IPTV-Broadcast -63

Passive Network With Advanced Splitters • Advanced splitters divide on wavelength • Only passive components as outside plant

All Fiber with different wavelengths for each subscriber

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -64

Eventually it should be possible to deliver a fully passive optical solution. Each distribution would be over a different wavelength controlled optically at a passive splitter using a control wavelength. This would deliver two way channels to each user if required enabling not just TV but interactive information services at multimegabit speeds.

Notes:

Silicon-IPTV-Broadcast -64

Technology: Active Ethernet and PON

Considerations: CAPEX/OPEX, Reliability, Standardization, Scalability, Futureproofing

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -65

Notes:

Silicon-IPTV-Broadcast -65

Standard Single Mode Fiber Profile • Historically transmission at 1310 nm dominated • Characteristics of dispersion at 1500 nm needed addressing Attenuation

Standard Single-mode fiber Dispersion

+20

0.5

+10

0.4

0

DWDM

0.3

-10

0.2

-20

1300

1400 1500 Wavelength (nm)

Dispersion (ps/nmxkm)

Attenuatiom (dB/km)

0.6

1600

Single Channel Transmission at 1330 nm © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -66

Standard single mode fiber will carry signals at many different wavelengths, but there are particular peaks in the loss curve caused by water and other molecules penetrating the glass. The attenuation in the fiber will be minimised at particular wavelengths. These are called “windows”. 1330 and 1550 nano-meters are particularly important values.

Notes:

Silicon-IPTV-Broadcast -66

Actual Fiber Performance

1600

G bit/s per fiber

800 400 200

100

Optimal Operating Region

Actual Single Mode Fiber Performance Bit Rate < 10 Gbit/s Unamplified

2.5 10

100

500

2000

10000

Transmission Distance in km © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -67

In reality fibres can now be constructed to carry data at very high speeds and over very very long distances. However as the data rate and distance between powered repeaters increases so does the cost. The economical operating range is typically measured in 10s or hundreds of Gbit/s and up to about 80 km in length.

Notes:

Silicon-IPTV-Broadcast -67

Fiber for Course Wavelength Division Multiplexing (CWDM)

Attenuation

Dispersion

+20

SSMF

0.5

+10

0.4

0

0.3

-10 LWPF

0.2

1300

1400 1500 Wavelength (nm)

-20

Dispersion (ps/nmxkm)

Attenuatiom (dB/km)

0.6

1600

Low Water Peak Fiber allows CWDM over full available spectrum

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -68

By using different wavelengths of light down the same fiber it is possible to increase the data carried. Course Wavelength Division Multiplexing can be undertaken on most fibers, and by improving the water peak up to about 8 wavelengths can be carried.

Notes:

Silicon-IPTV-Broadcast -68

Long Haul Fiber With Dense WDM

Attenuation

Standard Single-mode fiber Dispersion

+20

0.5

+10

0.4

0

0.3 0.2

-10

Long Haul Fiber

1300

-20

1400 1500 Wavelength (nm)

Dispersion (ps/nmxkm)

Attenuatiom (dB/km)

0.6

1600

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -69

Using much more precision and deploying very narrow bands of light it is possible to pack many frequencies into the 1550 nm band. This is known as dense wavelength division multiplexing.

Notes:

Silicon-IPTV-Broadcast -69

ITU-T Standard Spacing for DWDM Channels • There is now an ITU-T standard for DWDM with 240 different wavelengths Standard ITU Wavelengths for DWDM 50 GHz, and 100 GHz Spacing Lα

Lβ

Cα

Cβ

Sα

Sβ

THz 186.00 186.10 186.20 186.30 186.40 186.50 186.60 186.70 186.80

nm 1611.79 1610.92 1610.06 1609.19 1608.33 1607.47 1606.60 1605.74 1604.88

THz 186.05 186.15 186.25 186.35 186.45 186.55 186.65 186.75 186.85

nm 1611.35 1610.49 1609.62 1608.76 1607.90 1607.04 1606.17 1605.31 1604.46

THz 191.00 191.10 191.20 191.30 191.40 191.50 191.60 191.70 191.80

nm 1569.59 1568.77 1567.95 1567.13 1566.31 1565.50 1564.68 1563.86 1563.05

THz 191.05 191.15 191.25 191.35 191.45 191.55 191.65 191.75 191.85

nm 1569.18 1568.36 1567.54 1566.70 1565.90 1565.09 1564.27 1563.45 1562.64

THz 196.00 196.10 196.20 196.30 196.40 196.50 196.60 196.70 196.80

nm 1529.55 1528.77 1527.99 1527.22 1526.44 1525.66 1524.89 1524.11 1523.34

THz 196.05 196.15 196.25 196.35 196.45 196.55 196.65 196.75 196.85

nm 1529.16 1528.38 1527.60 1526.83 1526.05 1525.27 1524.50 1523.72 1522.95

190.50 190.60 190.70 190.80 190.90

1573.71 1572.89 1572.06 1571.24 1570.42

190.55 190.65 190.75 190.85 190.95

1573.30 1572.48 1571.65 1570.83 1570.01

195.50 195.30 195.70 195.80 195.90

1533.47 1532.68 1531.90 1531.12 1530.33

195.55 195.65 195.75 195.85 195.95

1533.07 1532.29 1531.51 1530.72 1529.94

200.50 200.60 200.70 200.80 200.90

1495.22 1494.48 1493.73 1492.99 1492.25

200.55 200.65 200.75 200.85 200.95

1494.85 1494.11 1493.36 1492.62 1491.88

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -70

There is now an ITU-T standard that allows 240 different wavelengths on the same fiber. No implementations of this number yet exist but there are examples of as many as 80 wavelengths each running 2.5 Gbit/s on a single fiber pair.

Notes:

Silicon-IPTV-Broadcast -70

SONET/SDH • Synchronous Optical Network (SONET) was developed in the early 1990s • Known as SDH Internationally for rates above 150 Mbit/s — OC = optical carrier — STM = synchronous transport module — STS = synchronous transport signal

SONET (ANSI)

Mbit/s

STS-1 or OC1

51.84

STS-3 or OC3

155.52

STM-1

STS-12 or OC12

622.08

STM-4

STS-24 or OC24

1244.16

STS-48 or OC48

2488.32

STM-16

STS-192 or OC192

9953.28

STM-64

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

SDH (ITU)

Silicon-IPTV-Broadcast -71

SONET was developed first in the USA during the early 1990s. The aim was to produce a transmission system that could run at much higher rates that PDH, carry any kind of traffic and become a world standard rather than just a North American one. The lowest rat of SONET,51.84 Mbit/s is arranged so that it could carry a DS3 at 45 Mbit/s and have enough margin in bit rate to allow for slippage where different clocks are used. The next rate of 155.5 Mbit/s was selected so that it could carry an E4 at 140 Mbit/s with enough margin again to allow for clock slippage. From 155.52 Mbit/s SONET and the international equivalent standard, Synchronous Digital Hierarchy are essentially the same. Higher rates are constructed by selecting multiples of four times for SDH. Notice that the multiples of bit rates are exact with no additional framing overhead used in the PDH hierarchy. SONET can be carried over any media, so the standard name for the rate starts STS. If it runs over fiber the rate starts OC. SDH is only defined for fiber so STM-1 is identical in rate to OC3.

Notes:

Silicon-IPTV-Broadcast -71

SDH Networks 622 622 622

Originating subscriber

155 140

34 2

155 140 34 2

34 2

34 2

34 34

155 140 34 2

Break BBX 155 140 34 2

34 2

Receiving subscriber 622 622 622

155 Mbit/s 622 Mbit/s 2488 Mbit/s

WBX 622-Mbit/s synchronous add/drop multiplexer (ADM) 155-Mbit/s synchronous add/drop multiplexer (ADM) 2.5-Gbit/s synchronous FOTS 622-Mbit/s synchronous FOTS Network terminals Network management center

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -72

SDH networks can be constructed from many SDH components. Synchronous Add/Drop multiplexers can insert and remove synchronous payloads as multiples of E1, E2, E3 or E4 as required. These would be dropped initially into STM-1 or STM-4 services. Wideband multiplexers can combine STM-1s and lower rates into STM-4 services at 622 Mbit/s. Broadband multiplexers can then combine STM-4s into STM-16s.

Notes:

Silicon-IPTV-Broadcast -72

Network Topologies • Point-to-Point

T1 T3

ADM (terminal mode)

ADM (terminal mode)

T1 T3

Dial Single Mode Fiber

• Bus — Add Drop Multiplexers can add in and drop off SPEs as required

T1 T3

ADM (terminal mode)

ADM

T3

ADM (terminal mode)

T1 T3

T1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -73

With SDH services can run either point to point or even in a bus structure with Add/Drop multiplexers inserting new payloads and removing others for local delivery. This is much simpler and more reliable than using banks of multiplexers needed with PDH services which had to be demultiplexed down to separate E1 services before dropping off and inserting for remultiplexing back up to the line rates.

Notes:

Silicon-IPTV-Broadcast -73

SDH Rings • Ring (single or dual) — can provide fault tolerance — Becoming the most popular SDH topology

E1 E3

E1

E1 E3

ADM

E3

E3 E1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -74

Perhaps the most important topology however is the SDH ring. This enables groups of multiplexers to be interconnected with pairs of fibers where one of the two is used and the other is a standby. In the event of a failure of a pair the service can be reconfigured to maintain delivery.

Notes:

Silicon-IPTV-Broadcast -74

Automatic Protection Switching • SONET/SDH includes standardized mechanisms for Automatic Protection Switching (APS) • Benefits of APS — Faster restoration of service when failure occurs (or service deteriorates) – Optical path may be severed – Electronic equipment may fail or lose power – Standardization allows APS in a multivendor environment — Protection switching may be used during maintenance or testing • APS requires a pre-provisioned protection facility (backup route) — Operates using section (multiplexer section) APS channels

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -75

The signaling overhead of the regenerator section and the multiplexer section allow for alarms to be transferred between devices that identify failures and the management center. It is then possible with Automatic Protection Switching (APS) to instruct a device to reconfigure itself automatically in the event of failure within 50 msec.

Notes:

Silicon-IPTV-Broadcast -75

Self Healing Rings

Alarm !

Working backup

No data

Data

Break Data

Fiber Break Causes Alarm

Normal Operation

APS APS

Automatic Rerouting Re-establishes Service © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -76

With APS implemented throughout a ring it is possible to produce self healing rings. Typically a network would be constructed by interconnecting these self healing rings at two or more points so producing networks which have multiple paths between sites each able to offer highly reliable services.

Notes:

Silicon-IPTV-Broadcast -76

Broadcast Distribution Systems

Cable TV Delivery Systems Terrestrial Delivery IP Delivery Encoding Methods Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -77

Notes:

Silicon-IPTV-Broadcast -77

Over-The Air Broadcasting • Transmissions are sent over radio links — Generally dedicated licensed channels in the VHF or UHF Bands — Range is limited to line of sight – Over flat terrain may be 50 km – In hilly or mountainous areas range my be only a few km — Multiple frequencies used to deliver each channel in adjacent areas

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -78

There are various bands on which televisions operate depending upon the country. The VHF and UHF signals in bands III to V are generally used. Lower frequencies do not have enough bandwidth available for television. Although the BBC initially used Band I VHF at 45 MHz, this frequency is no longer in use for this purpose. Band II is used for FM radio transmissions. Higher frequencies behave more like light and do not penetrate buildings or travel around obstructions well enough to be used in a conventional broadcast TV system, so they are generally only used for satellite broadcasting, which uses frequencies around 10 GHz. TV systems in most countries relay the video as an AM (amplitude-modulation) signal and the sound as a FM (frequencymodulation) signal. An exception is France, where the sound is AM. Digital Terrestrial TV is transmitted on radio frequencies that are similar to standard analog television, with the primary difference being the use of multiplex transmitters to allow reception of multiple channels on a single frequency range (such as a UHF or VHF channel). The amount of data that can be transmitted (and therefore the number of channels) is directly affected by the modulation method of the channel. The modulation method in DVB-T is COFDM with either 64 or 16 state Quadrature Amplitude Modulation (QAM). In general a 64QAM channel is capable of transmitting a greater bitrate, but is more susceptible to interference. 16 and 64QAM constellations can be combined in a single multiplex, providing a controllable degradation for more important programme streams. This is called hierarchical modulation. The DVB-T standard is not used for terrestrial digital television in North America. Instead, the ATSC standard calls for 8VSB modulation, which has similar characteristics to the vestigial sideband modulation used for analogue television. This provides considerably more immunity to interference, and effectively does not provide for single-frequency network operation (which is in any case not relevant in the United States). Both systems use the MPEG-2 transport stream and video codec; they differ significantly in how related services (such as multichannel audio, captions, and program guides) are encoded.

Notes:

Silicon-IPTV-Broadcast -78

Digital Terrestrial in UK • Receiving digital terrestrial television in the UK needs a set-top box • There are 6 multiplexes labelled 1, 2, A, B, C and D • Each multiplex is an error-protected bi stream of 18 or 24 megabits per second — BBC controls Multiplex 1 — ITV and Chnnel 4 Multiplex 2 — ITV Digital controlled other services until its collapse in May 2002 — The Freeview consortium stepped in to save Digital services — Multiplex A is now largely controlled by SC4 and what remains of ONDigital — BBC acquired control of one Multiplex (B) for its own services — Crown Castle/National Grid the other two (C & D) for commercial services

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -79

Digital terrestrial television in the United Kingdom is made up of over fifty primarily free-to-air television channels (including all six non-RSL analogue stations) and over twenty radio channels primarily from the Freeview branded and Top Up TV services. It is intended that digital terrestrial television will completely replace analogue television in the UK by 2012. Digital terrestrial television launched in the UK on 15 November 1998 (just after digital satellite television on 1 October 1998). The technology required that the UK government license the broadcast of channels in six groups, or multiplex (usually abbreviated to 'mux') labelled 1, 2, A, B, C, and D[1]. Each multiplex is an error-protected bitstream of 18 or 24 megabits per second, which can be used for almost any combination of digitally-represented video, audio and data. The DVB-T standard provides a multiplex service that can make trade-offs between the number of services and the picture and audio subjective quality. The Independent Television Commission (ITC) allocated each existing analogue terrestrial channel half the capacity a multiplex each. This meant the BBC got a multiplex to themselves (Multiplex 1), ITV and Channel 4 shared Multiplex 2 (though 10% of the capacity was given to Teletext Limited) and Five and S4C shared Multiplex A. The remaining space (Muliplexes B, C and D) was then auctioned off. A consortium made up of Granada and Carlton (members of the ITV network, which have now merged to form ITV plc) and BSkyB successfully bid for these licences, and set-up the subscription ONdigital service, (though BSkyB left the consortium prior to launch).

Notes:

Silicon-IPTV-Broadcast -79

DVB-T Services – Mux 1 and 2 • Multiplex 1 — Operated by the BBC; broadcasts nationwide in 16QAM mode at 18 megabits/second — TV: BBC One (regional variation), BBC Two (national variation), BBC Three, CBBC Channel, BBC News 24 — Radio: BBC Radio Wales (Wales only), BBC Radio Scotland (Scotland only), BBC Radio Ulster (Northern Ireland only), BBC Radio Cymru (Wales only), BBC Radio nan Gaidheal (Scotland only), BBC Radio Foyle (Northern Ireland Only) — Text/Interactive: BBCi, The Engineering Channel • Multiplex 2 — Operated by Digital 3&4 (an ITV/Channel 4 consortium); broadcasts nationwide in 64QAM mode at 24 megabits/second — TV: ITV1 (regional service), Channel 4, ITV2, ITV3, More4, E4, ITV4, Film4+1, Setanta Sports 1*, CITV Channel — Radio: U105 (Northern Ireland only), Heart (except Scotland), Radio Music Shop (except Scotland) — Text/Interactive: Teletext, Teletext Holidays (Wales only), Teletext Cars, Teletext on 4, Teletext on ITV * Pay TV Services © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -80

Notes:

Silicon-IPTV-Broadcast -80

DVB-T Services – Mux A and B • Multiplex A — Operated by SDN (owned by ITV plc); broadcasts nationwide in 64QAM mode at 24 megabits/second — TV: S4C Digidol (Wales only), Five, TeleG (Scotland only), ABC1 (except Wales), QVC, UKTV Gold*, bid tv, price-drop tv, TCM*, UKTV Style*, Discovery Channel*, British Eurosport*, Five US, Five Life, Top Up Anytime 1, Top Up Anytime 2, Top Up Anytime 3, Discovery Real Time*, Cartoon Network*, S4C2 (Wales only), Teachers' TV, Television X* — Radio: BBC Radio 1, BBC Radio 2, BBC Radio 3, BBC Radio 4, Mojo (except Wales), Heat (except Wales) — Text/Interactive: Teletext Holidays (except Wales), Teletext Games, Top Up TV Active • Multiplex B — Operated by the BBC; broadcasts nationwide in 16QAM mode at 18 megabits/second — TV: BBC Four, CBeebies, BBC Parliament, Community Channel — Radio: BBC 1Xtra, BBC Radio Five Live, BBC Five Live Sports Extra, BBC 6 Music, BBC 7, BBC Asian Network — Text/Interactive: BBCi (301, 302, 303), BBC Parliament (redundant ¼ screen service), The Engineering Channel * Pay TV Services © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -81

Notes:

Silicon-IPTV-Broadcast -81

DVB-T Services – Mux C and D • Multiplex C — Operated by National Grid Wireless; broadcasts nationwide in 16QAM mode at 18 megabits/second — TV: Sky Three, UKTV History, E4+1, SmileTV, Sky News, Sky Sports News — Radio: talkSPORT, 3C, Premier Christian Radio, Virgin Radio — Text/Interactive: Sky Text, TVTV Digital • Multiplex D — Operated by National Grid Wireless; broadcasts nationwide in 16QAM mode at 18 megabits/second — TV: The Hits, UKTV Bright Ideas, Ftn, TMF, Ideal World, Film4, ITV Play — Radio: BBC World Service, The Hits Radio, Smash Hits, Kiss 100, Magic 105.4, Q, Oneword, 102.2 Smooth FM, Kerrang! — Text/Interactive: 4TVInteractive

* Pay TV Services © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -82

Notes:

Silicon-IPTV-Broadcast -82

Multiplexing Technology • Some multiplexes carry more services than others • Some channels share bandwidth as channels transmit at different times • Different channels use different bandwidths — For example BBC1 uses 4.4 Mbit/s — Sky Sports News uses only 2 Mbit/s • There are three basic modulation schemes currently in use in the UK; — QPSK (only used for tests in the Oxford and London areas) — 16 QAM — 64 QAM • Each with a progressively higher bitrate and thus SNR — The cost is of progressively higher likelihood of signal degradation • Currently multiplexes 2 and A use 64 QAM and the others 16 QAM

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -83

Some of these multiplexes carry a much larger number of services than others for various reasons. Firstly, a number of services share bandwidth — so some channels turn off when others are on (for example one will never see CBeebies and BBC Four on air at the same time, as they use the same space in Multiplex B, with CBeebies broadcasting from 6am until 7pm and BBC Four from 7pm onwards; the situation is the same for CBBC and BBC Three). In addition, some multiplexes have fewer channels so as to allocate more data to fewer services, thus ensuring higher quality (for example, BBC One on Multiplex 1 is carried as a 4.4 Megabit stream, while Sky Sports News typically uses 2 Megabits per second). On top of this, the modulation of the multiplexes can be varied to squeeze higher digital bitrates out of the same portion of the electromagnetic spectrum. This comes at the cost of making it harder to get a good signal. There are three basic modulation schemes currently in use in the UK; in order of bandwidth efficiency, they are: QPSK (only used for tests in the Oxford and London areas), 16 QAM and 64 QAM, each with a progressively higher bitrate, at the cost of progressively higher likelihood of signal degradation. Currently multiplexes 2 and A use 64 QAM (and are consequently more prone to poor reception) while the other multiplexes all currently use 16 QAM. Furthermore, multiplexes can make use of statistical multiplexing at the MPEG video coder whereby the bitrate allocated to a channel within the multiplex can vary dynamically depending on how difficult it is to code the picture content at that precise time, and how much demand there is for bandwidth from other channels. In this way, complex pictures with lots of detail may demand a higher bitrate at one instant and this can result in the bitrate allocated to another channel in the same multiplex being reduced if the second channel is currently transmitting pictures which are easier to code, with less fine detail. The only channel on the DTT system not to use statistical multiplexing, i.e. has a constant bit rate, is BBC One. This is so the English Regions and Nations can perform a simple transmultiplex, or T-Mux, operation and insert their local version of BBC One over the London feed straight into the existing BBC Multiplex 1 without having to re-code the entire multiplex at each regional centre, requiring specialist (and costly) equipment at several locations.

Notes:

Silicon-IPTV-Broadcast -83

LCN1

Channel

Notes

Multiplex

1

BBC One

Includes regional variations

1

2

BBC Two

Includes regional variations; digital variations from analogue in Wales and Northern Ireland

1

ITV1

In England, Wales, Southern Scotland, the Isle of Man and the Channel Islands2

STV

In Central and Northern Scotland2

UTV

In Northern Ireland2

Channel 4

Except Wales

2

S4C Digidol

Wales only

A3

3

4

2

5

Five

A3

6

ITV2

2

7

BBC Three

Broadcasts 1900-0600

1

Channel 4

Wales only

2

TeleG

Scotland only; broadcasts 1800-1900

A

9

BBC Four

Broadcasts 1900-0600

B

10

ITV3

11

Sky Three

12

UKTV History

13

More4

2

14

E4

2

15

ABC1

Not available in Wales; broadcasts 0600-1800

A

16

QVC

Reduced hours in Wales (not broadcast 0900-1700 Tuesday-Thursday)

A

8

2 C Broadcasts 0500-0100

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

C

Silicon-IPTV-Broadcast -84

Logical Channel Number ITV1 is the brand name for 12 of the 15 regional ITV Network franchises for England, Wales, southern Scotland, the Isle of Man and the Channel Islands. Each of these 12 franchises has a separate brand name used prior to local programming, see ITV1. STV is the brand name for the franchises for central and northern Scotland. UTV operates the franchise for Northern Ireland. All 15 franchises broadcast 0925-0600; GMTV operates the franchise for national breakfast television and broadcasts 0600-0925. Five, S4C and S4C2 will move to a public service multiplex at the start of digital switchover, using the bandwidth created by switching from 16QAM to 64QAM mode, so will be transmitted from all 1,154[7] UK transmitters. Multiplexes A, C and D will only be transmitted from the current 80 transmitters after switchover but with higher powered signals (and in 64QAM mode).

Notes:

Silicon-IPTV-Broadcast -84

17

UKTV Gold

18

The Hits

Top Up TV; broadcasts 1600-0100

A

19

UKTV Bright Ideas

Broadcasts 0600-1800

D

20

Ftn

Broadcasts 1800-0600

D

21

TMF

22

Ideal World

23

bid tv

24

price-drop tv

25

TCM

Top Up TV; broadcasts 1900-0055

A

26

UKTV Style

Top Up TV; broadcasts 1300-1600

A

27

Discovery Channel

Top Up TV; broadcasts 1800-2300

A

28

ITV4

Broadcasts 1800-0600

2

29

Film4

D

30

E4+1

C

31

ITV Play

D

32

Film4+1

2

33

British Eurosport

Top Up TV; broadcasts 1300-1800

A

34

Setanta Sports 1

Pay-per-view service (from Top Up TV); broadcasts dependent on SPL match times

2

35

Five US

36

Five Life

Broadcasts 0500-2300

A

37

SmileTV

Broadcasts 0100-0500

C

D

D D Reduced hours in Wales (only broadcasts 0600-1900)

A A

A

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -85

Logical Channel Number ITV1 is the brand name for 12 of the 15 regional ITV Network franchises for England, Wales, southern Scotland, the Isle of Man and the Channel Islands. Each of these 12 franchises has a separate brand name used prior to local programming, see ITV1. STV is the brand name for the franchises for central and northern Scotland. UTV operates the franchise for Northern Ireland. All 15 franchises broadcast 0925-0600; GMTV operates the franchise for national breakfast television and broadcasts 0600-0925. Five, S4C and S4C2 will move to a public service multiplex at the start of digital switchover, using the bandwidth created by switching from 16QAM to 64QAM mode, so will be transmitted from all 1,154[7] UK transmitters. Multiplexes A, C and D will only be transmitted from the current 80 transmitters after switchover but with higher powered signals (and in 64QAM mode).

Notes:

Silicon-IPTV-Broadcast -85

38

Top Up TV Anytime 1

Subscription service; not yet launched

A

39

Top Up TV Anytime 2

Subscription service; not yet launched

A

40

Top Up TV Anytime 3

Subscription service; not yet launched

A

42

Discovery Real Time

Top Up TV; broadcasts 0600-1200

A

43

Top Up TV Promo

Not yet launched

A

70

CBBC Channel

Broadcasts 0600-1900

1

71

CBeebies

Broadcasts 0600-1900

B

72

Cartoon Network

Top Up TV; broadcasts 0900-1100

A

75

CITV Channel

Broadcasts 0600-1800; not broadcast while Setanta Sports 1 is on air

2

80

BBC News 24

1

81

BBC Parliament

B

82

Sky News

C

83

Sky Sports News

86

S4C2

Wales only; broadcasts 0900-1700 Tuesday-Thursday

A3

87

Community Channel

Broadcasts 0600-0900

B

88

Teachers' TV

Broadcasts 1100-1300

A

97

Television X

Top Up TV (additional subscription); broadcasts 2300-0500

A

98

Red Hot TV

Pay-per-view service; placeholder (no longer broadcasting)

A

501

BBC HD Trial

BBC High Definition Test Channel; London only

CH31

503

ITV HD Trial

ITV High Definition Test Channel; London only

CH27

504

Channel 4 HD Trial

C4 High Definition Test Channel; London only

CH27

505

Five HD Trial

Five High Definition Test Channel; London only

CH27

C

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -86

Logical Channel Number ITV1 is the brand name for 12 of the 15 regional ITV Network franchises for England, Wales, southern Scotland, the Isle of Man and the Channel Islands. Each of these 12 franchises has a separate brand name used prior to local programming, see ITV1. STV is the brand name for the franchises for central and northern Scotland. UTV operates the franchise for Northern Ireland. All 15 franchises broadcast 0925-0600; GMTV operates the franchise for national breakfast television and broadcasts 0600-0925. Five, S4C and S4C2 will move to a public service multiplex at the start of digital switchover, using the bandwidth created by switching from 16QAM to 64QAM mode, so will be transmitted from all 1,154[7] UK transmitters. Multiplexes A, C and D will only be transmitted from the current 80 transmitters after switchover but with higher powered signals (and in 64QAM mode).

Notes:

Silicon-IPTV-Broadcast -86

DVB-T Testing in Ireland • Multiplex 1 — Reserved for existing terrestrial services • Television — RTÉ One, RTÉ Two, TV3 Ireland, TG4 • Radio — RTÉ Radio 1 FM, RTÉ Radio 1 AM, RTÉ 2FM, Raidió na Gaeltachta, RTÉ Lyric FM, Today FM

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -87

Trials began again on August 4, 2006, with a high power multiplex ("Mux 1") transmitting on channel 54 (-167 kHz offset) from Three Rock Mountain. Transmission parameters are 16 QAM, 3/4 forward error correction and a 1/32 guard interval, with an 8k FFT. Transmissions from the Clermont Carn transmitter began on August 11 on channel 53, meaning coverage is provided to Dublin city and county as well as most of the north-east of Ireland — approximately 1/3 of the population. The trial officially launched on August 16, 2006, with seven months testing expected prior to the introduction of extra content. Transmissions are unencrypted and use standard coding modes - most modern set-top boxes designed for Freeview in the UK are fully compatible, and many have purchased Freeview boxes from Northern Ireland to avail of the trial service. The service is however, legally restricted to 1000 selected users. 4 multiplexes have been announced for the trial, with Mux 1 reserved for existing nationally licenced television and radio services, Mux 2 and half of Mux 3 reserved for selected "content managers", for which advertisements were placed in the press, and the remainder of Mux 3 retained for future use. Mux 4 will be reserved for "innovative content". Ireland's frequency plans allow for 4 multiplexes nationally (6 on main transmitters) until analogue switchoff, and 9 - 8 UHF, 1 VHF - nationally after switchoff. 9 entities have applied to become content managers. EPG information is currently provided for approximately one week ahead. It seems very likely that Channel 6 will eventually become available on the platform, as they have applied to manage the entire network. Some Sky Digital channels may also be available, most likely Sky News, and possibly Sky Sports News. However a terrestrial service may force Sky to register the channels with BCI.

Notes:

Silicon-IPTV-Broadcast -87

Wireless Standards

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -88

There are 4 major classifications of wireless services based upon range. Broadcast TV has generally evolved from the WAN area while LANs are where data services started. Convergence of the technology now makes it feasible to deliver TV over any of these technologies.

Notes:

Silicon-IPTV-Broadcast -88

Multipoint Distribution Services Two versions of MDS have evolved: • LMDS – Local MDS — Single-duplex channel to a local hub — Generally uses 28, 35, 38 GHz bands — Can provide high speed data where wired infrastructure is inadequate — Typical range: 5–8 km • MMDS – Multichannel MDS — Multiple simplex or duplex channels to a local hub — Generally employed in 2.4, 5 GHz bands — CATV distribution over MMDS — Typical range: 55 km • Wimax: IEEE 802.16 is addressing physical/MAC layer, and frequency coexistence standards

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -89

In the USA and Canada wireless local loop technologies have been used for some time.

Notes:

Silicon-IPTV-Broadcast -89

Example MMDS System Omni transmit antenna LNB

Satellite Receivers HPA

Decoder

Modulation & Encryption

Tree top House top Receive Antenna (may be omni or directional)

Decoded Receiver

Frequency Translation

HPA = High Power Amplifier LNB = Low Noise Block Convector © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -90

Notes:

Silicon-IPTV-Broadcast -90

Typical Wireless Loop Installation

M

av ow icr

e

RST System controller

RST

RST

Fiber Local Concentrator exchange

Cell site

System Cell controller site

Fax machine

RST = radio subscriber terminal

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -91

Notes:

Silicon-IPTV-Broadcast -91

Existing Technologies • Some suppliers use cellular equipment to provide wireless loops

Vendor

Product

Alcatel

7390 LMDS

AT&T

Wireless Subscriber System

Nokia

DAXnode 2000

Ericsson

RAS 1000

Motorola

WiLL

Northern Telecom

DMS-MTX and 800

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -92

Most major telecom vendors have developed wireless loop technologies. However these are converging onto a common future set of standards.

Notes:

Silicon-IPTV-Broadcast -92

Licensed and Licensed-exempt Spectrum

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -93

WiMAX will bring this technology closer to a common reality across the world. The frequencies of use will differ but in Europe frequencies in the 3.5 GHz band will be used.

Notes:

Silicon-IPTV-Broadcast -93

IEEE 802 LANs • IEEE 802 LANs started with the introduction of Ethernet — 10 Mbit/s Bus LAN based upon 0.4 inch yellow coaxial cable — Developed by Xerox in 1979 — Limited to about 1.5 km

802.2 Logical Link Control 802.1 Management

802.10 Security

• IEEE founded the 802 committee to standardize LANs in 1980

Data

802.1d Bridging

Link Layer

802.3

802.4

802.5

802.6

CSMA/CD

Token

Token

DQDB

Bus

Bus

Ring

MAN

802.11 Wireless LAN

802.16 WiMAX Wireless Access

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

802.20 Wireless Broadband

Physical Layer

Silicon-IPTV-Broadcast -94

IEEE 802 standards generally provide the standardization of protocols and services at the physical and data link layers. The physical layer defines the transmission of bits and the hardware elements of connection. The data link layer is responsible for the transmission of frames of data, error detection within those frames and the sharing of access to the physical transmission medium.

Notes:

Silicon-IPTV-Broadcast -94

Broadcast Distribution Systems

Cable TV Delivery Systems Terrestrial Delivery IP Delivery Encoding Methods Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -95

Notes:

Silicon-IPTV-Broadcast -95

Set Top Boxes • Set top boxes are evolving to increase their functionality • Initially they provided Cable Decoder Free to air Digital

Combination with Personal Video Recorder with HDD

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -96

Cable services generally terminate at the user site on a set top box. The architecture of these is changing to add more processing power and faster, more standardised protocols.

Notes:

Silicon-IPTV-Broadcast -96

European Telecommunications Standards Institute

• European Standards • Mobile Phone (GSM/UMTS) • Tracks 3GPP • Fixed Line Standards • IP Multimedia Services (IMS) • TISPAN for fixed • DVB • Standards download free!

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -97

The European Telecommunications Standards Institute (ETSI) is an independent, non-profit organization, whose mission is to produce telecommunications standards for today and for the future. Based in Sophia Antipolis (France), the European Telecommunications Standards Institute (ETSI) is officially responsible for standardization of Information and Communication Technologies (ICT) within Europe. These technologies include telecommunications, broadcasting and related areas such as intelligent transportation and medical electronics. ETSI unites 654 members from 59 countries inside and outside Europe, including manufacturers, network operators, administrations, service providers, research bodies and users - in fact, all the key players in the ICT arena. ETSI plays a major role in developing a wide range of standards and other technical documentation as Europe's contribution to world-wide ICT standardization. This activity is supplemented by interoperability testing services and other specialisms. ETSI's prime objective is to support global harmonization by providing a forum in which all the key players can contribute actively. ETSI is officially recognized by the European Commission and the EFTA secretariat.

Notes:

Silicon-IPTV-Broadcast -97

History of IMS • IMS was originally defined by an industry forum called 3G.IP in 1999 — 3G.IP developed the initial IMS architecture — This was brought to the 3rd Generation Partnership Project (3GPP) — Part of their standardization work for 3G mobile phone systems in UMTS — Appeared in release 5 (evolution from 2G to 3G networks) – At the same time SIP-based multimedia was added — Support for the older GSM and GPRS networks was also provided. • Early IMS was defined to allow for IMS implementations that do not yet support all "Full IMS" requirements. • 3GPP2 (a different organization) based their CDMA2000 Multimedia Domain (MMD) on 3GPP IMS, adding support for CDMA2000. • 3GPP release 6 added interworking with WLAN • 3GPP release 7 added support for fixed networks, by working together with TISPAN R1.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -98

IMS was originally defined by an industry forum called 3G.IP, formed in 1999. 3G.IP developed the initial IMS architecture, which was brought to the 3rd Generation Partnership Project (3GPP), as part of their standardization work for 3G mobile phone systems in UMTS networks. It first appeared in release 5 (evolution from 2G to 3G networks), when SIP-based multimedia was added. Support for the older GSM and GPRS networks was also provided. Early IMS was defined to allow for IMS implementations that do not yet support all "Full IMS" requirements. 3GPP2 (a different organization) based their CDMA2000 Multimedia Domain (MMD) on 3GPP IMS, adding support for CDMA2000. 3GPP release 6 added interworking with WLAN. 3GPP release 7 added support for fixed networks, by working together with TISPAN R1.

Notes:

Silicon-IPTV-Broadcast -98

3GPP • The 3rd Generation Partnership Project (3GPP) is a collaboration agreement that was established in December 1998 — ETSI (Europe) — ARIB/TTC (Japan) — CCSA (China) — ATIS (North America) — TTA (South Korea) • The scope of 3GPP is to make a globally applicable third generation (3G) — mobile phone system specification within the scope of the ITU's IMT-2000 • 3GPP specifications are based on evolved GSM specifications, now generally known as the UMTS system.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -99

Each Release incorporates hundreds of individual standards documents, each of which may have been through many revisions. Current 3GPP standards incorporate the latest revision of the GSM standards. 3GPP's plans for the future beyond Release 7 are currently in the early stages of development under the title Long Term Evolution ("LTE"). 3GPP documents are made available freely on the organisation's web site. Whilst 3GPP standards can be bewildering to the newcomer, they are a remarkably complete and detailed resource and provide insight into how the cellular industry works. They cover not only the radio part ("Air Interface") and Core Network, but also billing information and speech coding down to source code level. Cryptographic aspects (authentication, confidentiality) are also freely specified in detail. 3GPP2 offer similar information about their system.

Notes:

Silicon-IPTV-Broadcast -99

Telecommunications and Internet Converged Services for Advanced Networking (TISPAN) • TISPAN specifies a Next Generation Network which: — Offers standardised multimedia services based on xDSL — Uses the 3GPP IMS for service handling, ensuring FMC — Supports legacy POTS services (PSTN/ISDN Emulation) – Same as the PSTN/ISDN Telephony service over an IP infrastructure – Enables use of ISDN Supplementary services and phone at home – So NGN will replace the soon becoming obsolescent PSTN — Supports a set of fully-defined Supplementary Services (Simulation) including Voice – Similar - but not identical - to existing PSTN service – Based on IMS capabilities – TISPAN’s specific needs to accommodate Wireline access to IMS are covered by a collaboration between TISPAN and 3GPP: TISPAN-specific IMS extensions are prepared in TISPAN and proposed for inclusion to 3GPP IMS Rel-7. Joint meetings between TISPAN and 3GPP.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -100

The Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) is a standardization body of ETSI, specializing in fixed networks and Internet convergence. It was formed in 2003 from the amalgamation of the ETSI bodies Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) and Services and Protocols for Advanced Networks (SPAN) TISPAN's focus is to define the European view of the Next Generation Networking (NGN) though TISPAN also includes much participation from regions outside Europe. TISPAN Release 1 was published in December 2005. The Release 1 architecture is based upon the concept of cooperating subsystems sharing common components. This subsystem-oriented architecture enables the addition of new subsystems over the time to cover new demands and service classes. The architecture ensures that the network resources, applications, and user equipment are common to all subsystems and therefore ensure user, terminal and service mobility to the fullest extent possible, including across administrative boundaries. One of the key subsystems is based upon the 3GPP IP Multimedia Subsystem (IMS) Release 6 and 3GPP2 Revision A architectures. TISPAN has adopted the IMS architecture given in release 6 and is adding wireline access to the same.

Notes:

Silicon-IPTV-Broadcast -100

Role of ETSI-TISPAN • TISPAN defines: — The Fixed Core Network — TISPAN addresses Fixed-access impacts on 3GPP’s IMS

IMS

HSS

FIXED

MOBILE

xDSL

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -101

To meet the rising demands relative to IP multimedia applications, the 3rd Generation Partnership Project (3GPP) promotes the IP Multimedia Subsystem (IMS). 3GPP defines the specifications for radio access by both WCDMA and GSM. It acts a facilitator for R99 and R4, inclusive of antenna interface specifications, voice service specifications in circuit switched (CS) domains, and basic data service specifications in packet switched (PS) domains. With respect to R5 and R6 research in relation to IP multimedia applications, R5 defines the core network architecture, public components, and basic service flows of IMS. Based on the extension of some R5 components, R6 defines the key service capability of IMS, Quality of Service (QoS), network interoperability, and also IMS/CS integration. The IMS architecture derived from 3GPP is broadly recognized as a reasonably comprehensive solution to the IP multimedia domain. 3GPP2 and TISPAN have adjusted their IP multimedia network architectures and service systems according to the 3GPP IMS model. In terms of their responsibilities with regard to IMS, 3GPP2 is handling access for cdma2000, and fixed networks are under the remit of TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking).

Notes:

Silicon-IPTV-Broadcast -101

Drivers in Sizing TV Services • Network capacity needed for TV Services depends upon several factors • Subscriber audience size – Bigger audiences need more access • Take-up rate of services — Take-up patterns vary from audience to audience • Resolution of TV programs distributed — Standard resolution:2 Mbit/s to 4 Mbit/s of bandwidth — HDTV requires 5 Mbit/s of bandwidth with MPEG-4 • Number of channels offered • Number of channels actually watched • Kind of service — Unicast or multicast

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -102

Notes:

Silicon-IPTV-Broadcast -102

IPTV and VOD • Commitment to next generation broadband access network is critical enabler for sufficient quality of service — NTT target of 30m FTTH customers by 2010 in Japan • Innovation and market development being held back by uncertain regulatory environments • Demand could be tempered by dual screen environment rather than convergence • Growing market for consumer electronics able to timeshift viewing may affect IPTV take up — Sales of DVD HDD recorders reached 5.5m in 2005 — Sony X Video Station to launch this year. A PVR with 8 tuners and 2 terabytes of hard disk memory

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -103

VoD services already exist in Japan, Korea and parts of the USA. There are small pockets around Europe too. Early indications are that take-up is price sensitive as one might expect. Where Time-slip TV is offered this is attractive to viewers and results in greater usage than premium rate moves. Even within subscribers the usage rarely reached 15% of subscribers at any time. Usage is more dependent upon what programming on free-to-air channels was. Where this was strong most viewers would not invest the time to decide what movie to watch!

Notes:

Silicon-IPTV-Broadcast -103

Efficient Distribution • Efficient distribution may require the duplication of some services — VoD services are best located near to subscriber — Broadcast channels of recorded video and moves may work best duplicated

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -104

To avoid transferring large amounts of data from one side of the network to another duplication of servers will be necessary in many networks. Bulk transfer of content is probably best achieved by man-in-a-van transfer.

Notes:

Silicon-IPTV-Broadcast -104

IPTV Bandwidth Requirements • Video — IPTV with MPEG2 compression – Standard Definition – High Definition — IPTV with MPEG4 compression – Standard Definition – High Definition

3.5 - 4.5 Mbps 12 -19.3 Mbps 1.5 - 2.0Mbps 5.0 - 8.0Mbps

• Access speeds for triple play might need to reach double the aggregate — How fast would access need to be? — Most locations cannot achieve this over long copper loops — Need to replace with fiber loops or accept lower quality

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -105

A key issue in the distribution of IPTV might be the stream bandwidth. Most households have more than one TV so we must expect fixed access speed to grow to match a profile that includes more than a single IP-TV stream. Given that HDTV becomes a significant consumer demand, delivery of this over MPEG-2 requires perhaps double the access speed. We might expect access speeds to need to be double the aggregated service so to deliver 2 HD-TV channels demands access to reach in excess of 20 Mbit/s with MPEG-4 and perhaps closer to 50 Mbit/s with MPEG-2.

Notes:

Silicon-IPTV-Broadcast -105

Centralized Architectures?

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -106

With an aggregated access speed of about 20 Mbit/s per household the bradband access nodes will need to be sized appropriately. Where a nominal 1000 loops are supported on a single rack, the reach must support about 20 Gbit/s of switching capacity at least. In the broadband aggregation networks each rack might therefore require backhauls of two 10G Ethernet trunks per rack. Policy control services will deliver QoS for different services to control quality through the access which will be the limiting part of the network. The broadband edge devices will then convert to MPLS for delivery across the core. Should we place services closely coupled to the core delivering a centralized service? This may not be optimal for all services. Indeed very much NOT optimal for VOD.

Notes:

Silicon-IPTV-Broadcast -106

Distributed Architectures?

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -107

By delivering video content regionally or even closely coupled to the access it becomes less necessary to carry large numbers of VOD sessions over the core. A centralized storage of content for long-term access could still be of benefit but would be transferred to regional or local servers for multiple local access.

Notes:

Silicon-IPTV-Broadcast -107

Network Dimensioning Is Critical

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -108

First Mile: In the access IPTV dominates the bandwidth use. This might be to receive broadcast TV or VOD. For any one TV set it is likely that only one of these will be in use at any one time. Second Mile: As we move to the aggregation level broadcast content might dominate since many different channels are likely to be watched all of which must be carried through the aggregated access. It is also likely that only a minority will request VOD at any one time. Third Mile: As we further aggregate services each individual VOD session becomes a new band to be individually carried so at the edge of the core it will become the dominant service. This will drive the deployment of VOD services from regional or local service points closer to the access.

Notes:

Silicon-IPTV-Broadcast -108

Switching Capacity • MSAN Switching capacity must service switching from access to back-haul • Throughput of switch should exceed twice sum of throughput — This is necessary for queuing allowance — Eventually may be desirable to make switch non blocking • Example:— Offer each user 8 Mbit/s down and 2 Mbit/s up total = 10 Mbit/s — 1000 users lines: usage is 10 Mbit/s x 1000 = 10 Gbit/s capacity for non blocking access — At only 10% utilization total load is 10 x 0.1 = 1 Gbit/s so we need to provide not less than twice this = 2 Gbit/s — At 40% utilization total load is 40 x 0.1 = 4 Gbit/s so we need to provide not less than twice this = 8 Gbit/s

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -109

The final backhaul capacity provided and the switching capacity needed largely depends upon the access speeds offered and the utilization levels used by users. As access speeds increase, utilization levels generally reduce. There is after all a limit to how fast a user can read or click a mouse. Higher access speeds will not significantly increase reading speed! However the provision of faster and faster services enablers new applications to be delivered and migration from usage just based upon web surfing, with utilization at or below 10%. HDTV with utilization at or above 50% can drastically change the backhaul capacity needed, and thus the total switching speed. We need to reduce the backhaul demand by ensuring the majority of TV is multicast.

Notes:

Silicon-IPTV-Broadcast -109

Winamp

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -110

Notes:

Silicon-IPTV-Broadcast -110

Video LAN Client

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -111

Notes:

Silicon-IPTV-Broadcast -111

Microsoft Media Player

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -112

Notes:

Silicon-IPTV-Broadcast -112

Broadcast Distribution Systems

Cable TV Delivery Systems Terrestrial Delivery IP Delivery Encoding Methods Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -113

Notes:

Silicon-IPTV-Broadcast -113

Compression • Compression is possible once we are in the digital domain • Video pictures are inherently full of redundancy if we have storage — In the majority of cases the next frame is largely the same as the last — By sending just the differences we can reduce bandwidth • Methods used today are dominated by Motion Picture Experts Group

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -114

Some people say that compressing video is a little like making orange juice concentrate or freezedried back-packing food. You throw something away (like water) that you think you can replace later. In doing so, you gain significant advantages in storage and transportation and you accept the food-like result because it's priced right and good enough for the application. Unfortunately, while orange juice molecules are all the same, the pixels used in digital video might all be different. Video compression is more like an ad that used to appear in the subway which said something like: "If u cn rd ths, u cn get a gd pying jb" or the kind of language used in SMS text messages. The real difference is perhaps the scale of the compression in that we can now deliver a viable picture in about 2% of the bandwidth of the original. A 2 Mbit/s video stream replacing a 166 Mbit/s original. The price we pay is quality. The notion of quality in any medium is inherently a moving target. We've added color and stereo sound to television. Just as we start to get a handle on compressing standard definition signals, high definition and widescreen loom on the horizon. There will never be enough bandwidth. There is even a Super High Definition format that is 2048x2048 pixels--14 times as large as NTSC. Perhaps former Tektronix design engineer Bruce Penny countered the quip best when he said, "Compression does improve picture quality. It improves the picture you can achieve in the bandwidth you have.”

Notes:

Silicon-IPTV-Broadcast -114

Compression Methods • Image Compression Methods — JPEG — GIF 89a — Wavelet Compression • Sound Compression — MPEG Audio Overview — MPEG Layer-3 (MP3) — MPEG AAC • Video Compression Methods — H.261 — MPEG/MPEG-2 — MPEG-4 — MPEG-7

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -115

There are multiple forms of compression available. These have evolved independently in many cases. We will examine static images first and then MPEG2 which will include many of the sound compressions elements used then we will examine MPEG4 and H.264. Finally we will address MPEG7 for completeness.

Notes:

Silicon-IPTV-Broadcast -115

JPEG Compression: Basics • Human vision is insensitive to high spatial frequencies • JPEG Takes advantage of this by compressing high frequencies more coarsely and storing image as frequency data • JPEG is a “lossy” compression scheme.

Losslessly compressed image, ~150KB

JPEG compressed, ~23KB

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -116

On the left the image is compressed with a loss-less compressions systems – GIF. In the right the same image compresses to one sixth the size using JPEG. While initially the two images look the same, close inspection will show loss of some detail. The level of compression can be selective to match quality to application.

Notes:

Silicon-IPTV-Broadcast -116

GIF 89a examples vs. JPEG

GIF Image, 7.5KB, optimal encoding

JPEG, blotchy spots in single-color areas

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -117

Notes:

Silicon-IPTV-Broadcast -117

JPEG Compression Rates

67k

37k

27k

22k

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -118

Notes:

Silicon-IPTV-Broadcast -118

Wavelet Image Compression • Optimal for images containing sharp edges, or continuous curves/lines (fingerprints) • Compared with DCT, uses more optimal set of functions to represent sharp edges than cosines. • Wavelets are finite in extent as opposed to sinusoidal functions

Several different families of wavelets.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -119

Wavelets are functions that satisfy certain mathematical requirements and are used in representing data or other functions. This idea is not new. Approximation using superposition of functions has existed since the early 1800's, when Joseph Fourier discovered that he could superpose sines and cosines to represent other functions. However, in wavelet analysis, the scale that we use to look at data plays a special role. Wavelet algorithms process data at different scales or resolutions. If we look at a signal with a large "window," we would notice gross features. Similarly, if we look at a signal with a small "window," we would notice small features. The result in wavelet analysis is to see both the forest and the trees, so to speak. This makes wavelets interesting and useful. For many decades, scientists have wanted more appropriate functions than the sines and cosines which comprise the bases of Fourier analysis, to approximate choppy signals. By their definition, these functions are non-local (and stretch out to infinity). They therefore do a very poor job in approximating sharp spikes. But with wavelet analysis, we can use approximating functions that are contained neatly in finite domains. Wavelets are well-suited for approximating data with sharp discontinuities. http://www.amara.com/IEEEwave/IEEEwavelet.html#contents

Notes:

Silicon-IPTV-Broadcast -119

Wavelet Transforms • Wavelet transforms comprise an infinite set • Wavelet subclasses distinguished by the number of coefficients

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -120

Wavelet transforms comprise an infinite set. The different wavelet families make different trade-offs between how compactly the basis functions are localized in space and how smooth they are. Some of the wavelet bases have fractal structure. The Daubechies wavelet family is one example on the left. Within each family of wavelets (such as the Daubechies family) are wavelet subclasses distinguished by the number of coefficients and by the level of iteration. Wavelets are classified within a family most often by the number of vanishing moments. This is an extra set of mathematical relationships for the coefficients that must be satisfied, and is directly related to the number of coefficients (1). For example, within the Coiflet wavelet family are Coiflets with two vanishing moments, and Coiflets with three vanishing moments. Comparision is shown on the right.

Notes:

Silicon-IPTV-Broadcast -120

Wavelet vs. JPEG compression

Wavelet compression file size: 1861 bytes compression ratio - 105.6

JPEG compression file size: 1895 bytes compression ratio - 103.8

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -121

We can use wavelets to retrieve the true image from the noise produced by the compression. The technique works in the following way. When you decompose a data set using wavelets, you use filters that act as averaging filters and others that produce details. Some of the resulting wavelet coefficients correspond to details in the data set. If the details are small, they might be omitted without substantially affecting the main features of the data set. The idea of thresholding, then, is to set to zero all coefficients that are less than a particular threshold. These coefficients are used in an inverse wavelet transformation to reconstruct the data set. Figure 6 is a pair of "before" and "after" illustrations of a nuclear magnetic resonance (NMR) signal. The signal is transformed, thresholded and inverse-transformed. The technique is a significant step forward in handling noisy data because the denoising is carried out without smoothing out the sharp structures. The result is cleaned-up signal that still shows important details.

Notes:

Silicon-IPTV-Broadcast -121

Wavelet compression advantages

Fourier basis functions, time-frequency tiles, and coverage of the timefrequency plane.

Daubechies wavelet basis functions, timefrequency tiles, and coverage of the timefrequency plane

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -122

The most interesting dissimilarity between these two kinds of transforms is that individual wavelet functions are localized in space. Fourier sine and cosine functions are not. This localization feature, along with wavelets' localization of frequency, makes many functions and operators using wavelets "sparse" when transformed into the wavelet domain. This sparseness, in turn, results in a number of useful applications such as data compression, detecting features in images, and removing noise from time series. One way to see the time-frequency resolution differences between the Fourier transform and the wavelet transform is to look at the basis function coverage of the time-frequency plane. The left figure shows a windowed Fourier transform, where the window is simply a square wave. The square wave window truncates the sine or cosine function to fit a window of a particular width. Because a single window is used for all frequencies in the WFT, the resolution of the analysis is the same at all locations in the time-frequency plane. An advantage of wavelet transforms is that the windows vary. In order to isolate signal discontinuities, one would like to have some very short basis functions. At the same time, in order to obtain detailed frequency analysis, one would like to have some very long basis functions. A way to achieve this is to have short high-frequency basis functions and long low-frequency ones. This happy medium is exactly what you get with wavelet transforms. The right figure shows the coverage in the time-frequency plane with one wavelet function, the Daubechies wavelet. One thing to remember is that wavelet transforms do not have a single set of basis functions like the Fourier transform, which utilizes just the sine and cosine functions. Instead, wavelet transforms have an infinite set of possible basis functions. Thus wavelet analysis provides immediate access to information that can be obscured by other time-frequency methods such as Fourier analysis.

Notes:

Silicon-IPTV-Broadcast -122

MPEG Compression Protocols • MPEG-1 ISO/IEC JTC1/SC29/WG11 ISO 11172 parts 1 to 4 • MPEG-2 ISO/IEC JTC1/SC29/WG11 ISO 13818 parts 1 to 10 • MPEG-3 abandoned but audio encoding • MPEG-4 ISO/IEC JTC1/SC29/WG11 N4668 • MPEG-7 ISO/IEC JTC1/SC29/WG11N6828 — Adds descriptions language for multimedia • MPEG-21 ISO/IEC JTC1/SC29/WG11/N5231 — Adds digital rights management

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -123

Moving Picture Experts Group (MPEG) a working group of ISO/IEC in charge of the development of standards for coded representation of digital audio and video. Established in 1988, the group has produced MPEG-1, the standard on which such products as Video CD and MP3 are based, MPEG-2, the standard on which such products as Digital Television set top boxes and DVD are based, MPEG-4, the standard for multimedia for the fixed and mobile web and MPEG-7, the standard for description and search of audio and visual content. Work on the new standard MPEG-21 "Multimedia Framework" has started in June 2000. So far a Technical Report and two standards have been produced and three more parts of the standard are at different stages of development. Several Calls for Proposals have already been issued

Notes:

Silicon-IPTV-Broadcast -123

MPEG • The Motion Picture Experts group was started in 1988 • MPEG-1 is a 3 part standard released in 1993 — Defines encoding for Video, Audio and Compression — Includes multiplexing of these for interleaving video and audio — It was aimed at encoding video for VHS quality at rates of about 1.5 Mbit/s • MPEG-2 aimed at more general application — Currently the dominant standard for digital TV services — Generally reckoned that 5 Mbit/s encoding is equivalent to over-air broadcast — Encoding possible to lower bit rates when bandwidth is limited

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -124

MPEG (Moving Picture Experts Group) was started in 1988 as a working group within ISO/IEC with the aim of defining standards for digital compression of audio-visual signals. MPEG's first project, MPEG-1, was published in 1993 as ISO/IEC 11172 [1]. It is a three-part standard defining audio and video compression coding methods and a multiplexing system for interleaving audio and video data so that they can be played back together. MPEG-1 principally supports video coding up to about 1.5 Mbit/s giving quality similar to VHS and stereo audio at 192 bit/s. It is used in the CD-i and Video-CD systems for storing video and audio on CD-ROM. During 1990, MPEG recognised the need for a second, related standard for coding video for broadcast formats at higher data rates. The MPEG-2 standard [2] is capable of coding standard-definition television at bit rates from about 3-15 Mbit/s and high-definition television at 15-30 Mbit/s. MPEG-2 extends the stereo audio capabilities of MPEG-1 to multi-channel surround sound coding. MPEG-2 decoders will also decode MPEG-1 bitstreams. Drafts of the audio, video and systems specifications were completed in November 1993 and the ISO/IEC approval process was completed in November 1994. The final text was published in 1995. MPEG-2 aims to be a generic video coding system supporting a diverse range of applications. Different algorithmic 'tools', developed for many applications, have been integrated into the full standard. To implement all the features of the standard in all decoders is unnecessarily complex and a waste of bandwidth, so a small number of subsets of the full standard, known as profiles and levels, have been defined. A profile is a subset of algorithmic tools and a level identifies a set of constraints on parameter values (such as picture size and bit rate). A decoder which supports a particular profile and level is only required to support the corresponding subset of the full standard and set of parameter constraints.

Notes:

Silicon-IPTV-Broadcast -124

MPEG2 Standard Parts • ISO/IEC 13818-1:2000 Information technology -- Generic coding of moving pictures and associated audio information: Systems (available in English only) • ISO/IEC 13818-2:2000 Information technology -- Generic coding of moving pictures and associated audio information: Video (available in English only) • ISO/IEC 13818-3:1998 Information technology -- Generic coding of moving pictures and associated audio information -- Part 3: Audio (available in English only) • ISO/IEC 13818-4:1998 Information technology -- Generic coding of moving pictures and associated audio information -- Part 4: Conformance testing (available in English only) • ISO/IEC 13818-4:1998/Cor 2:1998 (available in English only)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -125

Notes:

Silicon-IPTV-Broadcast -125

MPEG2 Standard Parts • ISO/IEC 13818-4:1998/Amd 1:1999 Advanced Audio Coding (AAC) conformance testing (available in English only) • ISO/IEC 13818-4:1998/Amd 2:2000 System target decoder model (available in English only) • ISO/IEC 13818-4:1998/Amd 3:2000 Additional audio conformance bitstreams (available in English only) • ISO/IEC TR 13818-5:1997 Information technology -- Generic coding of moving pictures and associated audio information -- Part 5: Software simulation (available in English only) • ISO/IEC TR 13818-5:1997/Amd 1:1999 Advanced Audio Coding (AAC) (available in English only)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -126

Notes:

Silicon-IPTV-Broadcast -126

MPEG2 Standard Parts • ISO/IEC 13818-6:1998 Information technology -- Generic coding of moving pictures and associated audio information -- Part 6: Extensions for DSMCC (available in English only) • ISO/IEC 13818-6:1998/Cor 1:1999 (available in English only) • ISO/IEC 13818-6:1998/Amd 1:2000 Additions to support data broadcasting (available in English only) • ISO/IEC 13818-6:1998/Amd 2:2000 Additions to support synchronized download services, opportunistic data services and resource announcement in broadcast and interactive services (available in English only) • ISO/IEC 13818-7:1997 Information technology -- Generic coding of moving pictures and associated audio information -- Part 7: Advanced Audio Coding (AAC) (available in English only)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -127

Notes:

Silicon-IPTV-Broadcast -127

MPEG2 Standard Parts • ISO/IEC 13818-7:1997/Cor 1:1998 (available in English only) • ISO/IEC 13818-9:1996 Information technology -- Generic coding of moving pictures and associated audio information -- Part 9: Extension for real time interface for systems decoders (available in English only) • ISO/IEC 13818-10:1999 Information technology -- Generic coding of moving pictures and associated audio information -- Part 10: Conformance extensions for Digital Storage Media Command and Control (DSM-CC) (available in English only)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -128

Notes:

Silicon-IPTV-Broadcast -128

Part 1 of MPEG2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -129

Part 1 of MPEG-2 addresses the combining of one or more elementary streams of video and audio, as well as, other data into single or multiple streams which are suitable for storage or transmission. This is specified in two forms: the Program Stream and the Transport Stream. Each is optimised for a different set of applications The Program Stream is similar to MPEG-1 Systems Multiplex. It results from combining one or more Packetised Elementary Streams (PES), which have a common time base, into a single stream. The Program Stream is designed for use in relatively error-free environments and is suitable for applications which may involve software processing. Program stream packets may be of variable and relatively great length. The Transport Stream combines one or more Packetized Elementary Streams (PES) with one or more independent time bases into a single stream. Elementary streams sharing a common timebase form a program. The Transport Stream is designed for use in environments where errors are likely, such as storage or transmission in lossy or noisy media. Transport stream packets are 188 bytes long.

Notes:

Silicon-IPTV-Broadcast -129

Part 2 of MPEG2

Multiview 4:2:2 Simple

Main

High level

X

High-1440 level

X

Main level Low level

X

SNR scalable

Spatial scalable

High

X X

X

X

X

X

X X

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

X

X

Silicon-IPTV-Broadcast -130

Part 2 of MPEG-2 builds on the powerful video compression capabilities of the MPEG-1 standard to offer a wide range of coding tools. These have been grouped in profiles to offer different functionalities. Only the combinations marked with an "X" are recognised by the standard. Since the final approval of MPEG-2 Video in November 1994, one additional profile has been developed. This uses existing coding tools of MPEG-2 Video but is capable to deal with pictures having a colour resolution of 4:2:2 and a higher bitrate. Even though MPEG-2 Video was not developed having in mind studio applications, a set of comparison tests carried out by MPEG confirmed that MPEG-2 Video was at least good, and in many cases even better than standards or specifications developed for high bitrate or studio applications. The 4:2:2 profile has been finally approved in January 1996 and is now an integral part of MPEG-2 Video. The Multiview Profile (MVP) is an additional profile currently being developed. By using existing MPEG-2 Video coding tools it is possible to encode in an efficient way tow video sequences issued from two cameras shooting the same scene with a small angle between them. This profile will be finally approved in July 1996.

Notes:

Silicon-IPTV-Broadcast -130

Part 3 of MPEG2 : Audio

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -131

Part 3 of MPEG-2 is a backwards-compatible multichannel extension of the MPEG1 Audio standard. Part 6 of MPEG-2 - Digital Storage Media Command and Control (DSM-CC) is the specification of a set of protocols which provides the control functions and operations specific to managing MPEG-1 and MPEG-2 bitstreams. These protocols may be used to support applications in both stand-alone and heterogeneous network environments. In the DSM-CC model, a stream is sourced by a Server and delivered to a Client. Both the Server and the Client are considered to be Users of the DSMCC network. DSM-CC defines a logical entity called the Session and Resource Manager (SRM) which provides a (logically) centralized management of the DSMCC Sessions and Resources

Notes:

Silicon-IPTV-Broadcast -131

MPEG Audio basics & Psychoacoustic Model • Human hearing limited to values lower than ~20kHz in most cases • Human hearing is insensitive to quiet frequency components to sound accompanying other stronger frequency components • Stereo audio streams contain largely redundant information • MPEG audio compression takes advantage of these facts to reduce extent and detail of mostly inaudible frequency ranges

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -132

Notes:

Silicon-IPTV-Broadcast -132

MPEG-Layer3 Overview

MP3 Compression Flow Chart © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -133

Notes:

Silicon-IPTV-Broadcast -133

MPEG Layer-3 performance

sound quality

bandwidth

mode

bitrate

reduction ratio

telephone sound

2.5 kHz

mono

8 kbps *

96:1

better than short wave

4.5 kHz

mono

16 kbps

48:1

better than AM radio

7.5 kHz

mono

32 kbps

24:1

similar to FM radio

11 kHz

stereo

56...64 kbps

26...24:1

near-CD

15 kHz

stereo

96 kbps

16:1

CD

>15 kHz

stereo

112..128kbps

14..12:1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -134

Notes:

Silicon-IPTV-Broadcast -134

MPEG-2 Advanced Audio Coding (AAC) • Sampling frequencies from 8kHz to 96kHz • 1 to 48 channels per stream • Temporal Noise Shaping (TNS) smooths quantization noise by making frequency domain predictions • Prediction: Allows predictable sound patterns such as speech to be predicted and compressed with better quality

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -135

Notes:

Silicon-IPTV-Broadcast -135

MPEG-2 AAC Flowchart Input Time Signal

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -136

Notes:

Silicon-IPTV-Broadcast -136

Part 6 of MPEG2 • Digital Storage Media Command and Control (DSM-CC) — is the specification of a set of protocols which provides the control functions

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -137

Part 4 and 5 of MPEG-2 correspond to part 4 and 5 of MPEG-1. They have been finally approved in March 1996. Part 6 of MPEG-2 - Digital Storage Media Command and Control (DSM-CC) is the specification of a set of protocols which provides the control functions and operations specific to managing MPEG-1 and MPEG-2 bitstreams. These protocols may be used to support applications in both stand-alone and heterogeneous network environments. In the DSM-CC model, a stream is sourced by a Server and delivered to a Client. Both the Server and the Client are considered to be Users of the DSMCC network. DSM-CC defines a logical entity called the Session and Resource Manager (SRM) which provides a (logically) centralized management of the DSMCC Sessions and Resources.

Notes:

Silicon-IPTV-Broadcast -137

Part 9 of MPEG2 • Part 9 defines the Transport Stream for MPEG2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -138

Part 6 of MPEG-2 - Digital Storage Media Command and Control (DSM-CC) is the specification of a set of protocols which provides the control functions and operations specific to managing MPEG-1 and MPEG-2 bitstreams. These protocols may be used to support applications in both stand-alone and heterogeneous network environments. In the DSM-CC model, a stream is sourced by a Server and delivered to a Client. Both the Server and the Client are considered to be Users of the DSMCC network. DSM-CC defines a logical entity called the Session and Resource Manager (SRM) which provides a (logically) centralized management of the DSMCC Sessions and Resources Part 9 of MPEG-2 is the specification of the Real-time Interface (RTI) to Transport Stream decoders which may be utilised for adaptation to all appropriate networks carrying Transport Streams

Notes:

Silicon-IPTV-Broadcast -138

MPEG Transport over IP

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -139

Digital video and audio signals are compresses into elementary streams and then packetised. The Packetised Elementary Streams (PES) contain both payload and header information. Each payload contains a single frame of audio or video and becomes part of the MPREG-2 Transport Stream. It is further sub-divided into 188bytes packets. A packet Identifier (PID) in the header of each transport packet associates the packet with the program channel to which it belongs using information signaled in MPEG-2 PSI. Also placed in the packets periodically are program clock reference (PCR) values to closely synchronize the encoder and decoder clocks. Both PID and PCR are important measurement parameters within the transport stream. The PID identifies the program to which each packet belongs and also enables determination of the bandwidth allocation between programs.

Notes:

Silicon-IPTV-Broadcast -139

MPEG Video Compression • Supports JPEG and H.261 through downward compatibility • Supports higher Chrominance resolution and pixel resolution (720x480 is standard used for TV signals) • Supports interlaced and noninterlaced modes • Uses Bidirectional prediction in “Group Of Pictures” to encode difference frames.

“Group Of Pictures” inter-frame dependencies in a stream

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -140

Source: “Parallelization of Software Mpeg Compression” http://www.evl.uic.edu/fwang/mpeg.html

Notes:

Silicon-IPTV-Broadcast -140

Picture Types • MPEG-2 uses 3 different picture types • I-Pictures - Intra pictures - these are encoded without reference to others — They can take advantage of spatial redundancy • P-Pictures - Predictive pictures - these use a previous I-picture or Ppicture plus motion compensation • B-Pictures - Bidirectional pictures - these can use a previous or future Ipicture or P-picture for motion compensation — When a future picture is used the frames are reordered — The receiver stores the frame, uses it for constructing the new frame and then later plays it in the correct play sequence • B-Pictures are the most complex to construct but yield the greatest compression • The greater use that is made of them the greater will be the receiver memory requirements © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -141

'Intra' pictures (I-pictures) are coded without reference to other pictures. Moderate compression is achieved by reducing spatial redundancy, but not temporal redundancy. They can be used periodically to provide access points in the bitstream where decoding can begin. 'Predictive' pictures (P-pictures) can use the previous I- or P-picture for motion compensation and may be used as a reference for further prediction. Each block in a P-picture can either be predicted or intra-coded. By reducing spatial and temporal redundancy, P-pictures offer increased compression compared to I-pictures. 'Bidirectionally-predictive' pictures (B-pictures) can use the previous and next I- or P-pictures for motion-compensation, and offer the highest degree of compression. Each block in a B-picture can be forward, backward or bidirectionally predicted or intra-coded. To enable backward prediction from a future frame, the coder reorders the pictures from natural 'display' order to 'bitstream' order so that the B-picture is transmitted after the previous and next pictures it references. This introduces a reordering delay dependent on the number of consecutive B-pictures. The different picture types typically occur in a repeating sequence, termed a 'Group of Pictures' or GOP. A typical GOP in display order is: B1 B2 I3 B4 B5 P6 B7 B8 P9 B10 B11 P12 The corresponding bitstream order is: I3 B1 B2 P6 B4 B5 P9 B7 B8 P12 B10 B11 For a given decoded picture quality, coding using each picture type produces a different number of bits. In a typical example sequence, a coded I-picture was three times larger than a coded P-picture, which was itself 50% larger than a coded B-picture.

Notes:

Silicon-IPTV-Broadcast -141

MPEG 1 & 2 Bitstream

The MPEG data hierarchy

© Copyright: All rights reserved. Not to be reproduced without prior written consent. Silicon-IPTV-Broadcast -142 Source: http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol4/sab/report.html

Notes:

Silicon-IPTV-Broadcast -142

MPEG-2 • MPEG-2 encodes the active portion of the PAL frame — 720 pixels by 576 lines • Using 8 bits for each of 8 enc0ding streams required 166 Mbit/s • First stage is to average adjacent lines reducing rate to 124 Mbit/s • Frames have spatial and temporal redundancy — Adjacent parts of a picture are similar — 2 dimensional blocks are encoded 8 pixels by 8 lines

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -143

The active region of a digital television frame, sampled according to CCIR recommendation 601, is 720 pixels by 576 lines for a frame rate of 25 Hz. Using 8 bits for each Y, U or V pixel, the uncompressed bit rates for 4:2:2 and 4:2:0 signals are therefore: 4:2:2: 720 x 576 x 25 x 8 + 360 x 576 x 25 x ( 8 + 8 ) = 166 Mbit/s 4:2:0: 720 x 576 x 25 x 8 + 360 x 288 x 25 x ( 8 + 8 ) = 124 Mbit/s MPEG-2 is capable of compressing the bit rate of standard-definition 4:2:0 video down to about 315 Mbit/s. At the lower bit rates in this range, the impairments introduced by the MPEG-2 coding and decoding process become increasingly objectionable. For digital terrestrial television broadcasting of standard-definition video, a bit rate of around 6 Mbit/s is thought to be a good compromise between picture quality and transmission bandwidth efficiency. A bit rate reduction system operates by removing redundant information from the signal at the coder prior to transmission and re-inserting it at the decoder. A coder and decoder pair are referred to as a 'codec'. In video signals, two distinct kinds of redundancy can be identified. Spatial and temporal redundancy: Pixel values are not independent, but are correlated with their neighbours both within the same frame and across frames. So, to some extent, the value of a pixel is predictable given the values of neighbouring pixels. Psychovisual redundancy: The human eye has a limited response to fine spatial detail, and is less sensitive to detail near object edges or around shot-changes. Consequently, controlled impairments introduced into the decoded picture by the bit rate reduction process should not be visible to a human observer.

Notes:

Silicon-IPTV-Broadcast -143

MPEG-2 • The pattern of values for pixels is not random im practice • By using cosine transforms the division of frequency of change in the pixels can be concentrated into coefficient values — The pattern of coefficients is generally concentrated in lower frequencies • Compression can be achieved by not transmitting the high frequencies • The quantization of the encoding of coefficients is weighted — Low frequency components are encoding using more accuracy than high frequency • The encoding uses a form of run length encoding — Takes advantage of the high instance of zero values

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -144

For an 8x8 block of 8 bit pixels, the DCT produces an 8x8 block of 11 bit coefficients (the range of coefficient values is larger than the range of pixel values.) The reduction in the number of bits follows from the observation that, for typical blocks from natural images, the distribution of coefficients is non-uniform. The transform tends to concentrate the energy into the low-frequency coefficients and many of the other coefficients are near-zero. The bit rate reduction is achieved by not transmitting the near-zero coefficients and by quantising and coding the remaining coefficients as described below. The non-uniform coefficient distribution is a result of the spatial redundancy present in the original image block. Quantisation: The function of the coder is to transmit the DCT block to the decoder, in a bit rate efficient manner, so that it can perform the inverse transform to reconstruct the image. It has been observed that the numerical precision of the DCT coefficients may be reduced while still maintaining good image quality at the decoder. Quantisation is used to reduce the number of possible values to be transmitted, reducing the required number of bits. The degree of quantisation applied to each coefficient is weighted according to the visibility of the resulting quantisation noise to a human observer. In practice, this results in the high-frequency coefficients being more coarsely quantised than the low-frequency coefficients. Note that the quantisation noise introduced by the coder is not reversible in the decoder, making the coding and decoding process 'lossy'. Coding: The serialisation and coding of the quantised DCT coefficients exploits the likely clustering of energy into the low-frequency coefficients and the frequent occurrence of zero-value coefficients. The block is scanned in a diagonal zigzag pattern starting at the DC coefficient to produce a list of quantised coefficient values, ordered according to the scan pattern.

Notes:

Silicon-IPTV-Broadcast -144

MPEG-2 Encoding • Example encoding of a string of coefficients:

12, 6, 6, 0, 4, 3, 0, 0, 0...0 • First step is to group them into a string of zeros followed by non-zero

(12), (6), (6), (0, 4), (3) EOB

Length of run of zeros 0

Value of nonVariable-length zero Code-word coefficient 12 0000 0000 1101 00

0

6

0010 0001 0

1

4

0000 0011 000

0

3

0010 10

EOB

-

10

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -145

Using the scan pattern common to both MPEG-1 and MPEG-2. MPEG-2 has an additional 'alternate' scan pattern intended for scanning the quantised coefficients resulting from interlaced source pictures. To illustrate the variable-length coding process, consider the following example list of values produced by scanning the quantised coefficients from a transformed block: 12, 6, 6, 0, 4, 3, 0, 0, 0...0 The first step is to group the values into runs of (zero or more) zeros followed by a non-zero value. Additionally, the final run of zeros is replaced with an end of block (EOB) marker. Using parentheses to show the groups, this gives: (12), (6), (6), (0, 4), (3) EOB The second step is to generate the variable length code words corresponding to each group (a run of zeros followed by a non-zero value) and the EOB marker. Table 1 shows an extract of the DCT coefficient VLC table common to both MPEG-1 and MPEG-2. MPEG-2 has an additional 'intra' VLC optimised for coding intra blocks (see Section 4). Using the variable length code from Table and adding spaces and commas for readability, the final coded representation of the example block is: 0000 0000 1101 00, 0010 0001 0, 0010 0001 0, 0000 0011 000, 0010 10, 10

Notes:

Silicon-IPTV-Broadcast -145

MPEG-2 Motion Compensation • Temporal redundancy is exploited by predicting each frame • An earlier reference frame is used and compared with the current • The decoded pictures are not identical to the source — Small distortions result from the compression encoding — The source therefore constructs a local decode and uses this for reference • Blocks of picture are matched between reference and new frame • The 'best' offset is selected on the basis of minimum error between the block being coded and the prediction

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -146

This technique exploits temporal redundancy by attempting to predict the frame to be coded from a previous 'reference' frame. The prediction cannot be based on a source picture because the prediction has to be repeatable in the decoder, where the source pictures are not available (the decoded pictures are not identical to the source pictures because the bit rate reduction process introduces small distortions into the decoded picture.) Consequently, the coder contains a local decoder which reconstructs pictures exactly as they would be in the decoder, from which predictions can be formed. The simplest inter-frame prediction of the block being coded is that which takes the co-sited (i.e. the same spatial position) block from the reference picture. Naturally this makes a good prediction for stationary regions of the image, but is poor in moving areas. A more sophisticated method, known as motion-compensated inter-frame prediction, is to offset any translational motion which has occurred between the block being coded and the reference frame and to use a shifted block from the reference frame as the prediction. One method of determining the motion that has occurred between the block being coded and the reference frame is a 'block-matching' search in which a large number of trial offsets are tested by the coder using the luminance component of the picture. The 'best' offset is selected on the basis of minimum error between the block being coded and the prediction. The bit rate overhead of using motion-compensated prediction is the need to convey the motion vectors required to predict each block to the decoder. For example, using MPEG-2 to compress standard-definition video to 6 Mbit/s, the motion vector overhead could account for about 2 Mbit/s during a picture making heavy use of motion-compensated prediction.

Notes:

Silicon-IPTV-Broadcast -146

MPEG-2: Profiles and Levels Profiles SNR

Spatial

High

Multiview

4:2:0

4:2:0

4:2:0;4:2:2

4:2:0

Enhancement

1920 X 1151/60

1920 X 1151/60

Lower

960 X 576/30

1920 X 1151/60

Bitrate

100, 80,25

130, 50, 80

Levels

High Enhancement

1440 X 1152/60

1440 X 1152/60

1920 X 1152/60

Lower

720 X 576/30

720 X 576/30

1920 X 1152/60

High-1440 Bitrate Enhancement Main

Low

60, 40, 15 720 X 576/30

Lower Bitrate

15, 10

Enhancement

352 X 288/30

80, 60, 20

100, 40, 60

720 X 576/30

720 X 576/30

352 X 288/30

720 X 576/30

20, 15, 4

Lower Bitrate

25, 10, 15 352 X 288/30 352 X 288/30

4, 3

8, 4, 4

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -147

Notes:

Silicon-IPTV-Broadcast -147

Pro MPEG For Error Tolerance • Adding Forward Error recovery to MPEG protocols improves quality • During transmission on satellite and terrestrial broadcast errors occur • Over IP networks packets of frames are lost when errors occur — On copper cables error rates of 1 bit in 109 are typical — On fiber cables error rates of 1 bit in 1012 are expected — Gigabit Ethernet frames are 1500 bytes or 12,000 bits long – Even over fiber this results in 12 errors per second on average!! • Codes of Practice define how to add FEC to MPEG streams

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -148

Professional video streaming over IP networks has become a reality and this paper provides an insight into the workings of Pro-MPEG CoP#3 Forward Error Correction (FEC) in protecting contribution and distribution services. In transporting real-time media over IP networks either UDP or RTP (Real Time Protocol) protocols can be used. RTP provides packet sequence ordering over UDP, enabling a receiver to identify out of sequence, discarded or reordered packets so is more robust than UDP. The Pro-MPEG CoP #3 FEC scheme uses the RTP transport protocol as a building block for providing packet recovery techniques to ensure reliable real-time media transport. The MPEG Transport Stream (TS) packets must first be packed into IP frames. Since most streams will pass over an Ethernet network at some point, whose MTU (Maximum Transmission Unit) is 1500, the IP frame must be constrained so that fragmentation does not occur. This limits the number of TS packets to a maximum of 7 per IP packet. Packing the maximum of seven 188 byte packets into an IP packet gives optimum packing efficiency at the cost of excessive data loss per a packet. If only a single MPEG packet is placed in an IP packet minimal loss of data occurs on packet loss, at the cost of higher transmission overheads, which in turn will place greater demand on the network.

Notes:

Silicon-IPTV-Broadcast -148

Pro-MPEG CoP3 Forward Error Correction (FEC)

Normal MPEG-2 Transport streams pack several video frames in an Ethernet Transfer

Pro-MPEG takes consecutive packets and adds FEC

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -149

The generation of the FEC packets is based on the use of a matrix. The matrix size is defined by two parameters L and D, L is the spacing between non-consecutive packets to be used to calculate the FEC packet and D is the depth of the matrix. Column FEC provides correction for consecutive burst packet loss of up to L packets. The FEC packets are generated per a column within the matrix allowing loss of any single media packet within a column or burst of error within a row to be corrected through the FEC packet. Column FEC is ideal for correcting packet burst errors and random errors. Row FEC provides correction of non-consecutive packet loss and can correct any single packet loss within a row of media packets. The FEC packets are generated per a row allowing loss of any single packet to be recovered. Row FEC is ideal for correcting random packet errors. Column FEC is often called 1D FEC due to the FEC only being calculated on 1 dimension where Column and Row FEC is referred to as 2D FEC due to the FEC being calculated on 2 dimensions, column and row.

Notes:

Silicon-IPTV-Broadcast -149

Pro-MPEG CoP3 Forward Error Correction (FEC)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -150

The combination of Column and Row FEC provides a robust error protection scheme capable of dealing with random and burst errors, and is able to correct more errors than either column or row schemes can independently. Once the FEC packets have been computed they must be transmitted with the media packets to the receivers. The standard defines that the media and FEC packets are transmitted separately on different UDP ports. The diagram shows the transmission of the media packet on port n while the column FEC packets are transmitted on port n+2 and row FEC packets on port n+4 as defined in the Pro-MPEG CoP #3 standard. This enables reception by both non-enabled and enabled FEC receivers, the FEC enabled receivers can utilise the additional FEC streams to correct any missing or corrupted media packets while non-enabled receivers are unaffected by the FEC packets and will simply ignore them. The transmitted media and FEC streams are received at the receive site. The receiver should use the available FEC packets to the best of its ability to reconstruct the original media stream. The illustration below shows the correction of missing packets using the available column and row FEC packets to recover the missing media packets.

Notes:

Silicon-IPTV-Broadcast -150

COP 4 for SMPTE 292M • RFC3497, RTP Payload Format • Society of Motion Picture & Television Engineers (SMPTE) 292M Video • Commercial Code of Practice issued by the Pro-MPEG forum • Used to carry uncompressed HDTV

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -151

The serial digital interface, SMPTE 292M , defines a universal medium of interchange for uncompressed High Definition Television (HDTV) between various types of video equipment (cameras, encoders, VTRs, etc.). SMPTE 292M stipulates that the source data be in 10 bit words and the total data rate be either 1.485 Gbps or 1.485/1.001 Gbps. The use of a dedicated serial interconnect is appropriate in a studio environment, but it is desirable to leverage the widespread availability of high bandwidth IP connectivity to allow efficient wide area delivery of SMPTE 292M content. This RFC only addresses the transfer of uncompressed HDTV. Compressed HDTV is a subset of MPEG-2 , which is fully described in document A/53 of the Advanced Television Standards Committee. The ATSC has also adopted the MPEG-2 transport system (ISO/IEC 13818-1) . Therefore RFC 2250 sufficiently describes transport for compressed HDTV over RTP.

Notes:

Silicon-IPTV-Broadcast -151

Versions of MPEG4

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -152

MPEG-4 Version 1 was approved by MPEG in December 1998; version 2 was frozen in December 1999. After these two major versions, more tools were added in subsequent amendments that could be qualified as versions, even though they are harder to recognize as such. Recognizing the versions is not too important, however; it is more important to distinguish Profiles. Existing tools and profiles from any version are never replaced in subsequent versions; technology is always added to MPEG?4 in the form of new profiles. Figure 3 below depicts the relationship between the versions. Version 2 is a backward compatible extension of Version 1, and version 3 is a backward compatible extension of Version 2 – and so on. The versions of all major parts of the MPEG-4 Standard (Systems, Audio, Video, DMIF) were synchronized; after that, the different parts took their own paths. The Systems layer of Version later versions is backward compatible with all earlier versions. In the area of Systems, Audio and Visual, new versions add Profiles, do not change existing ones. In fact, it is very important to note that existing systems will always remain compliant, because Profiles will never be changed in retrospect, and neither will the Systems Syntax, at least not in a backward-incompatible way.

Notes:

Silicon-IPTV-Broadcast -152

MPEG4

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -153

Media objects may need streaming data, which is conveyed in one or more elementary streams. An object descriptor identifies all streams associated to one media object. This allows handling hierarchically encoded data as well as the association of meta-information about the content (called ‘object content information’) and the intellectual property rights associated with it. Each stream itself is characterized by a set of descriptors for configuration information, e.g., to determine the required decoder resources and the precision of encoded timing information. Furthermore the descriptors may carry hints to the Quality of Service (QoS) it requests for transmission (e.g., maximum bit rate, bit error rate, priority, etc.) Synchronization of elementary streams is achieved through time stamping of individual access units within elementary streams. The synchronization layer manages the identification of such access units and the time stamping. Independent of the media type, this layer allows identification of the type of access unit (e.g., video or audio frames, scene description commands) in elementary streams, recovery of the media object’s or scene description’s time base, and it enables synchronization among them. The syntax of this layer is configurable in a large number of ways, allowing use in a broad spectrum of systems. The synchronized delivery of streaming information from source to destination, exploiting different QoS as available from the network, is specified in terms of the synchronization layer and a delivery layer containing a two-layer multiplexer. The first multiplexing layer is managed according to the DMIF specification, part 6 of the MPEG?4 standard. (DMIF stands for Delivery Multimedia Integration Framework) This multiplex may be embodied by the MPEG-defined FlexMux tool, which allows grouping of Elementary Streams (ESs) with a low multiplexing overhead. Multiplexing at this layer may be used, for example, to group ES with similar QoS requirements, reduce the number of network connections or the end to end delay. The “TransMux” (Transport Multiplexing) layer models the layer that offers transport services matching the requested QoS. Only the interface to this layer is specified by MPEG-4 while the concrete mapping of the data packets and control signaling must be done in collaboration with the bodies that have jurisdiction over the respective transport protocol. Any suitable existing transport protocol stack such as (RTP)/UDP/IP, (AAL5)/ATM, or MPEG-2’s Transport Stream over a suitable link layer may become a specific TransMux instance. The choice is left to the end user/service provider, and allows MPEG-4 to be used in a wide variety of operation environments.

Notes:

Silicon-IPTV-Broadcast -153

MPEG-4 Video Encoding • MPEG-4 includes tools for:— Efficient compression of images and video — Efficient compression of textures for texture mapping on 2-D and 3-D meshes — Efficient compression of implicit 2-D meshes — Efficient compression of time-varying geometry streams that animate meshes — Efficient random access to all types of visual objects — Extended manipulation functionality for images and video sequences — Content-based coding of images and video — Content-based scalability of textures, images and video — Spatial, temporal and quality scalability — Error robustness and resilience in error prone environments

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -154

The tools for representing natural video in the MPEG-4 visual standard provide standardized core technologies allowing efficient storage, transmission and manipulation of textures, images and video data for multimedia environments. These tools allow the decoding and representation of atomic units of image and video content, called “video objects” (VOs). An example of a VO could be a talking person (without background), which can then be composed with other AVOs (audio-visual objects) to create a scene. Conventional rectangular imagery is handled as a special case of such objects. In order to achieve this broad goal rather than a solution for a narrow set of applications, functionalities common to several applications are clustered. Therefore, the visual part of the MPEG-4 standard provides solutions in the form of tools and algorithms for: Efficient compression of images and video Efficient compression of textures for texture mapping on 2-D and 3-D meshes Efficient compression of implicit 2-D meshes Efficient compression of time-varying geometry streams that animate meshes Efficient random access to all types of visual objects Extended manipulation functionality for images and video sequences Content-based coding of images and video Content-based scalability of textures, images and video Spatial, temporal and quality scalability Error robustness and resilience in error prone environments

Notes:

Silicon-IPTV-Broadcast -154

MPEG-4 Video Encoding • Scalable Coding of Video Objects • Robustness in Error Prone Environments • Resynchronization • Data Recovery • Error Concealment • Fast recovery in real-time coding • Improved temporal resolution stability with low buffering delay — A special technique of use in real-time encoding situations is Dynamic Resolution Conversion (DRC) — It is a way to stabilize the transmission buffering delay

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -155

The coding of conventional images and video is similar to conventional MPEG-1/2 coding. It involves motion prediction/compensation followed by texture coding. For the content-based functionalities, where the image sequence input may be of arbitrary shape and location, this approach is extended by also coding shape and transparency information. Shape may be either represented by an 8 bit transparency component - which allows the description of transparency if one VO is composed with other objects - or by a binary mask. The extended MPEG-4 content-based approach can be seen as a logical extension of the conventional MPEG-4 VLBV Core or high bit-rate tools towards input of arbitrary shape. There are several scalable coding schemes in MPEG-4 Visual: spatial scalability, temporal scalability, fine granularity scalability and object-based spatial scalability. Spatial scalability supports changing the spatial resolution. Object-based spatial scalability extends the 'conventional' types of scalability towards arbitrary shape objects, so that it can be used in conjunction with other object-based capabilities. Thus, a very flexible content-based scaling of video information can be achieved. This makes it possible to enhance SNR, spatial resolution, shape accuracy, etc, only for objects of interest or for a particular region, which can be done dynamically at play-time. Fine granularity scalability (FGS) was developed in response to the growing need on a video coding standard for streaming video over the Internet. FGS and its combination with temporal scalability addresses a variety of challenging problems in delivering video over the Internet. FGS allows the content creator to code a video sequence once and to be delivered through channels with a wide range of bitrates. It provides the best user experience under varying channel conditions. It overcomes the “digital cutoff” problem associated with digital video. In other words, it makes compressed digital video behave similarly to analog video in terms of robustness while maintaining all the advantages of digital video.

Notes:

Silicon-IPTV-Broadcast -155

VLBV: Very Low Bit-rate Video

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -156

MPEG-4 provides error robustness and resilience to allow accessing image or video information over a wide range of storage and transmission media. In particular, due to the rapid growth of mobile communications, it is extremely important that access is available to audio and video information via wireless networks. This implies a need for useful operation of audio and video compression algorithms in error-prone environments at low bit-rates (i.e., less than 64 kbit/s). The error resilience tools developed for MPEG-4 can be divided into three major areas: resynchronization, data recovery, and error concealment. It should be noted that these categories are not unique to MPEG-4, but instead have been used by many researchers working in the area error resilience for video. It is, however, the tools contained in these categories that are of interest, and where MPEG-4 makes its contribution to the problem of error resilience. After synchronization has been reestablished, data recovery tools attempt to recover data that in general would be lost. These tools are not simply error correcting codes, but instead techniques that encode the data in an error resilient manner. For instance, one particular tool that has been endorsed by the Video Group is Reversible Variable Length Codes (RVLC). In this approach, the variable length codewords are designed such that they can be read both in the forward as well as the reverse direction. An example illustrating the use of a RVLC is given in Figure 19. Generally, in a situation such as this, where a burst of errors has corrupted a portion of the data, all data between the two synchronization points would be lost. However, as shown in the Figure, an RVLC enables some of that data to be recovered. It should be noted that the parameters, QP and HEC shown in the Figure, represent the fields reserved in the video packet header for the quantization parameter and the header extension code, respectively.

Notes:

Silicon-IPTV-Broadcast -156

Example of Sprite Coding of Video Sequence • The sprite panoramic background image is constructed and sent — This is held in a sprite buffer • Foreground object is transmitted separately as an arbitrary-shape video object

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -157

An important advantage of the content-based coding approach MPEG-4 is that the compression efficiency can be significantly improved for some video sequences by using appropriate and dedicated object-based motion prediction “tools” for each object in a scene. A number of motion prediction techniques can be used to allow efficient coding and flexible presentation of the objects: Standard 8x8 or 16x16 pixel block-based motion estimation and compensation, with up to ¼ pel accuracy Global Motion Compensation (GMC) for video objects: Encoding of the global motion for a object using a small number of parameters. GMC is based on global motion estimation, image warping, motion trajectory coding, and texture coding for prediction errors. Global motion compensation based for static “sprites”. A static sprite is a possibly large still image, describing panoramic background. For each consecutive image in a sequence, only 8 global motion parameters describing camera motion are coded to reconstruct the object. These parameters represent the appropriate affine transform of the sprite transmitted in the first frame. Quarter Pel Motion Compensation enhances the precision of the motion compensation scheme, at the cost of only small syntactical and computational overhead. A accurate motion description leads to a smaller prediction error and, hence, to better visual quality. Shape-adaptive DCT: In the area of texture coding, the shape-adaptive DCT (SA-DCT) improves the coding efficiency of arbitrary shaped objects. The SA-DCT algorithm is based on predefined orthonormal sets of one-dimensional DCT basis functions. This slidevdepicts the basic concept for coding an MPEG-4 video sequence using a sprite panorama image. It is assumed that the foreground object (tennis player, image top right) can be segmented from the background and that the sprite panorama image can be extracted from the sequence prior to coding. (A sprite panorama is a still image that describes as a static image the content of the background over all frames in the sequence). The large panorama sprite image is transmitted to the receiver only once as first frame of the sequence to describe the background – the sprite remains is stored in a sprite buffer. In each consecutive frame only the camera parameters relevant for the background are transmitted to the receiver. This allows the receiver to reconstruct the background image for each frame in the sequence based on the sprite. The moving foreground object is transmitted separately as an arbitrary-shape video object. The receiver composes both the foreground and background images to reconstruct each frame (bottom picture in figure below). For low delay applications it is possible to transmit the sprite in multiple smaller pieces over consecutive frames or to build up the sprite at the decoder progressively.

Notes:

Silicon-IPTV-Broadcast -157

MPEG-4 Sound • Speech coding at bitrates between 2 and 24 kbit/s is supported by using Harmonic Vector eXcitation Coding (HVXC) for bit rates 2- 4 kbit/s • Code Excited Linear Predictive (CELP) coding for an operating bit rate of 4 - 24 kbit/s • For general audio coding at and above 6 kbit/s, transform coding techniques is used

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -158

MPEG-4 standardizes natural audio coding at bitrates ranging from 2 kbit/s up to and above 64 kbit/s. When variable rate coding is allowed, coding at less than 2 kbit/s, such as an average bitrate of 1.2 kbit/s, is also supported. The presence of the MPEG-2 AAC standard within the MPEG-4 tool set provides for general compression of audio in the upper bitrate range. For these, the MPEG-4 standard defines the bitstream syntax and the decoding processes in terms of a set of tools. In order to achieve the highest audio quality within the full range of bitrates and at the same time provide the extra functionalities, speech coding techniques and general audio coding techniques are integrated in a common framework: · Speech coding at bitrates between 2 and 24 kbit/s is supported by using Harmonic Vector eXcitation Coding (HVXC) for a recommended operating bitrate of 2 - 4 kbit/s, and Code Excited Linear Predictive (CELP) coding for an operating bitrate of 4 - 24 kbit/s. In addition, HVXC can operate down to an average of around 1.2 kbit/s in its variable bitrate mode. In CELP coding, two sampling rates, 8 and 16 kHz, are used to support narrowband and wideband speech, respectively. The following operating modes have been subject to verification testing: HVXC at 2 and 4 kbit/s, narrowband CELP at 6, 8.3, and 12 kbit/s, and wideband CELP at 18 kbit/s. In addition various of the scalable configurations have been verified. · For general audio coding at bitrates at and above 6 kbit/s, transform coding techniques, namely TwinVQ and AAC, are applied. The audio signals in this region typically have sampling frequencies starting at 8 kHz. To allow optimum coverage of the bitrates and to allow for bitrate and bandwidth scalability, a general framework has been defined.

Notes:

Silicon-IPTV-Broadcast -158

Audio Resilience • The error robustness tools provide improved performance on error-prone transmission channels • These tools reduce the perceived deterioration of the decoded audio signal that is caused by corrupted bits in the bit stream — Virtual CodeBook tool (VCB11) — Reversible Variable Length Coding tool (RVLC) – Encodes using shorter codes for frequently used sound — Huffman Codeword Reordering tool (HCR)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -159

The silence compression tool reduces the average bit rate thanks to a lower bit rate compression for silence. In the encoder, a voice activity detector is used to distinguish between regions with normal speech activity and those with silence or background noise. During normal speech activity, the CELP coding as in Version 1 is used. Otherwise a Silence Insertion Descriptor (SID) is transmitted at a lower bit rate. This SID enables a Comfort Noise Generator (CNG) in the decoder. The amplitude and spectral shape of this comfort noise is specified by energy and LPC parameters similar as in a normal CELP frame. These parameters are an optional part of the SID and thus can be updated as required. The Error Resilient (ER) HVXC object is supported by the Parametric speech coding (ER HVXC) tools, which provides fixed bit-rate modes(2.0-4.0kbps) and variable bit-rate mode(<2.0kbps, <4.0kbps) both in a scalable and non-scalable scheme. In the Version 1 HVXC, variable bit rate mode of 2.0 kbit/s maximum is already supported and the variable bit rate mode of 4.0 kbit/s maximum is additionally supported in Version 2 ER HVXC. In the variable bit rate modes, nonspeech parts are detected in unvoiced signals, and a smaller number of bits is used for these nonspeech parts to reduce the average bit rate. ER HVXC provides communications-quality to near-tollquality speech in the 100-3800 Hz band at 8kHz sampling rate. When the variable bit-rate mode is allowed, operation at lower average bit-rate is possible. Coded speech with variable bit-rate mode at typical bit-rate of 1.5kbps average, and at typical bit-rate of 3.0kbps average has essentially the same quality as 2.0 kbps fixed rate and 4.0 kbps fixed rate respectively. The functionality of pitch and speed change during decoding is supported for all modes. ER HVXC has the syntax with the error sensitivity classes to be used with the EP-Tool, and the error concealment functionality are supported for the use for error-prone channel like mobile communication channels. The ER HVXC speech coder targets applications from mobile and satellite communications, to Internet telephony, to packaged media and speech databases

Notes:

Silicon-IPTV-Broadcast -159

Carriage of MPEG-4 over IP • MPEG-4 can be carried over RTP/UDP/IP — UDP Delivers multiplexing by using port numbers — RTP adds a time stamp and sequence number to provide synchronization — IP provides addressing and routing

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -160

The specifications on the carriage of MPEG-4 contents over IP networks are developed jointly with IETF AVT working group. These include a framework and several RTP payload format specifications. The framework is standardized as both a part 8 of MPEG-4, i.e. ISO/IEC 14496-8 and informative RFC in IETF. RTP payload format specifications are only standardized as a standard track RFC in IETF. Framework is an umbrella specification for the carriage and operation of MPEG-4 sessions over IPbased protocols, including RTP, RTSP, and HTTP, among others. It provides a framework for the carriage of MPEG-4 contents over IP networks and guidelines for designing payload format specifications for the detailed mapping of MPEG-4 content into several IP-based protocols. To assure compatibility between different RTP payload formats, framework defines a conformance point as illustrated in the Figure 1. To conform this framework all the payload formats shall provide normative mapping functions to reconstruct logical MPEG-4 SL packets. Framework also defines the standard MIME types associated with MPEG-4 contents. Several RTP payload formats are developed under this framework including generic payload format and FlexMux payload format. Generic RTP payload format specify a homogeneous carriage of various MPEG-4 streams. It defines a simple but efficient mapping between logical MPEG-4 SL packets and RTP packets. It also supports concatenation of multiple SL packets into one RTP packets to minimize overheads. FlexMux payload format specifies a carriage of FlexMux packetized streams via RTP packets. It includes a payload formats to convey FlexMux descriptors to dynamically signal the configuration of FlexMux.

Notes:

Silicon-IPTV-Broadcast -160

H.264 and MPEG-4 Part 10 • H.264 Advanced Video Coding (AVC) • The following terms are used interchangeably: – H.26L – The Work of the JVT or “JVT CODEC” – JM2.x, JM3.x, JM4.x – The Thing Beyond H.26L – The “AVC” or Advanced Video CODEC • Proper Terminology going forward: – MPEG-4 Part 10 (Official MPEG Term) » ISO/IEC 14496-10 AVC – H.264 (Official ITU Term)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -161

Notes:

Silicon-IPTV-Broadcast -161

The JVT Project • Started as ITU-T Q.6/SG16 (VCEG - Video Coding Experts Group) “H.26L” standardization activity • August 1999: 1st test model (TML-1) • July 2001: MPEG open call for “AVC” technology: H.26L wins • December 2001: Formation of the Joint Video Team (JVT) between VCEG and MPEG to finalize H.26L as a joint project similar to MPEG-2/H.262) • July 2002: Final Committee Draft status in MPEG • Final approval completed in both orgs 2003

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -162

After finalising the original H.263 standard for videotelephony in 1995, the ITU-T Video Coding Experts Group (VCEG) started work on two further development areas: a “short-term” effort to add extra features to H.263 (resulting in Version 2 of the standard) and a “long-term” effort to develop a new standard for low bitrate visual communications. The long-term effort led to the draft “H.26L” standard, offering significantly better video compression efficiency than previous ITU-T standards. In 2001, the ISO Motion Picture Experts Group (MPEG) recognised the potential benefits of H.26L and the Joint Video Team (JVT) was formed, including experts from MPEG and VCEG. JVT’s main task is to develop the draft H.26L “model” into a full International Standard. In fact, the outcome will be two identical) standards: ISO MPEG4 Part 10 of MPEG4 and ITU-T H.264. The “official” title of the new standard is Advanced Video Coding (AVC); however, it is widely known by its old working title, H.26L and by its ITU document number, H.264.

Notes:

Silicon-IPTV-Broadcast -162

Relationship to Other Standards • Same design to be approved in both ITU-T and MPEG • In ITU-T this will is new & separate standard — ITU-T Recommendation H.264 — ITU-T systems (H.32x) to be modified to support it • In MPEG this will be a new “part” in the MPEG-4 suite — Separate codec design from prior MPEG-4 visual — New part 10 called “advanced video coding” (similar to “AAC” position in MPEG-2 as separate codec) — Not backward compatible with prior standards (incl. the prior MPEG-4 visual spec. – core technology is different) — MPEG-4 Systems / File Format modifying to support it • H.222.0 | MPEG-2 Systems will also be modified to support it • IETF working on RTP payload packetization: — RTP Payload Format for H.264 Video RFC 3984 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -163

Notes:

Silicon-IPTV-Broadcast -163

JVT Project Technical Objectives • Primary technical objectives: — Significant improvement in coding efficiency: Average bit rate reduction of 50% given fixed fidelity compared to any other video standard — Error robustness & “Network Friendliness” (carry it well on MPEG-2 or RTP Issues examined in H.263 and MPEG-4 are further improved — Low latency capability (better quality for higher latency) — Exact match decoding — Simple syntax specification – Targeting simple and clean solutions – Avoiding any excessive quantity of optional features or profile configurations

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -164

Notes:

Silicon-IPTV-Broadcast -164

Need for H.264: MPEG-2 Has Hit A Wall

6 5

1st MPEG-2 Encoder MPEG-2 Standard Frozen (H.262)

2nd Generation Encoder 3rd Generation Encoder

4 Mbit/s

MPEG-2

4th Generation Encoder

3

5th Generation Encoder

2 1 0 1994

1995

1996

1997

1998

1999

2000

2001

2002

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

2003

2004

2005

Silicon-IPTV-Broadcast -165

Notes:

Silicon-IPTV-Broadcast -165

MPEG-4 in Comparison 1st MPEG-2 Encoder

6

2nd Generation Encoder

5 3rd Generation Encoder

4

MPEG-2

Mbit/s

MPEG-4

4th Generation Encoder

3

H.263

5th Generation Encoder

2 1 0 1994

1995

1996

1997

1998

1999

2000

2001

2002

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

2003

2004

2005

Silicon-IPTV-Broadcast -166

Notes:

Silicon-IPTV-Broadcast -166

H.26L Provides Focus 1st MPEG-2 Encoder

6

2nd Generation Encoder

5 3rd Generation Encoder

MPEG-2

Mbit/s

4

MPEG-4 H.26L

4th Generation Encoder

3

H.263

5th Generation Encoder

2 1 0 1994

1995

1996

1997

1998

1999

2000

2001

2002

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

2003

2004

2005

Silicon-IPTV-Broadcast -167

Notes:

Silicon-IPTV-Broadcast -167

MPEG-4 “Adopts” H.26L 1st MPEG-2 Encoder

6

2nd Generation Encoder

5 3rd Generation Encoder

Mbit/s

4

MPEG-2 MPEG-4 H.26L

4th Generation Encoder

3

H.263 th

5 Generation Encoder

2 1 H.264 / MPEG-4 part 10

0 1994

1995

1996

1997

1998

1999

2000

2001

2002

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

2003

2004

2005

Silicon-IPTV-Broadcast -168

Notes:

Silicon-IPTV-Broadcast -168

MPEG-4 Example

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -169

Notes:

Silicon-IPTV-Broadcast -169

MPEG-4 Example

This and Previous drawing are PRIMARY examples from MPEG-4 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -170

Notes:

Silicon-IPTV-Broadcast -170

More More MPEG-4 MPEG-4 Solutions Solutions in in Search Search of of Problems Problems

“2-D mesh modeling of video object - By deforming the mesh, the fish can be animated very efficiently, and be made to swim. Also, a logo could be projected onto the fish, and made to move in accordance with the fish” © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -171

Notes:

Silicon-IPTV-Broadcast -171

MPEG-4 Audio Tools Coding tool

Channels

AAC

5

Total bit rate 320 kb/s

Grading scale Subjective quality impairment 4.6

1995 Backward Compatible MPEG-2 Layer II

5

640 kb/s

impairment

4.6

AAC

2

128 kb/s

impairment

4.8

AAC

2

96 kb/s

impairment

4.4

MPEG-1 Layer II

2

192 kb/s

impairment

4.3

MPEG-1 Layer III

2

128 kb/s

impairment

4.1

AAC

1

24 kb/s

quality

4.2

Scalable: CELP base and AAC enhancement Scalable: Twin VQ base and AAC enhancement AAC

1

quality

3.7

1

quality

3.6

1

6 kb/s base, 18 kb/s enh. 6 kb/s base, 18 kb/s enh. 18 kb/s

quality

3.2

G.723

1

6.3 kb/s

quality

2.8

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -172

Notes:

Silicon-IPTV-Broadcast -172

MPEG-4 Audio Tools Coding tool

Channels

Total bit rate

Grading scale Subjective quality

Wideband CELP

1

18.2 kb/s

quality

2.3

BSAC

2

96 kb/s

quality

4.4

BSAC

2

80 kb/s

quality

3.7

BSAC

2

64 kb/s

quality

3.0

AAC ・Low Delay

1

64 kb/s

quality

4.4

G.722

1

64 kb/s

quality

4.2

AAC ・Low Delay

1

32 kb/s

quality

3.4

Narrowband CELP

1

6 kb/s

quality

2.5

Twin VQ

1

6 kb/s

quality

1.8

HILN

1

16 kb/s

quality

2.8

HILN

1

6 kb/s

quality

1.8

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -173

Notes:

Silicon-IPTV-Broadcast -173

Applications for AVC/H.264 • Entertainment Video (1 - 8+ Mbps, higher latency) — Broadcast / Satellite / Cable / DVD / VoD / FS-VDSL / … • Conversational H.32X Services (usu. <1Mbps, low latency) — H.320 Conversational — 3GPP Conversational H.324/M — H.323 Conversational Internet/unmanaged/best effort IP/RTP — 3GPP Conversational IP/RTP/SIP • Streaming Services (usu. lower bit rate, higher latency) — 3GPP Streaming IP/RTP/RTSP — Streaming IP/RTP/RTSP (without TCP fallback) • Other Services — 3GPP Multimedia Messaging Services

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -174

Notes:

Silicon-IPTV-Broadcast -174

The Scope of Picture and Video Coding Standardization

• Only the Syntax and Decoder are standardized:

— Permits optimization beyond the obvious — Permits complexity reduction for implementability — Provides no guarantees of Quality

Source Destination

Pre-Processing

Encoding

Post-Processing & Error Recovery

Decoding Scope of Standard

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -175

In common with earlier standards (such as MPEG1, MPEG2 and MPEG4), the H.264 draft standard does not explicitly define a CODEC (enCOder / DECoder pair). Rather, the standard defines the syntax of an encoded video bitstream together with the method of decoding this bitstream. In practice, however, a compliant encoder and decoder are likely to include the functional elements shown. Whilst the functions shown in these Figures are likely to be necessary for compliance, there is scope for considerable variation in the structure of the CODEC. The basic functional elements (prediction, transform, quantization, entropy encoding) are little different from previous standards MPEG1, MPEG2, MPEG4, H.261, H.263); the important changes in H.264 occur in the details of each functional element.

Notes:

Silicon-IPTV-Broadcast -175

AVC Encoder

Motion Imagery Sources

Encoder System GUI

Video Sensors, SMPTE Streams, Networked Video, Video Servers

DGFX PVA Frequency Shaping & Noise Reduction

DGFX PVA Hi Quality Chroma Processing

AVC Encoder

VLSI Chip or Chips

W/Exact Match

10 (& 12) Bit Enabled

Logical System Interconnect (HW or SW) CODEC System Platform & CPU

V

MD

Bitstream Output

NAL: MPEG-2 or Other Xport AVC’s Network Adaptation Layer (NAL) Supports a Range of Xport Layer Formats & Protocols (Similar to SMPTE Abstraction)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -176

Notes:

Silicon-IPTV-Broadcast -176

Comparison to MPEG-2, H.263, MPEG-4

Quality Y-PSNR [dB]

Foreman QCIF 10Hz

39 38 37 36 35 34 33 32 31 30 29 28 27

JVT/H.264/AVC MPEG-4 MPEG-2 H.263

0

50

100 150 Bit-rate [kbit/s]

200

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

250

Silicon-IPTV-Broadcast -177

Notes:

Silicon-IPTV-Broadcast -177

Comparison to MPEG-2, H.263, MPEG-4 CIF 30Hz

Peek Signal to Noise Ratio

Quality Y-PSNR [dB]

38 37 36 35 34 33 32 31 30 29 28 27 26 25

JVT/H.264/AVC MPEG-4 MPEG-2 H.263 0

500

1000

1500

2000

2500

3000

3500

Bit-rate [kbit/s] © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -178

Notes:

Silicon-IPTV-Broadcast -178

CODEC Comparison (Normalized speed In Mbps) Sequence 1-College Football 2-Panasonic Girls 3-Preakness

Attributes

Fast motion, high detail Skin tones, water Random motion 4-Philips Motion, high Liquids detail 5-Oscars ’02 Slow motion, high detail 6-Test Signals High detail, measurable

MPEG-2

AVC-1

AVC-2

26.7

7.3

4.6

10.1

4.2

2.2

70.0

30.8

23.3

2.9

0.9

9.5

2.5

1.2

1.4

0.8

0.1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -179

Notes:

Silicon-IPTV-Broadcast -179

AVC/H.264 Profiles • High Profile — Highest compression or video quality at a given bit rate — Suitable for good quality entertainment video distribution • Baseline Profile — Least complexity — Error resilient — Suitable for telephony, conferencing application

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -180

Notes:

Silicon-IPTV-Broadcast -180

AVC/H.264 – Levels • Level 1.0: QCIF @ 15frames/sec • Level 1.1: QCIF @ 30 frames/sec, CIF @7.5 frames/sec • Level 1.2: CIF @ 15 frames/sec • • • • • • • • •

Level 2.0: CIF @ 30 frames/sec Level 2.1: HHR @ 25 or 30 frames/sec Level 2.2: SDTV @ 15 frames/sec Level 3.0: SDTV: 720x480x30i, 720x576x25i — 10 Mbps (max.), up to 5 (max. resolution) reference frames Level 3.1: HDTV - 1280x720x30p, SVGA (800x600) 50+p Level 3.2: HDTV - 1280x720x60p Level 4.0: HDTV (all formats) - 1920x1080x30i, 1280x720x60p, 2kx1kx30p — 20 Mbps (max.), up to 4 (max. resolution) reference frames Level 4.1: HDTV - 1920x1080x30i, 1280x720x60p, 2kx1kx30p — 50 Mbps, up to 4 (max. resolution) reference frames Level 4.2: S-HDTV - 1920x1080x60p

• Level 5.0: S-HDTV/D-Cinema – 2kx1kx72p • Level 5.1: S-HDTV/D-Cinema – 2kx1kx120p, 4kx2kx24p, 4kx2kx30p © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -181

Notes:

Silicon-IPTV-Broadcast -181

Transport of AVC / H.264 • Transport of MPEG-4 AVC using MPEG-2 System: ISO/IEC 13818-1 — PDAM (Proposed Draft AMendment) in May 2002 — FPDAM (Final Proposed Draft AMendment) in Dec 2002 — FDAM in July 2003 — Approved AMD • IP delivery — MPEG-2 TS over UDP/IP, or — RTP over IP

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -182

Notes:

Silicon-IPTV-Broadcast -182

DVB Project • ETSI TR 101 200 — Digital Video Broadcasting (DVB);A guideline for the use of DVB specifications and standards — Originally from DVB.org Blue Books • Included different delivery technologies originally — Satellite (DVB-S and DVB-S2) — Cable (DVB-C) — Terrestrial television (DVB-T) — Terrestrial television for handhelds (DVB-H) • Later DVB-IPI added

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -183

DVB, short for Digital Video Broadcasting, is a suite of internationally accepted, open standards for digital television maintained by the DVB Project, an industry consortium with more than 270 members, and published by a Joint Technical Committee (JTC) of European Telecommunications Standards Institute (ETSI), European Committee for Electrotechnical Standardization (CENELEC) and European Broadcasting Union (EBU). How the several DVB sub-standards interact is described in the DVB Cookbook from DVB.org. One of the fundamental decisions which were taken during the early days of the DVB Project was the selection of MPEG-2 for the source coding of audio and video and for the creation of programme elementary streams, Transport Streams (TS), etc.; the so-called Systems level. The ISO/IEC 13818 Parts 1, 2, 3 [60], [61], [62] are international standards which describe MPEG-2 Systems, Video and Audio. All three are truly generic and can be considered too wide in scope for them to be applied to DVB directly.

Notes:

Silicon-IPTV-Broadcast -183

DVB Standards

• DVB.org • Industry Group • Developed DVB standards • Blue Books • Have become ETSI

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -184

From time to time, DVB publishes documents approved by its Steering Board: the BlueBooks. In practice, these are either commercial requirements documents, policy statements, or technical specifications which are being standardised. In the latter case, DVB has decided that there is value the in rapid publication of draft specifications as BlueBooks, pending their formal standardisation. The BlueBooks available on the DVB.org site are those that have not since been superceded by a published standard. All DVB standards, specifications and reports can be downloaded free of charge from the ETSI website. A086 (DVB-IPI) is not listed but can be found using a search at http://www.dvb.org/technology/standards_specifications/internet_protocol/dvbipi/ or as ETSI standard TS 102 034.

Notes:

Silicon-IPTV-Broadcast -184

DVB-C Standard Over Cable • DVB-C is Digital video Broadcasting over Cable • Standards for Cable systems are available at http://www.cablelabs.org

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -185

DVB-C is the digital Video broadcast standard for cable operation. Source coding and MPEG-2 multiplexing (MUX): video, audio, and data streams are multiplexed into an MPEG-2 PS (MPEG-2 Programme Stream). One or more PSs are joined together into a MPEG-2 TS (MPEG-2 Transport Stream); this is the basic digital stream which is being transmitted and received by home Set Top Boxes (STB). Allowed bitrates for the transported MPEG-2 depend on a number of modulation parameters: it can range from about 6 to about 64 Mbit/s (see the bottom figure for a complete listing). MUX adaptation and energy dispersal: the MPEG-2 TS is identified as a sequence of data packets, of fixed length (188 bytes). With a technique called energy dispersal, the byte sequence is decorrelated. External encoder: a first level of protection is applied to the transmitted data, using a nonbinary block code, a Reed-Solomon RS (204, 188) code, allowing the correction of up to a maximum of 8 wrong bytes for each 188-byte packet. External interleaver: convolutional interleaving is used to rearrange the transmitted data sequence, such way it becomes more rugged to long sequences of errors. Byte/m-tuple conversion: data bytes are encoded into bit m-tuples (m = 4, 5, 6, 7, or 8). Differential coding: the two most significant bytes in each m-tuple are encoded in order to give some ruggedness to the signal. QAM Mapper: the bit sequence is mapped into a baseband digital sequence of complex symbols. There are 5 allowed modulation modes: 16-QAM, 32QAM, 64-QAM, 128-QAM, 256-QAM. Base-band shaping: the QAM signal is filtered with a raised-cosine shaped filter, in order to remove mutual signal interference at the receiving side. DAC and front-end: the digital signal is transformed into an analog signal, with a digital-to-analog converter (DAC), and then modulated to radio frequency by the RF front-end.

Notes:

Silicon-IPTV-Broadcast -185

DVB-H • Digital Video Broadcast for Handhelds — ETSI EN 302 304 V1.1.1 (2004-11) – Digital Video Broadcasting (DVB);Transmission System for Handheld Terminals (DVB-H) — ETSI TS 102 472 V1.1.1 (2006-06) – Digital Video Broadcasting (DVB);IP Datacast over DVB-H: Content Delivery Protocols

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -186

DVB-H (Digital Video Broadcasting - Handheld) is a technical specification for bringing broadcast services to handheld receivers. was formally adopted as ETSI standard EN 302 304 in November 2004. The DVB-H specification (EN 302 304) can be downloaded from the DVB-H Online website[1]. The major competitor of this technology is Digital Multimedia Broadcasting (DMB). The conceptual structure of a DVB-H receiver is depicted here. It includes a DVBH demodulator and a DVB-H terminal. The DVB-H demodulator includes a DVBT demodulator, a time-slicing module and a MPE-FEC module. The DVB-T demodulator recovers the MPEG-2 Transport Stream packets from the received DVB-T (EN 300 744 [1]) RF signal. It offers three transmission modes 8K, 4K and 2K with the corresponding Transmitter Parameter Signalling (TPS). Note that the 4K mode, the in-depth interleavers and the DVB-H signalling have been defined while elaborating the DVB-H standard. The time-slicing module, provided by DVB-H, aims to save receiver power consumption while enabling to perform smooth and seamless frequency handhover. The MPE-FEC module, provided by DVB-H, offers over the physical layer transmission, a complementary forward error correction allowing the receiver to cope with particularly difficult receiving situations.

Notes:

Silicon-IPTV-Broadcast -186

DVB-T • Digital Video Broadcasting over Terrestrial • ETSI EN 300 744 — Framing structure, channel coding and modulation for digital terrestrial television • ETSI EN 301 958 — Interaction channel for Digital Terrestrial Television (RCT) incorporating Multiple Access OFDM • ETSI TR 101 190 — Implementation guidelines for DVB terrestrial services;Transmission aspects

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -187

VB-T stands for Digital Video Broadcasting - Terrestrial and it is the DVB European consortium standard for the broadcast transmission of digital terrestrial television. This system transmits a compressed digital audio/video stream, using OFDM modulation with concatenated channel coding (i.e. COFDM). The adopted source coding methods are MPEG-2 and, more recently, H.264. In January 2006, a study group named TM-T2_SM (Study Mission on Second Generation DVB-T) has been established by DVB Group for investigation of advanced modulation schemes that could be adopted by a second generation digital terrestrial television standard .

Notes:

Silicon-IPTV-Broadcast -187

DVB-IPI • Digital Video Broadcasting over IP Interfaces • ETSI TR 102 033 — Architectural Framework for the Delivery of DVB Services over IP-based Networks • ETSI TR 102 034 (Formerly DVB.org Blue Book A086) — Transport of MPEG-2 Based DVB Services over IP Based Networks • ETSI TS 102 813 — Transport of DVB Services over IP-based Networks: IEEE 1394 Home Network Segment • ETSI TS 102 814 — Transport of DVB Services over IP-based Networks: Ethernet Home Network Segment

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -188

DVB-IPI is the set of standards for delivery of DVB over IP interfaces. It evolved from the DVB.org Blue Book A086 standard and now forms the basis for most IPTV distribution systems. TR 102 034 is the original document which concentrates on the Transport of DVB over IP.

Notes:

Silicon-IPTV-Broadcast -188

DVB-IPI Architecture TR 102 033 • The Architecture defines 4 domains

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -189

Content Provider: the entity who owns or is licensed to sell content or content assets. Although the Service Provider is the primary source for the client at Home, a direct logical information flow may be set up between Content Provider and Home client e.g. for rights management and protection. Service Provider: the entity providing a service to the client. Different types of service provider may be relevant for DVB services on IP, e.g. simple Internet Service Providers (ISPs) and Content Service Providers (CSPs). In the context of DVB services on IP, the CSP acquires/licenses content from Content Providers and packages this into a service. In this sense the service provider is not necessarily transparent to the application and content information flow. Delivery Network: the entity connecting clients and service providers. The delivery system usually is composed of access networks and core or backbone networks, using a variety of network technologies. The delivery network is transparent to the IP traffic, although there may be timing and packet loss issues relevant for A/V content streamed on IP. Home: the domain where the A/V services are consumed. In the home a single terminal may be used for service consumption, but also a network of terminals and related devices may be present for this purpose

Notes:

Silicon-IPTV-Broadcast -189

DVB-IPI Home Reference Model

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -190

1) A home network can be simultaneously connected to multiple and heterogeneous delivery networks. As an example, in a typical scenario ADSL and DVB-S are both available at the home. Load balancing may be possible between the different delivery networks in order to optimize the utilization and throughput of the networks and to minimize the delay. 2) End users can choose the service provider. As an example, the ISPs and the CSPs may be independent from each other. 3) Different end users in the same home network can select different service providers. 4) Access to the content is independent from the underlying hardware.As an example, terminals with different capabilities (e.g. CPU power, display size, storage capacity) may be allowed to access to the same content through the use of transcoding resources, or through the use of device specific resources. 5) Roaming of end users between delivery networks should be possible. As an example, the personal environment of a (SOHO) user stored on a home server should be accessible from different external locations. Adequate security aspects need to be taken into account.

Notes:

Silicon-IPTV-Broadcast -190

DVB-IPI • TS 102 034 species a specific subset of Internet Protocols to be used — Real-Time Streaming Protocol (RTSP) and Real Time Protocol are used — These transport delivery of broadcast TV and audio

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -191

This is a logical diagram of the high-level protocols on the IPI-1 interface, specified in the present document for enabling DVB services over IP-based networks. The organization of this protocol stack is according to the ISO/OSI layering convention. The top layer of this stack signifies the service offering intended by the Service Provider. This consists of programs, information about programs, multicast- and/or unicast IP addresses; in short, the essential items needed to enable a DVB service over an IP network. The present TS 102 034 document specifies the protocols required for transport of elements of the service offering via IP networking, in principle independent of the physical layers below the IP networking layer. However, for use in future DVB Home Networking, the present document also specifies the Ethernet and IEEE 1394 Home Network Segments as physical layers. They are shown in their correct place, at the bottom of the diagram. The HNED is an IP compliant device; on its IPI-1 interface it supports the requirements laid down in RFC 1122. HTTP, TCP, UDP and IP are available to the HNED as networking and transport protocols.S

Notes:

Silicon-IPTV-Broadcast -191

Broadcast Distribution Systems

Cable TV Delivery Systems Terrestrial Delivery IP Delivery Encoding Methods Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -192

Notes:

Silicon-IPTV-Broadcast -192

Chapter Summary Now you have completed this chapter you can • Examine component parts of a TV distribution networks • Explore how the various systems options • Identify the key interfaces • Predict how the technology will evolve in the near future • Examine the encoding and compression standards

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -193

Notes:

Silicon-IPTV-Broadcast -193

Engineering Reliable IP Services

Notes:

Silicon-IPTV-Broadcast -194

Course Objectives • When you have completed this course you will be able to:• Engineer addressing schemes for IP network prefix configurations • Add resilience to MAC/IP mappings for reliable redundancy switching • Select the best routing and switching strategy for server and delivery networks • Analyze protocols used to carry multimedia and troubleshoot services problems • Appreciate how multicast routing protocols function • Specify requirements for firewall transit of video services

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -195

Notes:

Silicon-IPTV-Broadcast -195

Course Materials • Course Notes — Copies of all slides and supplemental presentation material

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -196

Notes:

Silicon-IPTV-Broadcast -196

Course Contents Introduction and Overview Chapter 1

Internet Protocol Suite Delivery of Multimedia Service

Chapter 2

Addressing

Chapter 3

Routing

Chapter 4

Managing Devices With SNMP

Chapter 5

Course Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -197

Notes:

Silicon-IPTV-Broadcast -197

Course Contents (Continued)

Appendix A

Networks Glossary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -198

Notes:

Silicon-IPTV-Broadcast -198

Course Schedule Each day, the course will follow this schedule: Start class

9:30 a.m.

Morning break

10:30 a.m. (approximately)

Lunch Resume class Afternoon break(s)

As needed

Adjourn

5:00 p.m.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -199

Notes:

Silicon-IPTV-Broadcast -199

Logistics • Restrooms/toilets • Drinking fountains, coffee and soft drink machines, snacks • Restaurants • Messages/phones • Security • Emergency measures • Use of equipment after class hours (if applicable) • Other important items

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -200

Notes:

Silicon-IPTV-Broadcast -200

Course Instructor • Background and education • Current position • Experience

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -201

Notes:

Silicon-IPTV-Broadcast -201

Attendee Introductions • Your name • Organization name • Current position • Experience in:— Telecommunications — TCP/IP networking • Expectations

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -202

Notes:

Silicon-IPTV-Broadcast -202

Chapter 3

Internet Protocol Suite Delivery of Multimedia Services

In this chapter we will examine all the protocols that were used in order to connect and operate the VoIP calls we used in demonstration 1 and captured in demonstration2. You can work from the LANwatch capture that you made of a real call or from the handout of a previous capture.

Notes:

Silicon-IPTV-Broadcast -203

Chapter Objectives When you have completed this chapter you will be able to • Describe the key protocols used for voice over IP • Discuss addressing and routing in IP networks • Explore the operation of applications within IP networks • Characterize the behavior of TCP/IP networks • Compare some alternative WAN technologies

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -204

Notes:

Silicon-IPTV-Broadcast -204

Internet Protocol Suite Delivery of Multimedia Services TCP/IP Architecture

Network Links

IP

TCP and UDP

Applications

Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -205

Notes:

Silicon-IPTV-Broadcast -205

Can We Put Voice on Our Data Networks? • IP networks are packet networks, which provoke several questions: — Can we transmit voice over packets? — What protocols would we use? — What is the impact on our data network? • Voice requires reliable, timely delivery; i.e., it is a “real-time” application — Can this be done on “best-effort” data networks? — What protocols can deal with this requirement? • Voice networks need high reliability and availability — Can data network routing protocols cope with outages quickly enough? • To connect a VoIP device, we need — IP addresses — Physical connectivity – Where and how should we connect devices?

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -206

Telephone companies (Telcos) are optimized for voice. (Shannon’s Law, Erlang Tables) Lans and Wans are optimized for throughput (RSVP, Tag Switching). Voice to Data ratios on telcos are tipping in favor of Data. Doesn’t it make sense to put voice on the data network rather than the other way around? Isn’t this just another way of saying that all networks are migrating (or will migrate) to data as the voice/data ratio becomes distorted in favor of data?

Notes:

Silicon-IPTV-Broadcast -206

Sources of Network Standards • There are two major standards groups of importance • International Telecommunications Union (ITU) • Internet Engineering Task Force (IETF)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -207

There are two important sources of standards that are vendor independent. Standards are said to be open if they are:1. Built to standards 2. Vendor Independent 3. Widely available

Notes:

Silicon-IPTV-Broadcast -207

International Telecommunications Union (ITU) • The only telecommunications body with United Nations Charter • Interested in International Interconnection — National standards bodies adapt and extend standards • European Telecommunications Standards Institute (ETSI) evolve from these • Recognize standards from numbers — A for administrative — E for numbering plans — G for trunk and CODEC standards — H for multimedia standards (VoIP) — Q for Signaling — V for data over analog telephony — X for digital data standards — and others • See http://www.itu.org © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -208

ITU standards are internationally recognized. The ITU is the ONLY international body with a charter from the UN to deliver standards. Historically they were produced every four years, being voted on at a large conference held every four years in a warm location. From 1992 onwards the reviews of standards have been as and when required allowing for much faster evolution of standards. A critical difficulty is the need under the charter for there to be agreement from major nations. This has caused some standards to be held up because of national interests. Standards must be purchased or subscribed to. Downloading a single standard can be expensive for an individual.

Notes:

Silicon-IPTV-Broadcast -208

Internet Engineering Task Force (IETF) • Produces standards upon which Internet is based • Called Requests For Comment (RFC) — Most RFCs are proposals for standards — Only small proportion finally accepted • Available free via the Internet — Information available from Internet Assigned Numbers Authority – http://www.iana.org/ — Downloadable from http://www.ietf.org/rfc.html — List of current standards in STD 1 — http://rfc.net/std1.html — Currently RFC3600

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -209

The IETF is an unpaid voluntary body that is heavily dominated in practice by American companies and Universities. However it tends to develop standards much faster than the ITU. Ideas for new standards are produced as RFCs and these may or may not eventually become standards. All standards and drafts are freely available over the Internet.

Notes:

Silicon-IPTV-Broadcast -209

Internet Protocol Suite Structure OSI Model 7. Application

Internet Model

6. Presentation

Application

Application

Transport

Transport

3. Network

Internet

Internet

2. Data Link

Network interface

Network interface

1. Physical

Hardware

Hardware

5. Session 4. Transport

TCP/IP

• IP does not care what the lower layers are: LAN or WAN — WAN can be frame relay, ATM, Point-to-Point Protocol (PPP) OSI = Open Systems Interconnection © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -210

We need to point out here that the top three layers of the OSI model are the application running in the PCs. A similar application is running less visibly in the routers to achieve the connection and operation.

Notes:

Silicon-IPTV-Broadcast -210

OSI Model • ISO 7498 and ITU-T X.200

Application Presentation Session Transport Network Data Link Physical

7

• P rovide s a pplica tion s e rvice s

6

• P rovide s da ta re pre s e nta tion

5

• P rovide s che ckpointing, a ctivity ma na ge me nt

4

• P rovide s e nd-to-e nd da ta inte grity

3

• Route s a nd re la ys

2

• Ma na ge s communica tion be twe e n a dja ce nt node s

1

• Tra ns mits bit s tre a m ove r phys ica l me dium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -211

The OSI model has 7 layers as this is the way the human brain works. The average person can hold in their mind only about 7 (plus or minus 2) ideas at any one time. Therefore we divide the functions of communications into 7 groups. The ISO standard for the model is very abstract and complex. We shall therefore translate this into simple, easy to grasp rules of thumb; roughly what each layer does in simple terms.

Notes:

Silicon-IPTV-Broadcast -211

OSI Model • ISO 7498 and ITU-T X.200

Application Presentation Session Transport Network Data Link Moves Bits

Physical

7

• P rovide s a pplica tion s e rvice s

6

• P rovide s da ta re pre s e nta tion

5

• P rovide s che ckpointing, a ctivity ma na ge me nt

4

• P rovide s e nd-to-e nd da ta inte grity

3

• Route s a nd re la ys

2

• Ma na ge s communica tion be twe e n a dja ce nt node s

1

• Tra ns mits bit s tre a m ove r phys ica l me dium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -212

Layer 1 moves bits. Anything to do with moving bits is layer 1. Electrical levels that represent bits, the cables through which the bits move, the plugs and sockets that join the cables, the timing of the bits.- all these are layer 1. Layer 1 is governed by the laws of physics and the laws of nature — one law of nature above all others — Murphy’s First Law. If things can go wrong they will; they will go wrong most in layer 1. So now we need a layer of firmware to detect errors. This is layer 2.

Notes:

Silicon-IPTV-Broadcast -212

OSI Model • ISO 7498 and ITU-T X.200

Application Presentation Session Transport Network Detects Errors

Data Link

Moves Bits

Physical

7

• P rovide s a pplica tion s e rvice s

6

• P rovide s da ta re pre s e nta tion

5

• P rovide s che ckpointing, a ctivity ma na ge me nt

4

• P rovide s e nd-to-e nd da ta inte grity

3

• Route s a nd re la ys

2

• Ma na ge s communica tion be twe e n a dja ce nt node s

1

• Tra ns mits bit s tre a m ove r phys ica l me dium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -213

Layer 2 detects errors. Anything to do with error detection is layer 2. We may divide the bit stream up into groups of bits called frames and calculate an error check which is sent at the end of the frame. This is known as a Frame Check Sequence or Cyclic Redundancy Check. While layer 2 is responsible for framing and error detection it is not required to correct the errors it finds. Some layer 2 protocols do but most don’t. I could construct a network of nodes interconnected by layer 1 cables, each link running a layer 2 detecting errors. However to deliver the data to the correct destination I need Routing which is the job of layer 3.

Notes:

Silicon-IPTV-Broadcast -213

OSI Model • ISO 7498 and ITU-T X.200

Application Presentation Session Transport Routing

Network

Detects Errors

Data Link

Moves Bits

Physical

7

• P rovide s a pplica tion s e rvice s

6

• P rovide s da ta re pre s e nta tion

5

• P rovide s che ckpointing, a ctivity ma na ge me nt

4

• P rovide s e nd-to-e nd da ta inte grity

3

• Route s a nd re la ys

2

• Ma na ge s communica tion be twe e n a dja ce nt node s

1

• Tra ns mits bit s tre a m ove r phys ica l me dium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -214

Layer 3 does routing. How did you get here today? I came by centralized static router — I came by train. You may have come by distributed dynamic router — taxi, or even by distributed static router — bus. There are many forms of routing, some have advantages over others. We will look at some of these later but in our case notice they all worked. However have you ever jumped on the wrong train, or missed your stop, or even found that your train was cancelled. Yes, the network layer can make mistakes. Not deliberate mistakes, but failures in the network can cause data to be lost. To fix this we need a transport layer.

Notes:

Silicon-IPTV-Broadcast -214

OSI Model • ISO 7498 and ITU-T X.200

Application Presentation Session End to End Error Recovery Routing

Transport Network

Detects Errors

Data Link

Moves Bits

Physical

7

• P rovide s a pplica tion s e rvice s

6

• P rovide s da ta re pre s e nta tion

5

• P rovide s che ckpointing, a ctivity ma na ge me nt

4

• P rovide s e nd-to-e nd da ta inte grity

3

• Route s a nd re la ys

2

• Ma na ge s communica tion be twe e n a dja ce nt node s

1

• Tra ns mits bit s tre a m ove r phys ica l me dium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -215

Layer 4, the Transport layer, runs from end-to-end and corrects errors the lower layers leave behind. It is this layer that guarantees the correct delivery of the data. Notice that it is in the ends not in the middle of the network. On the Internet when you are surfing the Transport layer runs in your desktop computer and in the web server itself — it does not run in the router within the Internet.

Notes:

Silicon-IPTV-Broadcast -215

OSI Model • ISO 7498 and ITU-T X.200

Application Presentation Checkpoints and Activities

Session

End to End Error Recovery

Transport

Routing

Network

Detects Errors

Data Link

Moves Bits

Physical

7

• P rovide s a pplica tion s e rvice s

6

• P rovide s da ta re pre s e nta tion

5

• P rovide s che ckpointing, a ctivity ma na ge me nt

4

• P rovide s e nd-to-e nd da ta inte grity

3

• Route s a nd re la ys

2

• Ma na ge s communica tion be twe e n a dja ce nt node s

1

• Tra ns mits bit s tre a m ove r phys ica l me dium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -216

Layers 5, 6 and 7 add services to the network. The first group of these is added by layer 5 — the Session layer. This layer adds checkpoints and activities. Checkpoints are points in a conversation that we can go back to. If you have ever surfed the Internet you have used the session layer without realizing it. When you click on a web link the system takes you to a new web page but remembers where you came from within the session layer. At any time you can click the back button on the web browser and return to exactly the point where you clicked the link. This is the purpose of checkpoints. However some systems are so simple that they have only a single transaction perhaps taking money from an automatic teller machine. This will start an activity at the start of the transaction (when you insert your plastic card) and then request input from you. If you press the return-card button, the system will abort the activity. If on the other hand you complete the transaction it will end-activity and update all the databases. Yes, databases depend upon the session layer.

Notes:

Silicon-IPTV-Broadcast -216

OSI Model • ISO 7498 and ITU-T X.200

Application Converts bits to Objects

Presentation

Checkpoints and Activities

Session

End to End Error Recovery

Transport

Routing

Network

Detects Errors

Data Link

Moves Bits

Physical

7

• P rovide s a pplica tion s e rvice s

6

• P rovide s da ta re pre s e nta tion

5

• P rovide s che ckpointing, a ctivity ma na ge me nt

4

• P rovide s e nd-to-e nd da ta inte grity

3

• Route s a nd re la ys

2

• Ma na ge s communica tion be twe e n a dja ce nt node s

1

• Tra ns mits bit s tre a m ove r phys ica l me dium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -217

The Presentation Layer, layer 6, converts bits to objects. Characters are objects, so a code set is Presentation Layer. Voices are objects so bits to voices and voices to bits in a CDEC is Presentation Layer too. Pictures to bits in MPEG is also Presentation Layer. Have you ever seen Star-Trek where there is a very clever Presentation Layer in Captain Kirk’s Transporter which converts bits to people and people back into bits.

Notes:

Silicon-IPTV-Broadcast -217

OSI Model • ISO 7498 and ITU-T X.200

Application and its Services Converts bits to Objects

Application Presentation

Checkpoints and Activities

Session

End to End Error Recovery

Transport

Routing

Network

Detects Errors

Data Link

Moves Bits

Physical

7

• P rovide s a pplica tion s e rvice s

6

• P rovide s da ta re pre s e nta tion

5

• P rovide s che ckpointing, a ctivity ma na ge me nt

4

• P rovide s e nd-to-e nd da ta inte grity

3

• Route s a nd re la ys

2

• Ma na ge s communica tion be twe e n a dja ce nt node s

1

• Tra ns mits bit s tre a m ove r phys ica l me dium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -218

Finally layer 7 is where the application and all the other functions run. Indeed you the user are in layer 7 too.

Notes:

Silicon-IPTV-Broadcast -218

Internet Protocol Suite Structure OSI Model 7. Application

Internet Model

6. Presentation

Application

Application

Transport

Transport

3. Network

Internet

Internet

2. Data Link

Network interface

Network interface

1. Physical

Hardware

Hardware

5. Session 4. Transport

TCP/IP

• IP does not care what the lower layers are: LAN or WAN — WAN can be frame relay, ATM, Point-to-Point Protocol (PPP) OSI = Open Systems Interconnection © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -219

We need to point out here that the top three layers of the OSI model are the application running in the PCs. A similar application is running less visibly in the routers to achieve the connection and operation.

Notes:

Silicon-IPTV-Broadcast -219

Internet Protocol Suite Delivery of Multimedia Services TCP/IP Architecture

Network Links

IP

TCP and UDP

Applications

Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -220

Notes:

Silicon-IPTV-Broadcast -220

Network Interconnection

Host

LAN A LAN B • Internetworking issues: — Addressing — Routing, path through the network — Packet size and format — Access technology — Shared protocols – Errors, flow, timing

Host

• These issues are resolved by an internetworking protocol (Layer 3) © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -221

In reality Internetworking involves the interconnection of LANs using WANs formed from routers.

Notes:

Silicon-IPTV-Broadcast -221

Data Link and Physical Layer in the LAN

Application

Application

Transport

Transport

Internet

Internet

Network interface

LAN or WAN link

Hardware

TCP/IP

Network interface Hardware

• IP can run over any kind of LAN

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -222

The LANs and the physical links that join routers together form the lowest two layers of the OSI model and of the Internet model.

Notes:

Silicon-IPTV-Broadcast -222

Data and Computer Networks • LANs permit computers to interconnect locally — Standardized by IEEE 802 committee – Includes wired and wireless versions — Use 48-bit addresses that are not routable — Address Resolution Protocol maps LAN addresses to IP addresses • Limited in physical dimensions

• LANs limited to one site can be interconnected — Effectiveness of interconnection depends upon data rate of access

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -223

We need to explain why LAN addresses are not easy to use for voice addressing as they are not routable. The first 3 bytes in the addresses are a code that identifies the manufacturer of the interface, but although we know who made the device we have no idea where it is. This makes 802 addresses fine for devices phyically on the name LAN, that is on the same site, but not much use on their own when we have many potential sites. IP addresses start with a Network address which is location fixed and so we can use this to get to the right network and finally the device host address to reach the final end point.

Notes:

Silicon-IPTV-Broadcast -223

Data and Computer Networks • LAN protocols do not guarantee timing — They are asynchronous — Most Wide Area connections are synchronous – Timing is provided by network • Typically routers interconnect LANs

Public network

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -224

LAN protocols are aysnchronous. Each frame is sent as and when needed. Each end of the conversation over a LAN knows approximately the speed at which data will be received and by using the first few bits it is able to align its incoming clock more exactly with that of the transmitter before decoding the data. Ethernet uses 64 bit times to achieve this. As there is no universal guarantee of time on LANs, special actions must be taken to carry voice over these structures as voice is VERY sensitive to changes in timing.

Notes:

Silicon-IPTV-Broadcast -224

xDSL • Digital Subscriber Loop technologies provide access over telephone loops — Often known as the last mile Type Bit rates Distance — HDSL (high-data-rate DSL) HDSL 1.5–2.0 Mbit/s, 4.5 km symmetric of 2- or 3-pair UTP — SDSL (single-line DSL) SDSL 1.5–2.0 Mbit/s, 3 km of — ADSL (asymmetric DSL) symmetric 1-pair UTP ADSL 1.5–9 Mbit/s down, – High bit rate downstream 2.5–5 km of 1-pair 16–640 kbit/s up UTP – Low upstream VDSL 13–52 Mbit/s down, 0.3–1.5 km of — VDSL (very high-data-rate DSL) 1.5–2.3 Mbit/s up 1-pair UTP

Public network

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -225

Digital subscriber loop technologies have evolved to allow high speed transmission over the copper subscriber loops installed originally to carry analog phone conversations. The loop generally pass from the subscriber premises to the local exchange. In more than 95% of cases this distance is less than 5 km. Generally speaking the higher the data rate used, the higher will be the bandwidth of frequencies required to carry the signals, and thus the higher will be the highest frequency. Generally speaking high frequencies suffer most loss and are affected most by noise. The more complex and expensive the electronics used, the higher will be the data rate achieved, but eventually the rate will be limited by the physics of the problem. Most loops are just a single pair of wires for sending data in both directions. It is not easy to use the same frequencies in both directions at the same time and so part of the bandwidth is normally allocated to each direction. Some xDSL technologies use different amounts of bandwidth in each direction and so are Asymmetric. Others may use two pairs of wires or use equal bandwidths and be symmetric.

Notes:

Silicon-IPTV-Broadcast -225

Internet Protocol Suite Delivery of Multimedia Services TCP/IP Architecture

Network Links

IP

TCP and UDP

Applications

Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -226

Notes:

Silicon-IPTV-Broadcast -226

Internet Protocol (IP) • Basic concepts: — IP used by hosts, routers, gateways — Does not need to know how to get to the final destination (endpoint) – Just to the next network (host, next hop) — Does not need to know about all of the networks on the route – Just the locally connected networks • IP packet contains destination address and data — That’s all that’s needed to reach destination • Best-effort delivery — No guarantees

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -227

The job of a router is to forward a packet to the next “best hop” en route to its destination.

Notes:

Silicon-IPTV-Broadcast -227

Internet Protocol Suite HTTP

SMTP

POP

FTP

Etc.

SNMP

TCP

RIP

Etc.

Transport

UDP IP

ICMP

Application

Internet

ARP

Data link

Network interface

Physical

Hardware

• Internet protocol suite — Includes applications – More than 100 now defined — Operates at Layer 3 and higher

RIP = Routing Information Protocol SNMP = Simple Network Management Protocol © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -228

This diagram shows some protocols run over TCP and some over UDP. Our signaling is going to run over TCP and our voices over UDP.

Notes:

Silicon-IPTV-Broadcast -228

Encapsulation E-mail Me

E-mail You

TCP E-mail

TCP E-mail

IP TCP E-mail

IP TCP E-mail

Ethernet IP TCP E-mail

Ethernet IP TCP E-mail

• Layer 4 interface is with processes on the host — For example, SMTP or POP • Layer 3 interface is with other hosts via address — For example, IP address • Layer 2 depends on the type of physical network used — For example, frame relay, ATM, ISDN, Ethernet — May include additional addressing (SVC, PVC, etc.) PVC = permanent virtual circuit SVC = switched virtual circuit © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -229

Notice that IP is not used alone. Each layer of the protocol stack passes its data within the protocol data units of the layer below. This is known as encapsulation. As data passes down the stack, the units of transfer grow. At the receiving end the transfers are unwrapped.

Notes:

Silicon-IPTV-Broadcast -229

IPv4 Datagram 4 bytes

0

Ver

IHL

TOS

Length M D 0 F F

Datagram ID TTL

31

Prot

Fragoff Checksum 20 bytes

Source address Destination address Options Data

TOS = type of service TTL = time to live © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -230

To see exactly how IP functions it is possible to capture traffic that is running over a LAN or serial PC interface. Using Ethereal which can be downloaded from www.ethereal.com and installed on almost any PC it is possible to view the fields within the IP header.

Notes:

Silicon-IPTV-Broadcast -230

IPv4 Datagram (continued) • Datagram fields important to VoIP — Type of service (TOS) – Used in VoIP QoS – First 3 bits give precedence — Datagram ID provides a unique number for the packet with the TTL — TTL: time to live in seconds (hops) – Routers reduce by 1 or number of seconds held — Flag field – MF: Indicates last fragment (MF=0 is last fragment) – DF: Permission to fragment—Don’t Fragment (DF bit) — Fragoff: Fragment offset – Measured in units of 8 octets — Prot: Next protocol – 6=TCP, 17=UDP • Total overhead is at least 20 bytes for the IP packet header

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -231

The header of IP version 4 packets is generally 20 bytes long. The version number and the Internet Header Length (IHL) confirm the version of IP and the header size measured in 32 bit words. The Type of Service (TOS) field is not often used to carry data but can be used to identify the kind of data being carried. Recently this field has been renamed the differentiated services code point and can be used in VoIP systems to identify voice packets. Routers can use this field to give priority to voice packets over data. The length field identifies the total size of the datagram including the header. As it is 16 bits long packets are limited to 64kbytes in length. Th fields in the next 32 bit word are used for fragmentation indicated the datagram number, a unique field value that is present in every fragment of a datagram. The Time To Live (TTL) is used to prevent packets going into loops within the Internet and is reduced by 1 in each router.

Notes:

Silicon-IPTV-Broadcast -231

Where The Internet Protocol Runs

Router LAN Router

Wireless Network

Router Point-To-Point Network Router Router

Switched Network © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -232

IP is the most widely used protocol in the world and represents in excess of 85% of the market. Indeed it is increasing in use with both voice and video distribution now available over IP. IP was developed originally by the US DOD from the ARPAnet project. ARPAnet was an experimental packet network developed between 1963 and 1969 to be used to launch nuclear missiles. It was deployed between 1969 and 1972 when the defense networks were split into the special networks for secret military use and the non-classified parts which were titled the Internet. Between 1972 and 1976 the Internet Protocol Suite was extended and IP improved over several versions until version 4 (known as IPv4) was reached which we now use. Development has continued to improve capabilities and address space with Version 6 being completed in 1996. However the migration from version 4 to version 6 will be very long and painful — so painful that some have doubted it will ever happen.

Notes:

Silicon-IPTV-Broadcast -232

Where The Internet Protocol Runs • The internet protocol runs in every host and every router — Host: a device that communicate over the internetwork — Router: a device that joins one or more networks onto the internetwork • Does not run in devices that form the networks themselves — Not in devices below OSI layer 3 – e. g. – Not in Ethernet switches – Not in Bridges – Not in Modems – Not in Network Termination Units – Not in any device that is Layer 2 or layer 1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -233

IPv4 runs in every router and every computer that needs to connect over the Internet within the layer 3 of its protocol stack. Hubs, bridges, switches, modems and other layer 1 or layer 2 devices are invisible to IP. It is an Internetworking protocol which means that it can be used not just within a network but between networks. Indeed it was intended that it should be possible to interconnect machines attached to any kind of network with IP. This has proved to be the case.

Notes:

Silicon-IPTV-Broadcast -233

Functions of Internet Protocols • IP is not the only internetworking protocol— others include — Novell IPX — ISO CLNP • All internetworking protocols provide — Physical network independence for higher-layer processing — Logical address for computers on network — Independence from maximum transmission unit (MTU) size — Fragmentation and reassembly control — Datagram service

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -234

IP is not the only internetworking protocol. Novell developed IPX from work originally started by Xerox on the Xerox Network System (XNS) and used it for PC networks. This too is an internetworking protocol but has few advantages over IP. Indeed Novell now offer products based on IP also. The ITU-T and ISO together also developed the Connection-Less Network Protocol (CLNP) also known as ISOIP which is used in OSI systems and the signaling systems for SDH and telephone services. These are however slowly but surely migrating to IP.

Notes:

Silicon-IPTV-Broadcast -234

Physical Medium Independence • Each network technology may have its own characteristics — Different hardware — Different API for access — Different timing dependency • IP provides a standard logical interface for exchange of data packets Single Common Network Interface IP

Network Type 1

Network Type 2

Different Network Interfaces

Network Type 3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -235

All internetworking protocols that join network technologies together must provide independence from the layer 1 and 2 used. The physical cables and channels used on different physical technologies bring with them limitations. IP removes these limitations. In practice this is achieved by configuring low level driver software that supports the physical technology below and interfaces to one of a range of driver interfaces to IP. NDIS (Network Driver Interface Specification) and ODI (Open Driver Interface) are two popular ones for PCs.

Notes:

Silicon-IPTV-Broadcast -235

Logical Addressing • Each network technology has its own addressing system • We require interoperation between any group of devices • IP introduces a single unique logical addressing scheme — Each device is given a logical address in addition to its physical network address — All IP addresses form part of the same single address space ATM 20 byte NSAP

48-bit Ethernet

IP address mapping

32-bit IP address

Internetwork address

14-decimal-digit X.25 E.164 15 digit

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -236

Different network technologies use different address lengths. X.25 a 14 digit address, the phone service E.164 a 15 digit address, Ethernet a 48 bit address and so on. All are different addresses and even different sizes. Devices on these networks will retain their original addresses but will be allocated another logical address by IP.

Notes:

Silicon-IPTV-Broadcast -236

Independence of MTU size • Each technology has a different maximum transmission unit size — The optimum MTU is determined by the error performance — The more reliable the physical transmission the optimum MTU — High error rates require small packets – More chance of error so less data can be sent before error occurs • Some actual MTUs for technologies widely used MTU (bytes)

Max frame size

Ethernet

Network

1,500

1,518

IEEE 802.5 (4 Mbit/s)

4,440

4,500

IEEE 802.5 (16 Mbit/s)

17,940

18,000

FDDI

4,352

4,500

X.25

4096

4102

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -237

Different networking technologies have different maximum frame and packet sizes. IP can support packets up to 64 kbytes in length and will fragment packets as necessary to fit within the network maximum sizes. There are limits however. The smallest IP header is 20 bytes long and each segment other than the last must contain a multiple of 8 bytes. There is a recommendation that networks should support at least 576 byte packets as a minimum. In practice most do, although radio networks may need limitations smaller than this.

Notes:

Silicon-IPTV-Broadcast -237

Fragmentation and Reassembly • It is the task of the router to match the MTU sizes between networks • Packets too large for delivery over the output network are fragmented • Destination host reassembles — Packets may be fragmented several times between source and destination

Source

Destination

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -238

Routers are responsible for fragmentation and will fragment datagrams down to sizes small enough to pass through output networks. The destination of the data must then reassemble the original datagram from the fragments. Reassembly can be a difficult and time consuming process so is best avoided if possible.

Notes:

Silicon-IPTV-Broadcast -238

Internetwork Datagram Service • IP always offers a datagram service — Best Efforts but no guarantee

Source

Destination

Virtual Circuit

Datagram

Virtual Circuit

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -239

IP is a datagram service. This means that while it will try to deliver data as quickly as possible there is no guarantee. Indeed in the event of congestion or other network limitations, routers will discard datagrams without warning. End systems must therefore use retransmission timers in the Transport layer (layer 4) to overcome datagrams lost.

Notes:

Silicon-IPTV-Broadcast -239

Internet Protocol Suite Delivery of Multimedia Services TCP/IP Architecture

Network Links

IP

TCP and UDP

Applications

Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -240

Notes:

Silicon-IPTV-Broadcast -240

Transmission Control Protocol (TCP) • Provides “reliable,” in-sequence stream transport — Useful for transfer of large volumes of data such as file transfer — Connection oriented—virtual circuit — When connection is established, data transfer starts – Protocols verify correct reception – Buffered traffic flow – Full-duplex connection • Accounts for more than 90 percent of Internet traffic • “Reliability” is achieved through retransmission — When packets are lost or errors occur, retransmission provides “reliability” – Suitable for data traffic and signaling for voice: Ensures correct information – Not suitable for voice traffic: Voice information must be continuous – By the time data is retransmitted, it is too late!

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -241

TCP is used to overcome the short coming of IP. IP provides delivery of data without any guarantees. Data may be corrupted, lost, duplicated or even (in theory) delivered to the wrong address. TCP provides sequence numbers and timers that allow data to be delivered once and only once, in order and with a high level of guarantee. In order to achieve this data is held in buffers by the sender until an acknowledgement is received and may be resent repeatedly after a time-out if no acknowledgment is received. This requires significant amounts of processing capacity, memory and takes time. TCP may be used in VoIP to carry the signaling used to dial and connect calls, but adds too much delay to carry the voice itself.

Notes:

Silicon-IPTV-Broadcast -241

TCP Segment Header 0

4

10

16

Source port

24

31

Destination port Sequence number

Acknowledgment number HLEN

Reserved

Code bits

Checksum

Window Urgent pointer

Options (if any)

Padding Data

Options (normally absent)

• Port is a destination for the message • Local host process can communicate with the port • A pair of IP addresses and port numbers for a connection forms a socket — Complete specification for an association—a conversation • Adds at least 20 bytes overhead per packet

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -242

Units of transfer for TCP are called Segments. Conversations are identified between source and destination using both addresses in the IP header together with both port numbers in the TCP header. This is known as a Full Association. Sequence numbers and acknowledgement numbers are used to ensure that all transfers are received in order and acknowledged. If a segment is lost then a timer in the sender will expire and cause the segment to be resent. This takes additional processing and delay but ensures all data is received. Because the additional retransmission and processing takes time it causes delay. It is therefore not practical to use TCP to carry voice in most cases.

Notes:

Silicon-IPTV-Broadcast -242

User Datagram Protocol (UDP) • Used for unreliable delivery— i.e., not acknowledged — Application must handle errors – Loss of packet, duplication, delay – Out-of-sequence, loss of physical connectivity — These functions add processing overhead in applications but… — Reduce processing in the transport layer – Much less than TCP • Accounts for less than 5 percent of Internet traffic currently • Used for transaction processing; selected for voice transport

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -243

When the overhead and delay of TCP is not required or cannot be tolerated UDP is used. This identifies the full association but does not guarantee delivery. We generally prefer to have lower delay rather than retransmission of lost data. Data is generally lost when the network is overloaded and so by careful sizing we can avoid overload.

Notes:

Silicon-IPTV-Broadcast -243

UDP Header • Source and destination are ports • Length is total length of packet • Checksum is for the header and data — Checksum is optional — All zeros if not used 0

15

31

Source port

Destination port

Length

Checksum User data …

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -244

The port numbers and IP addresses together identify the conversation. The checksum can be used to verify that no data has been lost or corrupted in the segment but in practice the layer 2 protocol will have already confirmed accurate transfer.

Notes:

Silicon-IPTV-Broadcast -244

Internet Protocol Suite Delivery of Multimedia Services TCP/IP Architecture

Network Links

IP

TCP and UDP

Applications

Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -245

Notes:

Silicon-IPTV-Broadcast -245

Applications Use Ports • Hosts are multitasking computers running multiple applications — Communication takes place between the applications running on the hosts — Linkage is not direct; use software code called a port – Allows operating system to direct packets to correct application • Server ports are normally well-known ports—less than 1024 — HTTP 80 SMTP 25 — FTP 21, 20 DNS 53 — Telnet 23 NNTP 119 • Ports used by VoIP are generally client ports—greater than 1024 — End-to-end VoIP call setup uses destination port 1720 – UDP ports dynamically assigned and both ends > 1024

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -246

Different conversations are identified by using the IP addresses and port numbers of both ends of a conversation. The change in any one of these four values, or in the layer 4 protocol (TCP or UDP) represents a different conversation. Client server operations are carried using low numbers less than 1024 in the port number of the server. As VoIP does not normally run between client and server, but runs client to client, low port numbers are not used. However well known values are used to carry signaling for H.323 (1720 to connect calls) and for SIP (5060).

Notes:

Silicon-IPTV-Broadcast -246

Datagram Delivery

TCP application

UDP application

Defined by port number

TCP

UDP Defined by “Protocol / Next” field

IP • Ports assigned — Fixed – “Well-known ports” assigned at and below 1024 — Dynamic – Assigned by applications: above 1024 up to 65536 (216) • RFC 1700 (assigned numbers)—defined “well-known ports” in 1992 — Updated list available from http://www.iana.net © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -247

I was going to put a copy of all the registered port numbers in an appendix but when I looked the list was enormously long now. You can find this on the Internet at http://www.iana.org/assignments/port-numbers. Signaling ports are registered numbers but not less than 1024 so not well known in the correct sense. VoIP conversations are normally NOT client server in the traditional sense but peer to peer so both ends are "client" ports greater than 1024.

Notes:

Silicon-IPTV-Broadcast -247

Real-Time Transport Protocol (RTP) • TCP/IP protocol suite includes protocols for real-time applications — Real-Time Transport Protocol (RTP) — Real-Time Control Protocol (RTCP) • RTP provides — Timestamping, sequence number – For playback timing and synchronization — Setting up real-time applications – Audio and video • RTCP provides — Reporting on achieved results — Delay, packet loss statistics • Defined in RFC 1889 originally — Copied by H.323 systems

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -248

TCP delivers too much delay to carry voice but we do need to ensure that datagrams of voice are played by the receiver in the order that the sender recorded them and in the correct timing. RTP is used to achieve this.

Notes:

Silicon-IPTV-Broadcast -248

Real-Time Applications on Packet Networks • To be intelligible, our speech must be played out with the same timing relationship between words as the original — Received packets may not all arrive with exactly the same delay – This is called jitter • Real-time Transport Protocol marks the voice samples with a timestamp — That timestamp is used to play out the packet in sequence – With the correct relative time relationship

You’re

right

This

is

an

IP

telephony

course

Sent

Received

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -249

Individual packets are produced by the sender when there is sound to send. When there is silence no packets are sent. In each packet a sequence number and timer indicate to the receiver the order in which packets must be decoded and played as well at the time at which playing should start. When the receiver has no packets to play at a particular time the receiver plays “silence”. In reality there is never any real silence on a voice call so the sender must define the sound level below which no data will be sent. To account for this some CODEC definitions include “comfort noise”, a low level sound which is used instead of true silence when there are no packets to play. This proves to be less disturbing to listeners in real life than pure silence.

Notes:

Silicon-IPTV-Broadcast -249

RTP • Real-time Transport Protocol—Adds minimum of 12 bytes — V: Version—RFC 1889 currently 2 — P: Padding— =1 if packet contains padding — X: Extension bit—if 1, then there is an extension header — CC: CSRC count—the number of CSRC identifiers following — M: Marker—profile may use this bit to define frame boundaries — PT: Payload type—defines the type of encoding • Sequence number increments by 1 for each RTP data packet V=2 P X

CC

M

PT

Sequence number Timestamp

Synchronization source (SSRC) identifier

Contributing source (CSRC) identifiers

CSRC = contributing source reference code © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -250

Notes:

Silicon-IPTV-Broadcast -250

Payload Types • RTP does not define payload types — Defined by the application or an RTP profile • For VoIP, the payload types are defined by the multimedia conferencing standards (H.323 and H.225) — Most widely used types: – Payload type Codec – 0 PCM µ-Law – 8 PCM A-Law – 9 G.722 audio codec – 4 G.723 audio codec – 15 G.728 audio codec – 18 G.729 audio codec – 34 H.263 video codec – 31 H.261 video codec — These codecs are examined in more detail later

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -251

H.323 defines that voice should be carried according to H.225 standards which are identical in format to RTP. The document does not define all the codecs given in the RTP RFC but just a subset.

Notes:

Silicon-IPTV-Broadcast -251

Payload Types Defined in RFC 1890 PT 0 1 2 3 5 6 7 8 9 10 11 14 15 25 26 28 31 32 33 34--71 72--76 77--95 96--127

encoding name

audio/video (A/V)

PCMU 1016 G721 GSM DVI4 DVI4 LPC PCMA G722 L16 L16 MPA G728 CelB JPEG nv H261 MPV MP2T unassigned reserved unassigned dynamic

A A A A A A A A A A A A A V V V V V AV ? N/A ? ?

clock rate (Hz)

channels (audio)

8000 8000 8000 8000 8000 16000 8000 8000 8000 44100 44100 90000 8000 90000 90000 90000 90000 90000 90000

1 1 1 1 1 1 1 1 1 2 1 1

N/A

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -252

This is the list of codecs from the RFC rather than H.323, and shows that quality much higher than that over normal phone systems is possible. The list has grown since the RFC and the latest list can be found at:http://www.iana.org/assignments/rtp-parameters For example types 10 and 11 indicate CD quality sound (music) in either mono or stereo. Also video codecs are defined too.MP4 is in a dynamic range, which means that there is not a defined number for mpeg4. See RFC 3016. ISMA uses a different RFC for audio transmission (or a RFC draft, actually).

Notes:

Silicon-IPTV-Broadcast -252

Real-Time Transport Control Protocol (RTCP) • Real-Time Transport Control Protocol is used with RTP — Provides – Monitoring and feedback of real-time parameters related to quality – Packets lost, cumulative packets lost – Interarrival jitter calculated as new = old + (delta-old)/16 – Calculated as each packet arrives (regardless of sequence) – Transport Level ID for the source of the RTP packets – Optional session control – Minimal capabilities – – Start session, bye • RTCP provides an option for encryption to ensure privacy • There is no provision in the standard for any action that may be taken if the results are unacceptable — RTCP is only a reporting mechanism

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -253

RTCP packets are so rare in our network that they are hard to find. You may only get one in a minute of what has been captured in a voice call. The highest rate is one every 5 seconds but without RTCP packets it is not possible to report to source upon loss and jitter changes. Probably it would not be possible to adjust the jitter buffering in a receiver more often than RTCP reports. Changes within the network loading that cause different end to end delays to be observed can cause packet loss until the next RTCP exchange. The infrequent exchanges in the classroom mean that configuration changes that cause big differences in delay will result in losses in the speech.

Notes:

Silicon-IPTV-Broadcast -253

RTCP • RTCP has four functions — Primary function of RTCP is to provide feedback on quality — Carries the canonical name (CNAME) of the source – This may or may not be displayed to the participants — Controls the rate at which the first two types are sent — Carries session control information

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -254

Most VoIP devices do not carry the identity in the CNAME but NetMeeting does.

Notes:

Silicon-IPTV-Broadcast -254

Example Multimedia Web Applications • Internet Radio • Internet TV : see http://wwitv.com • Streaming over the Internet

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -255

Notes:

Silicon-IPTV-Broadcast -255

Internet Protocol Suite Delivery of Multimedia Services TCP/IP Architecture

Network Links

IP

TCP and UDP

Applications

Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -256

Notes:

Silicon-IPTV-Broadcast -256

Chapter Summary Now you have completed this chapter you can • Describe the key protocols used for voice over IP • Discuss addressing and routing in IP networks • Explore the operation of applications within IP networks • Characterize the behavior of TCP/IP networks • Compare some alternative WAN technologies

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -257

Notes:

Silicon-IPTV-Broadcast -257

Chapter 4

Layer 2 Addressing

Notes:

Silicon-IPTV-Broadcast -258

Chapter Objectives When you have completed this chapter you will be able to • Describe how addressing works at layer 2 • Examine IEEE 802 addressing • Identify how LANs are interconnected at layer 2 • Examine Link level aggregation

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -259

Notes:

Silicon-IPTV-Broadcast -259

Layer 2 Addressing IEEE 802 Addressing

Bridging and Switching

Spanning Tree

Aggregation

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -260

Notes:

Silicon-IPTV-Broadcast -260

IEEE 802 Standards

802.1 overall standards

• Institute of Electrical and Electronic Engineers produces LAN standards — Available from http://standards.ieee.org/getieee802/

Type 1 Type 2

802.2 Logical Link Control

802.3 Ethernet

802.4 Token Bus

802.5 Token Ring

10BASE5

1 Mbps

4 Mbps

10BASE2

5 Mbps

16 Mbps

10BASE-T

10 Mbps

802.6 MAN

•••

Others

DQDB 155 Mbps

100BASE-T 1 Gbps LANs

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -261

Notes:

Silicon-IPTV-Broadcast -261

General Aspects of LANs • Several common frame format aspects — Destination and source address fields – 48-bit addresses — Variable-length “payload” data size – Maximum size differs – 32-bit error-check fields (6 byte s) Destination address 0 = IEEE Admin 1 = Local admin 0 = Individual 1 = Group

. . .

Assigned to the vendor (3 bytes)

Payload data

CRC

Assigned by the vendor (3 bytes)

Address is sent low order bits first in each byte E.g., Locally admin, group address Ethernet Hex Address

1100 0000 0

- - -

3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -262

Addressing on all 802 standard network technologies is similar. Each deploys a 48 byte address comprising a 3 byte field identifying the Vendor and a 3 byte field making each address unique. The Vendor code was originally call a Manufacturer code and has recently changed its name again to an Organizational Unit Identifier. Bytes are transmitted lowest bit in each byte first. The first two bits transmitted are reserved and used to identify the addressing scheme used and group addresses deployed when using multicasting.

Notes:

Silicon-IPTV-Broadcast -262

Speed, Size and Distance Limitations • If we remove the CSMA/CD then the speed and distance can increase • Distance will be limited by the media and layer one characteristics • By buffering in the hub collisions can be removed — The device changes from a hub or repeater to a switch or bridge • However by interconnecting switches very large layer 2 networks result • Also Ethernet is not routable — The address does not indicate where a station sits — Switches must flood broadcasts and unknown destination addresses — Switches must also build up tables of source addresses on each interface

Preamble (7 bytes)

Start delimiter

1010...1010 10101011

Min 64 Max 1,518 bytes

(6 bytes)

Frame check sequence (4 bytes)

(6 bytes) (2 bytes)

Destination Source address address

Type or length

“Data”

Pad

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

FCS

Silicon-IPTV-Broadcast -263

If we buffer packets in hubs and repeaters then we can preserve the packets while other send. By giving each device a separate interface that is buffered in both directions a switch is created and by filtering packets to remove those that a device does not need to see the speed and distance limitations can be removed. Also much faster and more secure networks result.

Notes:

Silicon-IPTV-Broadcast -263

802.3 Variations • The IEEE 802.3 variations are often expressed in the form 10BASE5 10 Mbps

Abbreviation T

–

500 M before Baseband needing a repeater

Or, the letter “T” after “BASE” standing for “twisted pair” the Media Type

Meaning Half duplex twisted pair, cat 3 or cat 5 (at 10 Mbit/s) 100m

TX

Full Duplex Twisted Pair- two pairs of cat 5 100m

FX

Fiber optic pair up to 400 m

SX

Short wavelength fiber (770-860nm) typically MMF 50 or 62.5/125

LX

Long wavelength fiber (1270-1355nm) typically SMF 10/125

LH

Long Haul fiber (1310 or 1550nm) SMF 9/125

CX

Shielded twisted pair 25 m or less © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -264

Notations now identify the speed, the kind of encoding (baseband or broadband) and the media used.

Notes:

Silicon-IPTV-Broadcast -264

Layer 2 Addressing IEEE 802 Addressing

Bridging and Switching

Spanning Tree

Aggregation

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -265

Notes:

Silicon-IPTV-Broadcast -265

Dividing Heavily Loaded Segments • Total LAN traffic on a segment may be high

Heavy traffic!

• Bridges allow heavy traffic to be isolated

Lighter traffic!

• Improves overall performance but adds delay between segments

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -266

However powerful a network becomes there will be limits on its capacity. By dividing this into two parts where most of the traffic stays local to each half and on communication between devices on the two halves needs to pass between, greater overall copacity is created. The interconnecting device is called a bridge and a group of many bridges in a single box is called a switch.

Notes:

Silicon-IPTV-Broadcast -266

Transparent Spanning Tree (TST) • This is the 802.1d standard approach • Bridges build a tree structure so there are no active loops — Does not scale well to large sizes • They find the root bridge(or switch) with lowest priority interface — Then minimize the distance from the root bridge — When two paths are found the longest path is turned off • Bridges forward all frame for deliver until they “learn” otherwise

Host Host

Host Host

Host Host

Stand-by bridge

Host Host

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -267

When multiple segments are connected by bridges each device listens to the source addresses of packets on each side and if it identifies in a packet that both source and destination are on the same side it does not copy the data. However if the destination address in a packet is unknown or a broadcast address (FF:FF:FF:FF:FF:FF) it is copied. A problem will arise however if bridges are used to connect traffic in a loop. IEEE 802.1D 1998 Transparent Spanning Tree overcomes this by building a tree structure and turning off interfaces that would form loops. In 2004 this was upgraded to speed up the process and re-titled Rapid Spanning Tree.

Notes:

Silicon-IPTV-Broadcast -267

Multiple Simultaneous Paths • Using multiple simultaneous paths means that backplane bandwidth is no longer shared • May be non-blocking  every station can transmit at the same time — Can also be full-duplex • Each interface becomes a collision domain with full bandwidth Switch

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -268

Each interface to a switch is normally full duplex and by ensuring that the backbone path is greater than the sum of the interface speeds it is possible to build full duplex non-blocking switches.

Notes:

Silicon-IPTV-Broadcast -268

802.1D Concepts • Unique identification of a bridge — A unique 48-bit Universally Administered MAC Address, termed the Bridge Address is assigned to each Bridge — The Bridge Address may be the individual MAC Address of a Bridge Port typically the lowest numbered Bridge Port (Port 1)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -269

To work each bridge bust be assigned a unique identification. This is formed either by configuration or using the address of one of it ports, typically the lowest.

Notes:

Silicon-IPTV-Broadcast -269

Functions Within a Bridge • The switches/bridges maintain a filtering database • Built dynamically on source addresses viewed

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -270

The bridge will need to be able to identify when a port is up and when it is down. When it is up and active the bridge will dynamically build a database of address for each VLAN passing over the port.

Notes:

Silicon-IPTV-Broadcast -270

Layer 2 Addressing IEEE 802 Addressing

Bridging and Switching

Spanning Tree

Aggregation

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -271

Notes:

Silicon-IPTV-Broadcast -271

The Rapid Spanning Tree Protocol • Consider this example: First devices forward Bridge Protocol Data Units

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -272

In this example the devices have been assigned identifications based upon their lowest port address. When a topology change is identified they output on every port a multicast packet giving details of their identity and listen for similar packet from their neighbors. Identifications are compared and when a device receives a better (lower) identification it stops sending its own and forwards that received updating the Root Path Cost. The Root Path Cost is the cost of the path from the root bridge, in reality if all interfaces are the same speed it is a hop count.

Notes:

Silicon-IPTV-Broadcast -272

Bridge Protocol Data Units

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -273

The Protocol Identifier is 0000 0000 0000 0000. The Protocol Version Identifier is 0000 0010. The BPDU Type is 0000 0010. This denotes a Rapid Spanning Tree The Topology Change flag is encoded in Bit 1 of Octet 5 The Proposal flag is encoded in Bit 2 of Octet 5 The Port Role is encoded in Bits 3 and 4 of Octet 5 The Learning flag is encoded in Bit 5 of Octet 5 The Forwarding flag is encoded in Bit 6 of Octet 5 The Agreement flag is encoded in Bit 7 of Octet 5 The Topology Change Acknowledgment flag is encoded in Bit 8 of Octet 5 as zero The Root Identifier is encoded in Octets 6 through 13 The Root Path Cost is encoded in Octets 14 through 17 The Bridge Identifier is encoded in Octets 18 through 25 The Port Identifier is encoded in Octets 26 and 27 The Message Age timer value is encoded in Octets 28 and 29 The Max Age timer value is encoded in Octets 30 and 31 The Hello Time timer value is encoded in Octets 32 and 33 The Forward Delay timer value is encoded in Octets 34 and 35 The Version 1 Length value encoded in Octet 36 is 0000 0000, which indicates that there is no Version 1 protocol information present.

Notes:

Silicon-IPTV-Broadcast -273

Bridge Protocol Data Units • Th BPDU Type can be either a topology change or a RTST • The Root Identifier is encoded in Octets 6 through 13 — This is made up from the address of the root and its priority • The Root Path Cost is encoded in Octets 14 through 17 • The Bridge Identifier is encoded in Octets 18 through 25 • The Port Identifier is encoded in Octets 26 and 27

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -274

Notes:

Silicon-IPTV-Broadcast -274

RST Parameter Values • RSTP Timer and Transmit Hold Count parameter values Parameter Migrate Time Bridge Hello Time Bridge Max Age Bridge Forward Delay Transmit Hold Count

Recommended or Default value 3.0 2.0 20.0 15.0 6

Permitted Range — — 6.0–40.0 4.0–30.0 1–10

Compatibility Range — 1.0–2.0 6.0–40.0 4.0–30.0 1–10

• Bridge and Port Identifier Priority values Parameter Bridge Priority Port Priority

Recommended or default value 32 768 128

Range 0–61 440 in steps of 4096 0–240 in steps of 16

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -275

Notes:

Silicon-IPTV-Broadcast -275

Port Path Cost values

Link Speed

Recommended value

Recommended range

Range

<=100 Kb/s 1 Mb/s 10 Mb/s 100 Mb/s 1 Gb/s 10 Gb/s 100 Gb/s 1 Tb/s 10 Tb/s

200 000 000 20 000 000 2 000 000 200 000 20 000 2 000 200 20 2

20 000 000–200 000 000 2 000 000–200 000 000 200 000–20 000 000 20 000–2 000 000 2 000–200 000 200–20 000 20–2 000 2–200 1–20

1–200 000 000 1–200 000 000 1–200 000 000 1–200 000 000 1–200 000 000 1–200 000 000 1–200 000 000 1–200 000 000 1–200 000 000

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -276

Notes:

Silicon-IPTV-Broadcast -276

Rapid Spanning Tree • Bridges broadcast their identity out of each interface — Typically the identity is the Ethernet address of port 1 with a priority value — Best Root is highest priority with lowest address • If they continue until a better Root identity is received — They stop sending their identity — They update the received record to reflect the new Root Path Cost — Flood this instead • The port with the lowest Root Path Cost becomes the root port • Each LAN in the Bridged Local Area Network has an associated Root Path Cost — This is the Root Path Cost of the lowest cost Bridge with a Bridge Port connected to that LAN

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -277

Notes:

Silicon-IPTV-Broadcast -277

The Rapid Spanning Tree Protocol

Identity Root Path Cost Discarding Interface

Path to root

Forwarding Interface

Forwarding Edge Interface © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -278

Here 111 has become the root. Bridges that receive more than one copy of the information from the root compare the root path cost values and select the one with the lowest value as the interface to use to reach the root. Other interfaces over which copies of the root identity were received with higher costs are “turned off” by discarding packets received. Packets are then forwarded to/from the root port from/to all other ports.

Notes:

Silicon-IPTV-Broadcast -278

Effective Topology • The effective topology is thus reduced

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -279

In effect the network becomes a tree.

Notes:

Silicon-IPTV-Broadcast -279

Typical Ring Backbone Topology • In a typical ring backbone one port becomes non-forwarding

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -280

A typical topology selected for reliable operation is a ring. This results in a tree being built while all interfaces function. When one fails a topology change results and a new tree is built continuing service with the failed interface becoming the edge of the tree.

Notes:

Silicon-IPTV-Broadcast -280

Layer 2 Addressing IEEE 802 Addressing

Bridging and Switching

Spanning Tree

Aggregation

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -281

Notes:

Silicon-IPTV-Broadcast -281

IEEE 802.3 Link Aggregation • When connecting 802.3 switches together 802.1d forms a spanning tree • This means that there is only a single active link carrying traffic between any two switches • As load increases this does not scale well as congestion can occur • Adding additional links will not help if these are turned off by 802.1d! • The solution to this is Link Aggregation

• Aggregation can be useful to provide: — Improved reliability without spanning tree reconfiguration — Increased throughput beyond the capacity of a single link © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -282

In this aggregated network we have 5 1 Gbit/s interconnections between two switches. Without aggregation 802.1d would turn off 4 of the 5 links delivering only 1 Gbiit/s capacity. If one link or indeed even if 4 links failed the service would continue but 802.1d might take a small number of seconds to switch cables. With aggregation data is shared between the links and so we can achieve up to say 5 times 1 Gbit/s as well as maitaining service without interruption over individual link failures.

Notes:

Silicon-IPTV-Broadcast -282

Link Aggregation • Formerly was IEEE 802.3ad now migrated to 802.3-2002 section 43 • Multiple links between two switches can share balanced load • Aggregation entity has its own single MAC address for group of links Aggregate MAC Address

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -283

Link Aggregation comprises an optional sublayer between a MAC Client and the MAC (or optional MACControl sublayer). Figure above depicts the positioning of the Link Aggregation sublayer in the CSMA/CDlayer architecture, and the relationship of that architecture to the Data Link and Physical Layers of the OSI Reference Model. The figure also shows the ability of the Link Aggregation sublayer to combine a numberof individual links in order to present a single MAC interface to the MAC Client. It is possible to implement the optional Link Aggregation sublayer for some ports within a System while not implementing it for other ports; i.e., it is not necessary for all ports in a System to be subject to Link Aggregation. A conformant implementation is not required to be able to apply the Link Aggregation sublayer to every port.

Notes:

Silicon-IPTV-Broadcast -283

Link Aggregation Control PDU (LACPDU) 01-80-C2-00-00-02 Type:88-09 0x01

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -284

LACPDUs are basic IEEE 802.3® frames; they arenot tagged. The LACPDU structure above has the following field definitions: a) Destination Address (DA). The DA in LACPDUs is the Slow_Protocols_Multicast address. Its use and encoding are specified in Annex 43B. b) Source Address (SA). The SA in LACPDUs carries the individual MAC address associated with the port through which the LACPDU is transmitted. c) Length/Type. LACPDUs are always Type encoded, and carry the Slow_Protocols_Type field value. The use and encoding of this type is specified in Annex 43B. d) Subtype. The Subtype .eld identi.es the specific Slow Protocol being encapsulated. LACPDUs carry the Subtype value 0x01. e) Version Number. This identities the LACP version; implementations conformant to this version of the standard carry the value 0x01. f) TLV_type = Actor Information. This field indicates the nature of the information carried in this TLVtuple. Actor information is identified by the value 0x01. g) Actor_Information_Length. This .eld indicates the length (in octets) of this TLV-tuple, Actor information uses a length value of 20 (0x14). h) Actor_System_Priority. The priority assigned to this System (by management or administration policy), encoded as an unsigned integer. i) Actor_System. The Actor’s System ID, encoded as a MAC address. j) Actor_Key. The operational Key value assigned to the port by the Actor, encoded as an unsigned integer. k) Actor_Port_Priority. The priority assigned to this port by the Actor (the System sending the PDU; assigned by management or administration policy), encoded as an unsigned integer. l) Actor_Port. The port number assigned to the port by the Actor (the System sending the PDU), encoded as an unsigned integer. m) Actor_State. The Actor’s state variables for the port, encoded as individual bits within a single octet.

Notes:

Silicon-IPTV-Broadcast -284

Link Aggregation Control PDU (LACPDU)

Priority and System identifier together identify the entity Port Priority and Port together identify the port prefered in an aggregated group All ports with same key are in the same group

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -285

1) LACP_Activity is encoded in bit 0. This .ag indicates the Activity control value with regard to this link. Active LACP is encoded as a 1; Passive LACP is encoded as a 0. 2) LACP_Timeout is encoded in bit 1. This .ag indicates the Timeout control value with regard to this link. Short Timeout is encoded as a 1; Long Timeout is encoded as a 0. 3) Aggregation is encoded in bit 2. If TRUE (encoded as a 1), this .ag indicates that the System considers this link to be Aggregatable; i.e., a potential candidate for aggregation. If FALSE (encoded as a 0), the link is considered to be Individual; i.e., this link can be operated only as an individual link. 4) Synchronization is encoded in bit 3. If TRUE (encoded as a 1), the System considers this link to be IN_SYNC; i.e., it has been allocated to the correct Link Aggregation Group, the group has been associated with a compatible Aggregator, and the identity of the Link Aggregation Group is consistent with the System ID and operational Key information transmitted. If FALSE (encoded as a 0), then this link is currently OUT_OF_SYNC; i.e., it is not in the right Aggregation. 5) Collecting is encoded in bit 4. TRUE (encoded as a 1) means collection of incoming frames on this link is de.nitely enabled; i.e., collection is currently enabled and is not expected to be disabled in the absence of administrative changes or changes in received protocol information. Its value is otherwise FALSE (encoded as a 0); 6) Distributing is encoded in bit 5. FALSE (encoded as a 0) means distribution of outgoing frames on this link is de.nitely disabled; i.e., istribution is currently disabled and is not expected to be enabled in the absence of administrative changes or changes in received protocol information. Its value is otherwise TRUE (encoded as a 1); 7) Defaulted is encoded in bit 6. If TRUE (encoded as a 1), this .ag indicates that the Actor’s Receive machine is using Defaulted operational Partner information, administratively con.gured for the Partner. If FALSE (encoded as a 0), the operational Partner information in use has been received in a LACPDU; 8) Expired is encoded in bit 7. If TRUE (encoded as a 1), this .ag indicates that the Actor’s Receive machine is in the EXPIRED state; if ALSE (encoded as a 0), this .ag indicates that the Actor’s Receive machine is not in the EXPIRED state.

Notes:

Silicon-IPTV-Broadcast -285

Link Aggregation Control PDU (LACPDU)

Partner at the other end of the link can be identified if required

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -286

n) Reserved. These 3 octets are reserved for use in future extensions to the protocol. They shall be ignored on receipt and shall be transmitted as zeroes to claim compliance with Version 1 of this protocol. o) TLV_type = Partner Information. This .eld indicates the nature of the information carried in this TLV-tuple. Partner information is identi.ed by the integer value 0x02. p) Partner_Information_Length. This .eld indicates the length (in octets) of this TLV-tuple, Partner information uses a length value of 20 (0x14). q) Partner_System_Priority. The priority assigned to the Partner System (by management or administration policy), encoded as an unsigned integer. r) Partner_System. The Partner’s System ID, encoded as a MAC address. s) Partner_Key. The operational Key value assigned to the port associated with this link by the Partner, encoded as an unsigned integer. t) Partner_Port_Priority. The priority assigned to this port by the Partner (by management or administration policy), encoded as an unsigned integer. u) Partner_Port. The port number associated with this link assigned to the port by the Partner, encoded as an unsigned integer. v) Partner_State. The Actor’s view of the Partner’s state variables, depicted in Figure 43–8 and encoded as individual bits within a single octet, as de.ned for Actor_State. w) Reserved. These 3 octets are reserved for use in future extensions to the protocol. They shall be ignored on receipt and shall be transmitted as zeroes to claim compliance with Version 1 of this protocol. x) TLV_type = Collector Information. This .eld indicates the nature of the information carried in this TLV-tuple. Collector information is identi.ed by the integer value 0x03. CSMA/CD IEEE Std 802.3-2002®, Section Three y) Collector_Information_Length. This .eld indicates the length (in octets) of this TLV-tuple. Collector information uses a length value of 16 (0x10). z) CollectorMaxDelay. This .eld contains the value of CollectorMaxDelay (43.2.3.1.1) of the station transmitting the LACPDU, encoded as an unsigned integer number of tens of microseconds. The range of values for this parameter is 0 to 65 535 tens of microseconds (0.65535 seconds).

Notes:

Silicon-IPTV-Broadcast -286

Link and Aggregator System Identifiers • Example

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -287

In order to allow for convenient transcription and interpretation by human network personnel, this standard provides a convention for representing compound LAG IDs. Using this format a) All fields are written as hexadecimal numbers, 2 digits per octet, in canonical format. b) Octets are presented in order, from left to right. Within .elds carrying numerical signiifcance (e.g., priority values), the most significant octet is presented first, and the least signi.cant octet last. c) Within .elds that carry MAC addresses, successive octets are separated by dashes (-), in accordance with the hexadecimal representation for MAC addresses defined in IEEE Std 8021990. d) Parameters of the LAG ID are separated by commas.

Notes:

Silicon-IPTV-Broadcast -287

Aggregator Grouping • Links with the same key are candidates for membership of a link aggigator group • In configuration it is possible to specify individual ports or any in a group — Any can be specified by using zero in the port number • The number of active links from a group can be configured — Ports are then activated in sequence of their priority and port number — Low numbers win • As groups are formed by specifying both ends, if links are miss connected they appear as different groups — There are 4 groups here

A

1 1 1 2 2 2 2

4 4 4 5B 5 5 5 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -288

By labelling each element in the group at both ends and passing this information between the adjacent switches it is possible for the switches to detect and confirm the correct cable attachment for each element in each group. Where a cable is incorrectly connected by mistake, the switches at each end can detect this and either inform the management system, report errors on the switch console control interface or intelligently reconfigure the operation of the switches algorithmically.

Notes:

Silicon-IPTV-Broadcast -288

Layer 2 Addressing IEEE 802 Addressing

Bridging and Switching

Spanning Tree

Aggregation

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -289

Notes:

Silicon-IPTV-Broadcast -289

Chapter Summary Now you have completed this chapter you can • Describe how addressing works at layer 2 • Examine IEEE 802 addressing • Identify how LANs are interconnected at layer 2 • Examine Link level aggregation

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -290

Notes:

Silicon-IPTV-Broadcast -290

Chapter 5

Layer 3 Addressing

Notes:

Silicon-IPTV-Broadcast -291

Chapter Objectives In this chapter, we will • Review how addressing works at layer 2 and layer 3 • Examine addressing and routing in IP networks • Explore the operation of MAC addresses • Resolve addresses between layer 2 and layer3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -292

Notes:

Silicon-IPTV-Broadcast -292

Layer 3 Addressing Routable Addresses

Address Classes (Historic)

Issuing Addresses and Resolving them

Subnetworking

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -293

Notes:

Silicon-IPTV-Broadcast -293

Routable Address Structure • To deliver a packet, a router must know where to deliver it • IP addresses are divided into two fields — Network—where to deliver the packet (usually a LAN) — Host—which machine at that location • The division of IP addresses is undertaken by a network mask

192 . 168 . 1

.10 Host

Network

255.255.255

Mask

.0

• Mask (netmask or subnet mask) contains binary 1s in the network portion — Used to indicate the division of network and host

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -294

With 2^32 possible destinations it might be necessary somewhere within the Internet to hold a table of possible addresses that was 2^32 rows long. This would be too large to be practical. To make this problem more manageable, addresses are grouped together into networks where every device on the same network has the same value in the first part of their addresses. This is known as the network address or the prefix. he length of the prefix can vary from one part of the Internet to another and so we need to define how long this is within the routing table of any device. This is done be using either binary mask with binary 1s set in the network portion and zeros following this. Another method used is to indicate the length of the network portion in bits. In this example I could say:address 192.168.1.10 with mask 255.255.255.0 or I could say 192.168.1.10/24 Notice that 255.255.255.0 contains 3 bytes full of 1s making a total of 24 bits.

Notes:

Silicon-IPTV-Broadcast -294

Net Prefix Notation • Net prefix notation is a shorthand way of describing address and mask • 192.168.1.10/24 is equivalent to — Address = 192.168.1.10 — Mask = 255.255.255.0 • Value after the “/” gives the number of “1s” in the mask • Trailing zeros in the address can be removed — 122.15.0.0/16 can be written as 122.15/16 — 0.0.0.0/0 can be written as 0/0

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -295

Net prefix notation is the name given to the method of expressing addresses and masks in the compact form such as 192.168.1.10/24.

Notes:

Silicon-IPTV-Broadcast -295

Networks and Subnetworks

192.168.0.1

192.168.0.2

192.168.0.10 Mask = 255.255.255.0

192.168.4.2

192.168.0.254

LAN A 192.168.4.1

192.168.1.254

LAN B

• Networks are identified by addresses — Each network must have unique ID — Each host must have unique ID and same prefix 192.168.1.1 192.168.1.2 192.168.1.10 Mask = 255.255.255.0

• Networks and subnetworks are joined by routers

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -296

Within any one organization a specific range of addresses will be used. This range will be allocated to the organization either directly by the Internet administrative authorities, or via their Internet Service Provider. Inside the organization however it might still be necessary to further sub-divide the network address in order to refer to different LANs within a building. This is known as sub-networking.

Notes:

Silicon-IPTV-Broadcast -296

Addressing for IP • IP phones need several pieces of information to work — An IP address — The mask for its network/subnetwork — The address of a router on its subnetwork – Often called a Default Gateway • IP addresses must be unique to connect to the Internet — Need a numbering plan — Address assignment can be – Static—by administrator – Dynamic; e.g., Dynamic Host Configuration Protocol (DHCP)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -297

For any device to be able to route data to other parts of the Internet clearly it must have an IP address. However it also needs to know other things too. It must know its network mask so that it can distinguish between local devices on the same LAN (the same sub-network), and the address of the interface on a router attached to its LAN so that it can send data to other networks. It may also need other information such as details of the server which can map names to IP addresses for Email and Web access. These values can be set manually although this can be time consuming and error prone. More usually the details are sent to the device when it is first turned on using DHCP. When the device starts up it sends out a single broadcast frame that every device on the LAN will examine. One device, the DHCP server, will respond to this and forward the required information including the IP address it should use.

Notes:

Silicon-IPTV-Broadcast -297

Layer 3 Addressing Routable Addresses

Address Classes (Historic)

Issuing Addresses and Resolving them

Subnetworking

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -298

Notes:

Silicon-IPTV-Broadcast -298

Interconnecting to the Internet • Choice between public and private (RFC 1918) IP address — If the device has a private address it cannot connect directly to the Internet – Network Address Translation (NAT) can translate addresses – Allows a limited set of addresses to be shared by a larger community – May improve immunity to attack from hackers • Address structure — Historically, the division of addresses was fixed in structure – Classes A, B, and C — Today we use classless addressing, which allows flexible division • Today we use classless addressing—before, we used address classes

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -299

There are now millions of devices attached to the Internet and it is through by some people that soon we will run out of IP addresses. Organizations may find that they are limited in the number of addresses they can use. In 1992 the Internet community recognized that this will become a problem. Many organizations had requested addresses in case they wished in the future to use Internet services but had never connected. RFC 1918 allocated 3 ranges of addresses that will never be used on the Internet so that private networks could use these addresses without using up address capacity. Also firewalls are normally deployed to protect organizations from attack by hackers. These devices can further protect their organizations by hiding the real addresses behind the firewall. Devices are allocated a private address from RFC 1918 and the firewall converts this to a valid address dynamically. This is called Network Address Translation. It is then possible for several devices to share the same address.

Notes:

Silicon-IPTV-Broadcast -299

Addresses Classes (Historic) H

A

N 0xxxxxxxx 1–126

N

H

H

B

N 10xxxxxxx 128–191

N

N

H

C

N 110xxxxxx 192–223

• Special addresses — Local host: 127.0.0.1 — Broadcast: – Local 255.255.255.255 – Directed; e.g., 192.168.1.255

H

H

• Private networks (RFC 1918) — 10.X.X.X Class A — 172.16-30.X.X Class B — 192.168.0-255.X Class C

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -300

Before 1992 the length of the network portion of addresses was fixed at one of 3 sizes. This was changed in 1992 when classless addressing was introduced and masks became variable in length.

Notes:

Silicon-IPTV-Broadcast -300

Internet Protocol (IP) • Role of IP is to communicate between hosts — Routable protocol – Define both network and host address – Other routable protocols – Novell IPX, Banyan VINES, AppleTalk, OSI IP • Unreliable, best-effort, connectionless delivery — Delivery of packet is not guaranteed — Reliability is the responsibility of the application • Reliability is the responsibility of the upper-layer protocols — May be TCP — May be the application

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -301

IP evolved over the 1960s and early 1970s until 1976 when the current version, version 4, was produced. It is a routable datagram protocol that delivers data without any guarantees.

Notes:

Silicon-IPTV-Broadcast -301

Addressing Routable Addresses

Address Classes (Historic)

Issuing Addresses and Resolving them

Subnetworking

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -302

Notes:

Silicon-IPTV-Broadcast -302

Mapping IP Addresses to Link Addresses • Imagine two machines connected to the same link, a LAN perhaps • Machine A wishes to send an IP datagram to machine B • It can construct the datagram but must place this inside the link protocol • How can it find out machine B’s link address? • Address Resolution Protocol (ARP) provides the answer Machine A IP Address: 192.168.10.1

Machine B IP Address: 192.168.10.2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -303

Notes:

Silicon-IPTV-Broadcast -303

Address Resolution Protocol • RFC 826 ARP provides a means of mapping IP addresses to link addresses • Machine A broadcasts an ARP request to all the machines on the link — ARP request includes the IP address of the required machine B • All machines on the link compare the requested IP address with their own — Only machine B finds a match and responds

Machine A IP Address: 192.168.10.1

Machine B IP Address: 192.168.10.2 Broadcast ARP Request

Broadcast Source A

Dest A

806

ARP Request

Source B

806

ARP Reply

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -304

Notes:

Silicon-IPTV-Broadcast -304

ARP Cache • Once a matching IP to physical link address mappings can be stored — Generally stored for a few minutes in a RAM arp cache — Long enough to avoid repeated arp requests — Not so long that if the link address or IP address changes it still remains – Link address might change because of • Contents of your ARP cache can be displayed using the arp command C:\WINDOWS>arp -a Interface: 213.122.23.149 on Interface 0x1000002 Internet Address Physical Address Type 62.248.16.48 20-53-52-43-00-00 dynamic Interface: 192.168.7.2 on Interface 0x2000003 Internet Address Physical Address 192.168.7.1 00-a0-cc-7b-18-66 192.168.7.11 00-20-18-71-f0-ea 192.168.7.32 00-40-05-d0-85-6d 192.168.7.191 00-03-47-0c-ae-40

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Type dynamic dynamic dynamic dynamic

Silicon-IPTV-Broadcast -305

Notes:

Silicon-IPTV-Broadcast -305

Configuring IP Addresses • A device can obtain its IP address in one of a number of ways — By manual configuration – A very reliable human configures it for storage on its backing store – This can make changing IP addresses very difficult – Error prone - if the human makes mistakes! — By using BOOTP - RFC 951 and 1084 – Fixed IP address for all time – Provides details of router and other information required — By using DHCP IP UDP BOOTP request

BOOTP server

Dest IP address = 255.255.255.255 Source IP address = 0.0.0.0

IP UDP BOOTP reply

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -306

Notes:

Silicon-IPTV-Broadcast -306

Dynamic Host Configuration Protocol (DHCP) • DHCP extends BOOTP to add a lease time • Used in most Microsoft environments • A request to the server yields an offer of an address with a lease time — The lease time limits the time the IP address is used — Can be renewed if server agrees — Allows more machines to exist than IP addresses – Only active devices need addresses • Very widely used to allocate addresses within windows networks

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -307

Notes:

Silicon-IPTV-Broadcast -307

Can find details with IPCONFIG

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -308

Notes:

Silicon-IPTV-Broadcast -308

Layer 3 Addressing Routable Addresses

Address Classes (Historic)

Issuing Addresses and Resolving them

Subnetworking

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -309

Notes:

Silicon-IPTV-Broadcast -309

Dividing Networks - Subnetworks • May be administratively convenient or even necessary to divide networks — Insufficient network addresses for each LAN to have a network — Routing between small groups of workstations on LANs — Easier administration 139.21.1.3 139.21.1.2 139.21.1.1 Rest of the Internet All Traffic to 139.21.0.0

139.21.2.1

139.21.2.2 139.21.2.3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -310

Notes:

Silicon-IPTV-Broadcast -310

Subnetting Classful Addresses • Before classless addressing network Classes A, B and C were allocated — Needed to divide these so we called the result a subnetwork — Mask used to define the division between subnetwork and host – Called a subnet mask – Today called a Netmask IP Address Network

Subnet

Host

1s in mask

0s in mask

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -311

Notes:

Silicon-IPTV-Broadcast -311

Division of Network • The division between network (or subnetwork) and host at bit location — Number of host addresses is always a power of 2 — Zero host address identifies the subnet - not used for host — All 1s host address used for broadcast - not used for host — Result is that number of usable host addresses is 2 less than power of 2 • Valid masks — 255.255.255.252 — 255.255.255.248 — 255.255.255.240 — 255.255.255.224 — 255.255.255.192 — 255.255.255.128 — 255.255.255.0 — 255.255.254.0 — 255.255.252.0 — 255.255.248.0

/30 /29 /28 /27 /26 /25 /24 /23 /22 /21

2 valid hosts 6 valid hosts 14 valid hosts 30 valid hosts 62 valid hosts 126 valid hosts 254 valid hosts 510 valid hosts 1022 valid hosts 2046 valid hosts and so on

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -312

Notes:

Silicon-IPTV-Broadcast -312

How Many Subnets Are Needed? • Routers route between networks or subnetworks • Each interface needs to be on a different network or subnetwork • How many subnetworks do I need here?

LAN A

LAN C

LAN B

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -313

Notes:

Silicon-IPTV-Broadcast -313

Point to Point Links • Point to point links count as subnetworks — Routers route between subnets so point to point links must be a subnets — Point to point links have only two addresses – One for each end – Ideal mask is 255.255.255.252 as just 2 valid addresses – Some router vendors allow unnumbered links – No need for IP address but difficult to test link remotely — Most popular routing protocol - RIP - requires all masks are the same – Point to point links use up many addresses

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -314

Notes:

Silicon-IPTV-Broadcast -314

Balancing Subnet and Host Needs • Every Host that is connected to a subnet needs a unique IP address • Every point to point link, LAN and other network needs a subnet address • Zero Subnet and all 1s subnet are more difficult to use — Zero subnet address and the network address are the same – Example – 139.21.0.0/16 is a network address (class B) – 139.21.0.0/24 is a subnet address but its address is the same – Some routers do not allow the use of zero subnet 139.21.2.0

139.21.1.0

Rest of the Internet All Traffic to 139.21.0.0

?

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -315

Notes:

Silicon-IPTV-Broadcast -315

SMIS Inc Network • SMIS Inc has 6 sites each with a router and a LAN

1

4

2

3

5

6

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -316

Notes:

Silicon-IPTV-Broadcast -316

SMIS Inc Network • Each site has the following numbers of computers currently — 1 225 — 2 250 — 3 100 — 4 250 — 5 210 — 6 216 • We have been allocated network address 139.21.0.0/16 • You have been appointed to advise on address allocations • Answer the following questions — How many subnets do we need — What subnet masks should be used on each subnet — How should the network addresses be defined for each router interface — How should the addresses be assigned to each host

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -317

Notes:

Silicon-IPTV-Broadcast -317

Layer 3 Addressing Routable Addresses

Address Classes (Historic)

Issuing Addresses and Resolving them

Subnetworking

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -318

Notes:

Silicon-IPTV-Broadcast -318

Chapter Objectives • In this chapter we have • Reviewed how addressing works at layer 2 and layer 3 • Examined addressing and routing in IP networks • Explored the operation of MAC addresses • Resolved addresses between layer 2 and layer3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -319

Notes:

Silicon-IPTV-Broadcast -319

Chapter 6

Routing

Notes:

Silicon-IPTV-Broadcast -320

Chapter Objectives • In this chapter we will • Study the operation of distributed dynamic routing • Review the major routing protocols • Examine how distance vector link state and policy based routing functions

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -321

Notes:

Silicon-IPTV-Broadcast -321

Routing Distributed Dynamic Routing Principles

RIP

OSPF

BGP4

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -322

Notes:

Silicon-IPTV-Broadcast -322

Dynamic Routing Principles C

• Consider this network • Each site has one LAN

D

B

C

A

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -323

IP uses distributed dynamic routing. Each router must maintain its own tables of routing information and make decisions about where to send data. We will take this simple example of 4 routers each connected to a local LAN to illustrate how routing can function.

Notes:

Silicon-IPTV-Broadcast -323

Dynamic Routing Principles • Routers build tables — Networks they see

D C 1 D 0

A 1 B 0 C 1

A 1 B

C

B 1 C 0 D 1

A 0 A

B 1 C 1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -324

Each router first constructs a table of destinations networks it knows. In our example we will use hops to indicate the metric used. Zero means no hops to the destination - it is local. One hop means that we must pass the data to one more router for delivery. Initially routers will only know the existence of routers to which they directly attach. Notice that router A at the bottom is connected directly to B and C but not directly to D.

Notes:

Silicon-IPTV-Broadcast -324

Dynamic Routing Principles • Exchange tables with — Immediate neighbors

D

A

C 1

B

1

C 1 0 D 0 1 A C A 1 0 1 B 0 1 1 C 1 1 0 D

A B D A 1 0 1 B

C

B 1 1 0 C 0 1 1 1

1

D 1

0

B C A 0 1 1 A

B 1 0 1 C 1 1 0 D

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

1 Silicon-IPTV-Broadcast -325

So that indirect connection can be used each router sends a copy of its own routing information to each of its direct neighbors. Notice now that A has information for both B and C. From the information received from router C it can discover the existence of router D.

Notes:

Silicon-IPTV-Broadcast -325

Dynamic Routing Principles C A 2 1

• Update Tables D

B 2 1 C 1 0 D 0 1

A C A 1 0 1 B 0 1 1 C 1 1 0

A B D A 1 0 1 2 B

C

B 1 1 0 2 C 0 1 1 1

D 2 2 1

D 1 2 2 0

B C A 0 1 1 A

B 1 0 1 C 1 1 0 D 2 2 1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -326

When all of the information is exchanged A will discover two possible routes to D. One via B amd one via C. The route via B is 2 hops while that via C only one so it will prefer that via C and will add one to this to construct its own metric of 2.

Notes:

Silicon-IPTV-Broadcast -326

Dynamic Routing Principles • Failed link — Remove information — Update links

C A 2 1

D

B 2 1 C 1 0 D 0 1

A C A 1 0 1 B 0 1 1 C 1 1 0

A B D A 1 0 1 2 B

C

B 1 1 0 2 C 0 1 1 1

D 2 2 1

D 1 2 2 0

B C A 0 1 1 A

B 1 0 1 C 1 1 0 D 2 2 1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -327

However if the link from A to C fails the information A has received from C is no longer useful and is removed. However a route still exists via B.

Notes:

Silicon-IPTV-Broadcast -327

Dynamic Routing Principles • Updated Information — Routes around failure

C A 3 2

D

B 2 1 C 1 0 D 0 1

A C A 1 0 1 B 0 1 1 C 1 2 0

B

C

D 2 3 1

A 2

B D 1 3

B 1

0 2

C 0

1 1

D 1

2 0

B A 0 1 A

B 1 0 C 2 1 D 3 2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -328

The route via B will then be taken as the preferred route for A to use to reach D and data is sent via B.

Notes:

Silicon-IPTV-Broadcast -328

Dynamic Routing Principles • Further Failure — Parts of Network Isolated — Further information

C A 3 2

D

B 2 1 C 1 0 D 0 1

A C A 1 0 1 B 0 1 1 C 1 2 0

B

C

D 2 3 1

A 2

B D 1 3

B 1

0 2

C 0

1 1

D 1

2 0

B A 0 1 A

B 1 0 C 2 1 D 3 2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -329

If however the B to C link also fails then clearly there will be not possible route to D from A. However the router will not immediately notice this.

Notes:

Silicon-IPTV-Broadcast -329

Dynamic Routing Principles C A 3 4

• Tables Updated D

B 2 3 C 1 0 D 0 1

A A 1 0 B 0 1 C 3 2

B

C

D 4 3

A 4

D 3

B 3

2

C 0

1

D 1

0

B A 0 1 A

B 1 0 C 4 3 D 5 4

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -330

A will continue to receive routes from B and B continue to send them back to A. As time passes the count of hops from A to D will grow from 2 to 3 and then from 3 to 4 until the hop count grows large.

Notes:

Silicon-IPTV-Broadcast -330

Dynamic Routing Principles • Tables Updated again — Hop counts too large — Only 4 hops in network — Nodes unreachable

C A 5 4

D

B 4 3 C 1 0 D 0 1

A A 1 0 B 0 1 C 5 4

B

C

D 6 5

A 6

D 5

B 5

4

C 0

1

D 1

0

B A 0 1 A

B 1 0 C 6 5 D 7 6

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -331

When the hop count reaches a value larger that the maximum possible count, in our example there are only 4 links so a hop count could never exceed 4, the routers will notice that the routes are unreachable. Unreachable routes can then be deleted.

Notes:

Silicon-IPTV-Broadcast -331

Dynamic Routing Principles • Tables reduced — Two distinct networks

D

C C 1 0 D 0 1

A A 1 0 B 0 1

B

D

C

C 0 1 D 1 0

B A 0 1 A

B 1 0

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -332

Notice now the inter- network has divided into two distinct parts.

Notes:

Silicon-IPTV-Broadcast -332

Routing Distributed Dynamic Routing Principles

RIP

OSPF

BGP4

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -333

Notes:

Silicon-IPTV-Broadcast -333

Distance Vector Routing • This is known as distance vector routing - routing by rumor • First used Routing Information Protocol (RIP) — Uses metric of Hops — Simple to implement but treats all links as equivalent — Updates routes every 30 seconds — Maximum hop count is 15 - 16 means unreachable – Maximum of 16 hops from destination — Ages routes not refreshed after 6 updates — All networks have the same mask – Does not support Variable Length Subnet Masks (VLSM) — Takes long time to update distant routes – Maximum time is 16 x 30 seconds = 8 minutes — Takes time to count to infinity (16 hops) • RIP version 2 overcomes many of the problems — Not widely supported yet and other options are better © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -334

The example we have taken is small but shows how RIP works. RIP was the first routing protocol ever used on the Internet but is now only used for small private networks of 50 subnets ot less.

Notes:

Silicon-IPTV-Broadcast -334

Routing Distributed Dynamic Routing Principles

RIP

OSPF

BGP4

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -335

Notes:

Silicon-IPTV-Broadcast -335

Link State Routing • Link state routing is routing using a network map • Routers pass information about state of links to neighbors • Neighbors flood the network so every router gets information • Each router builds a map of the whole network • Changes in link states are sent immediately and flooded — Fast update of like state changes - typically in seconds — Only updates sent so much less load after initial update • Most widely used link state routing algorithm is OSPF

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -336

Most large private networks would run very inefficiently if they used RIP. As the inter-network grows the routing tables grow too. With 1000 subnets the tables would be at least 1000 rows long and must be exchanged every 30 seconds. Instead Link State routing is normally used. This exchanges routes only when their status changes. If there are no changes then there is no traffic.

Notes:

Silicon-IPTV-Broadcast -336

Open Shortest Path First (OSPF) • Every router has a complete topological map of the network — Routers correspond to nodes in a graph – Networks are arcs or links between nodes • –

Routers are neighbors if they share the same link

R1 Net 1

R2

Net 2

R4

Net 5

Net 3

Net 4

R1

Net 5

Net 1 R2

R3

Net 2

Net 4

R4 Net 3 R3

Topological Map

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -337

OSPF is the most widely used routing protocol for medium and large organizations. Most ISPs use this internally.

Notes:

Silicon-IPTV-Broadcast -337

OSPF Routing Updates • Routers periodically send (multicast) status of each one of their links — Link status messages are used to update topological map database – Every router sees the same link-status message – Each calculates shortest path first to all networks — Route path cost can be a function of what ever manager requires – Hops, bandwidth, delay, protocol priority, usage cost, etc.

R1

Net 2

R4 My links to Net 2 and Net 3 are up!

Net 5 Net 1

Net 3

CRASH

R2

Net 4

My links to Net 3 and Net 4 are up! Sorry, my link to Net 5 is down.

R3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -338

It first exchanges details so that every router knows not just what its neighbors can do but gets a copy of details from every router. This takes some time, in practice a few seconds. However this data is sent only at startup. After the initial exchanges, only updates are sent and these are initiated only when the status of a link changes.

Notes:

Silicon-IPTV-Broadcast -338

What OSPF Can Deliver • Type of service routing — Possible to have different routing table for each TOS • Load balancing — Traffic can be divided between routes of equal metric • Flexible route path cost — Route path cost can be based on what ever is required • Unnumbered networks — Point to point links can be configured with taking and IP address • Multicast IP — Overhead reduced by using multicast addresses • Fast Convergence — New routes found within seconds after failures • Hierarchical routing possible using OSPF Areas © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -339

OSPF can deliver all of these functions in addition to normal routing of traffic.

Notes:

Silicon-IPTV-Broadcast -339

Routing Distributed Dynamic Routing Principles

RIP

OSPF

BGP4

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -340

Notes:

Silicon-IPTV-Broadcast -340

Routing Levels • Routing within the Internet can be broken down into 3 levels • First level of routing hierarchy: your PC talks to a router — Hosts make routing decisions for each IP packet they send out – Is destination directly connected? – Is destination in host’s routing table? – Is there a default router? — Host-specific routes are checked first • Second level of routing hierarchy: routers within an AS — Routers communicate within AS with generic Interior Gateway Protocols — Normally this is OSPF or in small networks RIP/EIGRP • Third level of routing hierarchy: AS to AS — Routers communicate between ASs with generic Exterior Gateway Protocols — In reality this is BGP4 today

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -341

Routing takes place at several levels. At the PC we route data to and from the interface of the PC and out to the nearest router. Once we reach the first ISP the ISP’s routers will follow routes that are advertised by other ISPs that it has a business arrangement with. For commercial reasons, routers within the internet will not follow necessarily the “shortest” route in all cases. In some cases economics may result in a longer and slower router being used.

Notes:

Silicon-IPTV-Broadcast -341

Example AS • Details of Autonomous System numbers is held at www.ripe.net • • • • • • • • • • • • • • • •

Example aut-num: as-name: descr: import: import: export: export: admin-c: tech-c: mnt-by: changed: changed: changed: changed: source:

AS12576 ORANGE-PCS Orange PCS Limited from AS702 action pref=100; accept ANY from AS2856 action pref=100; accept ANY to AS702 announce AS12576 to AS2856 announce AS12576 ORA1-RIPE ORA1-RIPE AS12576-MNT [email protected] 19990730 [email protected] 20020905 [email protected] 20020905 [email protected] 20040624 RIPE © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -342

This is an example of a registration from an Autonomous System. Within Europe RIPE acts as a non-profit organization to register addresses and AS identifications. ISPs attach to switches at general switching points known as Internet Exchanges. At these points they exchange routes, importing routes from other ISPs (AS) and exporting their own routes.

Notes:

Silicon-IPTV-Broadcast -342

Example AS • Details of Autonomous System numbers is held at www.ripe.net • • • • • • • • • •

Example aut-num: AS2856 as-name: BT-UK-AS descr: BTnet UK Regional network import: from AS286 action pref=11; accept AS-KQ export: to AS286 announce AS-BTGB import: from AS702 action pref=11; accept AS-UUNETEUUK export: to AS702 announce AS-BTGB import: from AS786 action pref=11; accept AS-JANETPLUS export: to AS786 announce AS-BTGB

• .

.

.

.

.

• import: from AS12576 action pref=10; accept AS12576 • export: to AS12576 announce AS-BTGB © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -343

Some ISPs specialize in interconnecting the Internet exchanges of the world forming the high bandwidth backbone connections. Other specialize in providing access services to users.

Notes:

Silicon-IPTV-Broadcast -343

Example AS • Details of Autonomous System numbers is held at www.ripe.net • Example • aut-num: AS702 as-name: AS702 • descr: MCI EMEA - Commercial IP service provider in Europe • import: from AS6 212.157.241.150 at 212.157.241.149 accept {129.185.30.0/22^22-24, 129.185.34.0/23^23-24} • import: from AS72 194.98.169.195 at 194.98.169.196 accept AS72 • import: from AS109 213.53.49.50 at 213.53.49.49 accept AS109 • .

.

.

.

.

• import: from AS12576 158.43.20.170 at 158.43.20.169 accept AS12576 • export: to AS12576 158.43.20.170 at 158.43.20.169 announce ANY

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -344

In Europe RIP controls the issuing of AS numbers and its datable records peering relationships.

Notes:

Silicon-IPTV-Broadcast -344

European Internet Exchanges • European exchanges http://www.dix.dk/euro/

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -345

This map shows the major exchanges around Europe. The European Internet Exchange Association provides information on the Internet exchanges in Europe although there is competition between them.

Notes:

Silicon-IPTV-Broadcast -345

European Exchanges • European Exchanges are members of European Internet Exchange Association — A few exchanges outside Europe are also associate members • There are now 38 members • See http://www.euro-ix.net/about/memberlist.shtml • Can you spot those in your country?

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -346

There are now 38 Internet Exchanges around Europe that are members of the European Internet Exchange Association.

Notes:

Silicon-IPTV-Broadcast -346

European Internet Exchange Association

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -347

Notes:

Silicon-IPTV-Broadcast -347

European Internet Exchange Association

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -348

Notes:

Silicon-IPTV-Broadcast -348

Peering Between Exchanges

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -349

Peering details can be found for exchanges at http://www.euro-ix.net/isp/choosing/search/ixpmatrix.php The largest exchange in terms of numbers of members is currently in Amsterdam. The Largest in terms of traffic is the London Internet Exchange LINX. There are also 3 other exchanges in the UK.

Notes:

Silicon-IPTV-Broadcast -349

Amsterdam Exchange Daily Statistics May 2006 • Exchange with the most members is in Amsterdam — Largest number of ISP peering in Europe — 2nd largest volume but growing fast

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -350

Amsterdam has the largest number of ISPs connected, though not the highest throughput in Europe. This diagram at http://www.ams-ix.net/technical/stats/ shows the traffic statistics in May 2006.

Notes:

Silicon-IPTV-Broadcast -350

LINX Performance: May 2006 • LINX in London has higher throughput and is largest in volume terms • LINX statistics https://www.linx.net

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -351

Detailed statisitics of Internet traffic through LINX can be found at https://www.linx.net/www_public/our_network/traffic_statistics_old/view?searchte rm=stats

Notes:

Silicon-IPTV-Broadcast -351

LINX Yearly 1 Day Average To May 2006

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -352

When LINX stated publishing Annual summaries of their statistics in the Year 2000 the traffic was doubling every six months and the daily total stood at below 3 Gbit/s. Today it is growing proportionately more slowly but has reached nearly 100 Gbit/s.

Notes:

Silicon-IPTV-Broadcast -352

LINX Growth Over 5 years • There has been a 10 fold increase over the last 4 years — Before this year on year growth was running at 300% • Can you predict the traffic for 2015? 2001

2002

2003

2004

2005

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

2006

Silicon-IPTV-Broadcast -353

Notice how the traffic continues to grow year on year. This is NOT the total traffic, it represents only the traffic between ISPs though London. Data starting and ending within the same ISP will not be included. Notice that traffic continues to increase year on year.

Notes:

Silicon-IPTV-Broadcast -353

Number of Computers on the Internet 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005

213 235 562 1,024 1,961 5,089 28,174 33,000 159,000 313,000 617,000 1,136,000 2,056,000 3,864,000 6,642,000 16,729,000 26,053,000 36.739,000 56,218,000 93,047,785 125,888,197 162,128,493 171,638,297 285,139,107 317,646,084

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -354

The number of computers attached to the Internet increases also. The key question that is now being asked is when will we run out of IP addresses?

Notes:

Silicon-IPTV-Broadcast -354

Growth in the Internet • The Internet has grown tremendously since 1990 — 32 bit address space was not allocated well initially • Demand for addresses was slowing because of firewall and proxy use — Rate has started to increase again — can you predict when we will run out of the 4,000,000,000 addresses?

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -355

Twice each year the ISC publishes a survey of the number of host addresses actually used in packets passing through the core of the Internet. This can be found at:http://www.isc.org/index.pl?/ops/ds/ While this is large and growing, we have still only used 315 out of the more than 4000 million addresses or about 8%. When you have spent 8% of your monthly pay, have you run out of money? If not, then at which point do you consider yourself out of cash - 90% say? So how long do you think it will take before we use another 3000 million addresses? In the past we have found more and more ways to reduce the demand for addresses and this can continue for some years yet.

Notes:

Silicon-IPTV-Broadcast -355

Routing Between ISPs • OSPF provides a good solution for large Autonomous Systems — Can cope with hundreds of networks and routers — Can be scaled using areas • Between ISPs it is not enough to just find the shortest route — Commercial decisions mean that shortest is not always best — ISP may gain revenue from its users — Does not want to carry transit traffic unless there is a commercial reason Transit ISPs

My ISP

Not this way Thankyou!

Your ISP

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -356

OSPF is no use however between commercial entities such as ISPs. ISPs are not interested in the shortest or best link if this cost them income. Business and political decisions need policy based routing.

Notes:

Silicon-IPTV-Broadcast -356

Border Gateway Protocol (BGP) • BGP enables a manager to decide the policy for carrying traffic — Current version is version 4 (BGP4) — Route from end to end is defined so that every ISP (AS) knows total route — If the route passes through an ISP which is not supported it can be rejected — ISPs can enter into commercial agreements to support traffic passage • Enables a manager to provide quality of service to supported customers • Routes may be summarized to reduce routing tables • Scalable to large number of Autonomous Systems

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -357

Border Gateway protocol version 4 is now required between ISPs. Most ISPs interconnect via Internet Exchanges which are layer 2 switches that join many routers together from different ISPs. These route according to policies that reflect their commercial interests. Broadly speaking the policy is “ you pay me and I will give you a route to carry the data”.

Notes:

Silicon-IPTV-Broadcast -357

Routing Survival Kit • What you need to know to make routing work:• Devices must have unique IP address • Prefix length (subnet mask) must be valid and consistent with address • Default router must be defined on the same subnet • Routing table must be valid: Use netstat -r to check — In a router show ip route • Must have route to destination: use tracert to check it exists — Check routing tables in devices where route is incorrect

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -358

Notes:

Silicon-IPTV-Broadcast -358

Trace Route

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -359

Notes:

Silicon-IPTV-Broadcast -359

Routing Table

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -360

Notes:

Silicon-IPTV-Broadcast -360

Pathping

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -361

Pathping provides a full tracerout to the destination and then undertakes a ping test progressively over the path. This enables details of packet loss to be determined so that particular error prone links or nodes may be identified. Most losses actually come from congestion causing queue buffers to overflow. There is no way to tell the actual cause of the packet los but it is possible at least to tie down the suspect links and routers.

Notes:

Silicon-IPTV-Broadcast -361

Routing Distributed Dynamic Routing Principles

RIP

OSPF

BGP4

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -362

Notes:

Silicon-IPTV-Broadcast -362

Chapter Summary • In this chapter we have • Studied the operation of distributed dynamic routing • Reviewed the major routing protocols • Examined how distance vector link state and policy based routing functions

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -363

Notes:

Silicon-IPTV-Broadcast -363

Chapter 7

Multicasting and Stream Delivery

Notes:

Silicon-IPTV-Broadcast -364

Chapter Objectives When you have completed this chapter you will be able to • Capture multicast streams • Identify different multicast address standards • Analyze IGMP and PIM • Differentiate between IGMP versions 1, 2 and 3 • Troubleshoot multicasting services

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -365

Notes:

Silicon-IPTV-Broadcast -365

Multicasting and Stream Delivery

Multicast Concepts Multicast Addressing IGMP PIM Sparse Mode Configuration Analysis of Multicast Exchanges Troubleshooting Multicast Problems Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -366

Notes:

Silicon-IPTV-Broadcast -366

Unicast vs Multicast

Unicast

Multicast

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -367

• Unicast transmission sends multiple copies of data, one copy for each receiver – Ex: host transmits 3 copies of data and network forwards each to 3 separatereceivers – Ex: host can only send to one receiver at a time • Multicast transmission sends a single copy of data to multiple receivers – Ex: host transmits 1 copy of data and network replicates at last possible hop for each receiver, each packet exists only one time on any given net work – Ex: host can send to multiple receivers simultaneously

Notes:

Silicon-IPTV-Broadcast -367

Multicast Advantages

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -368

As the number of viewers receiving the service increases, multicast delivery becomes dramatically more efficient. It is really not feasible to deliver broadcast television to a nation via Unicast, however via multicast it would be feasible to deliver dozens or perhaps a hundred channels that way.

Notes:

Silicon-IPTV-Broadcast -368

Multicast Disadvantages • Best Effort Delivery: Drops are to be expected — Multicast applications should not expect reliable delivery of data and should be designed accordingly — Reliable Multicast is still an area for much research • No Congestion Avoidance: Lack of TCP windowing and “slow-start” mechanisms can result in network congestion — Multicast applications should attempt to detect and avoid congestion conditions • Duplicates: Some multicast protocol mechanisms (e.g. Asserts, Registers and Shortest-Path Tree Transitions) result in the occasional generation of duplicate packets — Multicast applications should expect occasional duplicate packets • Out-of-Sequence Packets: Various network events can result in packets arriving out of sequence. — Multicast applications should be designed to handle packets that arrive in some other sequence than they were sent by the source © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -369

There are however disadvantages with multicast. By its very nature the traffic cannot be acknowledge so the service is less reliable.

Notes:

Silicon-IPTV-Broadcast -369

Multicasting and Stream Delivery

Multicast Concepts Multicast Addressing IGMP PIM Sparse Mode Configuration Analysis of Multicast Exchanges Troubleshooting Multicast Problems Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -370

Notes:

Silicon-IPTV-Broadcast -370

IP Multicast Service Model • RFC 1112 (Host Ext. for Multicast Support) • Each multicast group identified by a class-D IP address • Members of the group could be present anywhere in the Internet • Members join and leave the group and indicate this to the routers • Senders and receivers are distinct: — i.e., a sender need not be a member • Routers listen to all multicast addresses and use multicast routing protocols to manage groups

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -371

RFC 1112 is the Internet Group Management Protocol (IGMP) . It allows hosts to join a group that receives multicast packets. Users can dynamically register (join/leave multicast groups) based on the applications they execute It uses IP datagrams to transmit data Addressing Class D IP addresses (224-239) are dynamically allocated. Multicast IP addresses represent receiver groups, not individual receivers. Group Membership Receivers can be densely or sparsely distributed throughout the Internet. Receivers can dynamically join/leave a multicast session at any time using IGMP to manage group membership within the routers. Senders are not necessarily included in the multicast group they are sending to. Many applications have the characteristic of receivers also becoming senders eg RTCP streams from IP/TV clients

Notes:

Silicon-IPTV-Broadcast -371

Multicast Addresses

Multicast Address Range Assignments Description

Range

Reserved Link Local Addresses

224.0.0.0/24

Globally Scoped Addresses

224.0.1.0 to 238.255.255.255

Source Specific Multicast

232.0.0.0/8

GLOP Addresses

233.0.0.0/8

Limited Scope Addresses

239.0.0.0/8

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -372

The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast addresses. IANA has assigned the IPv4 Class D address space to be used for IP multicast. Therefore, all IP multicast group addresses fall in the range from 224.0.0.0 through 239.255.255.255. The Class D address range is used only for the group address or destination address of IP multicast traffic. The source address for multicast datagrams is always the unicast source address.

Notes:

Silicon-IPTV-Broadcast -372

Reserved Link Local Addresses

Address

Usage

224.0.0.1

All systems on this subnet

224.0.0.2

All routers on this subnet

224.0.0.5

OSPF routers

224.0.0.6

OSPF designated routers

224.0.0.12

Dynamic Host Configuration Protocol (DHCP) server/relay agent

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -373

The IANA has reserved addresses in the range 224.0.0.0/24 to be used by network protocols on a local network segment. Packets with these addresses should never be forwarded by a router. Packets with link local destination addresses are typically sent with a time-to-live (TTL) value of 1 and are not forwarded by a router. Network protocols use these addresses for automatic router discovery and to communicate important routing information. For example, Open Shortest Path First (OSPF) uses the IP addresses 224.0.0.5 and 224.0.0.6 to exchange link-state information. This lists some well-known link local IP addresses.

Notes:

Silicon-IPTV-Broadcast -373

Globally Scoped Addresses • IANA has assigned multicast addresses globally to a number of protocols • They are in the 224.0.0.0/16 range - several hundred in all! • Routers should NOT forward streams sent to these addresses • Examples:224.0.0.0 Base Address (Reserved) [RFC1112,JBP] 224.0.0.1 All Systems on this Subnet [RFC1112,JBP] 224.0.0.2 All Routers on this Subnet [JBP] 224.0.0.3 Unassigned [JBP] 224.0.0.4 DVMRP Routers [RFC1075,JBP] 224.0.0.5 OSPFIGP OSPFIGP All Routers [RFC2328,JXM1] 224.0.0.6 OSPFIGP OSPFIGP Designated Routers [RFC2328,JXM1] 224.0.0.7 ST Routers [RFC1190,KS14] 224.0.0.8 ST Hosts [RFC1190,KS14] 224.0.0.9 RIP2 Routers [RFC1723,GSM11] 224.0.0.10 IGRP Routers [Farinacci]

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -374

Addresses in the range from 224.0.1.0 through 238.255.255.255 are called globally scoped addresses. These addresses are used to multicast data between organizations and across the Internet. Some of these addresses have been reserved for use by multicast applications through IANA. For example, IP address 224.0.1.1 has been reserved for Network Time Protocol (NTP). IP addresses reserved for IP multicast are defined in RFC 1112, Host Extensions for IP Multicasting. More information about reserved IP multicast addresses can be found at the following location: http://www.iana.org/assignments/multicast-addresses

Notes:

Silicon-IPTV-Broadcast -374

Source Specific Multicast (SSM) • Addresses in the range 232/8 are reserved for source specific Multicast • Useful when several sources use the same multicast destination for different applications • End systems can distinguish application protocols but network efficiency suffers • By requesting streams based on the full (S, G) identity this is avoided • The receiver application sends a join a particular source by using the INCLUDE mode in IGMPv3 — The multicast router can now send the request directly to the source rather than send the request to a common RP as in PIM sparse mode

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -375

If two applications with different sources and receivers use the same IP multicast group address, receivers of both applications will receive traffic from the senders of both the applications. Even though the receivers, if programmed appropriately, can filter out the unwanted traffic, this situation still would likely generate noticeable levels of unwanted network traffic. In an SSM-enhanced multicast network, the router closest to the receiver will "see" a request from the receiving application to join to a particular multicast source. The receiver application then can signal its intention to join a particular source by using the INCLUDE mode in IGMPv3. The multicast router can now send the request directly to the source rather than send the request to a common RP as in PIM sparse mode. At this point, the source can send data directly to the receiver using the shortest path. In SSM, routing of multicast traffic is entirely accomplished with source trees. There are no shared trees and therefore an RP is not required. SSM also solves IP multicast address collision issues associated with one-to-many type applications. Routers running in SSM mode will route data streams based on the full (S, G) address, S making the entry unique.

Notes:

Silicon-IPTV-Broadcast -375

GLOP Addresses • GLOP is not an acronym • It is a means of assigning addresses in 233/8 • They are based on an autonomous system number • For a given ASN number, converted into two octets (say X and Y) • The GLOP space is therefore 233.X.Y/24

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -376

RFC 2770, GLOP Addressing in 233/8, proposes that the 233.0.0.0/8 address range be reserved for statically defined addresses by organizations that already have an AS number reserved. This practice is called GLOP addressing. The AS number of the domain is embedded into the second and third octets of the 233.0.0.0/8 address range. For example, the AS 62010 is written in hexadecimal format as F23A. Separating the two octets F2 and 3A results in 242 and 58 in decimal format. These values result in a subnet of 233.242.58.0/24 that would be globally reserved for AS 62010 to use.

Notes:

Silicon-IPTV-Broadcast -376

Limited Scope Addresses • Addresses in the 239/8 range are called limited scope addresses — or sometimes administratively scoped addresses • These addresses are described in RFC 2365 • Used by multicast applications that will not be forwarded outside their domain

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -377

Addresses in the 239.0.0.0/8 range are called limited scope addresses or administratively scoped addresses. These addresses are described in RFC 2365, Administratively Scoped IP Multicast, to be constrained to a local group or organization. Companies, universities, or other organizations can use limited scope addresses to have local multicast applications that will not be forwarded outside their domain. Routers typically are configured with filters to prevent multicast traffic in this address range from flowing outside of an autonomous system (AS) or any user-defined domain. Within an autonomous system or domain, the limited scope address range can be further subdivided so that local multicast boundaries can be defined. This subdivision is called address scoping and allows for address reuse between these smaller domains.

Notes:

Silicon-IPTV-Broadcast -377

Layer 2 Multicast Addresses • Multicast MAC addresses have the lowest order bit in the first byte set • If they are locally administered then the next lowest is set too

XXXXXX11

XXXXXXXX

XXXXXXXX

XXXXXXXX

XXXXXXXX

XXXXXXXX

Broadcast or multicast Locally administered address

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -378

In IP multicast, several hosts need to be able to receive a single data stream with a common destination MAC address. Some means had to be devised so that multiple hosts could receive the same packet and still be able to differentiate between several multicast groups. One method to accomplish this is to map IP multicast Class D addresses directly to a MAC address. Today, using this method, NICs can receive packets destined to many different MAC addresses—their own unicast, broadcast, and a range of multicast addresses.The IEEE LAN specifications made provisions for the transmission of broadcast and multicast packets. In the 802.3 standard, bit 0 of the first octet is used to indicate a broadcast or multicast frame. The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in hexadecimal format. Half of this block is allocated for multicast addresses. The range from 0100.5e00.0000 through 0100.5e7f.ffff is the available range of Ethernet MAC addresses for IP multicast.This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group address. The mapping places the lower 23 bits of the IP multicast group address into these available 23 bits in the Ethernet address

Notes:

Silicon-IPTV-Broadcast -378

Layer 2 Multicast Addresses • IANA has devised a mechanism for generating multicast MAC addresses • IANA has allocated to it the prefix 01-00-5e • The lower 23 bits of the IP multicast group address are used in the lowest 23 bits — This is not perfect as 32 multicast addresses map to each MAC address — Care should be taken when selecting addresses to keep the lowest 3 bytes unique

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -379

Because the upper five bits of the IP multicast address are dropped in this mapping, the resulting address is not unique. In fact, 32 different multicast group IDs map to the same Ethernet address . Network administrators should consider this fact when assigning IP multicast addresses. For example, 224.1.1.1 and 225.1.1.1 map to the same multicast MAC address on a Layer 2 switch. If one user subscribed to Group A (as designated by 224.1.1.1) and the other users subscribed to Group B (as designated by 225.1.1.1), they would both receive both A and B streams. This situation limits the effectiveness of this multicast deployment.

Notes:

Silicon-IPTV-Broadcast -379

Multicasting At Layer 2 • There are 3 methods of controlling multicasting at layer 2 — Cisco Group Management Protocol (CGMP) — IGMP Snooping — Router-Port Group Management Protocol (RGMP) – Used on routed segments that contain only routers • CGMP and IGMP Snooping are used on subnets that include end users or receiver clients

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -380

The default behavior for a Layer 2 switch is to forward all multicast traffic to every port that belongs to the destination LAN on the switch. This behavior reduces the efficiency of the switch, whose purpose is to limit traffic to the ports that need to receive the data. Three methods efficiently handle IP multicast in a Layer 2 switching environment—Cisco Group Management Protocol (CGMP), IGMP Snooping, and Router-Port Group Management Protocol (RGMP). CGMP and IGMP Snooping are used on subnets that include end users or receiver clients. RGMP is used on routed segments that contain only routers, such as in a collapsed backbone.

Notes:

Silicon-IPTV-Broadcast -380

Multicasting and Stream Delivery

Multicast Concepts Multicast Addressing IGMP PIM Sparse Mode Configuration Analysis of Multicast Exchanges Troubleshooting Multicast Problems Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -381

Notes:

Silicon-IPTV-Broadcast -381

Requests for Multicasts Streams

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -382

The receivers indicate their interest by sending an Internet Group Management Protocol (IGMP) host report to the routers in the network. The routers are then responsible for delivering the data from the source to the receivers. The routers use Protocol Independent Multicast (PIM) to dynamically create a multicast distribution tree. The video data stream will then be delivered only to the network segments that are in the path between the source and the receivers. This process is further explained in the following sections. Multicast is based on the concept of a group. A multicast group is an arbitrary group of receivers that expresses an interest in receiving a particular data stream. This group has no physical or geographical boundaries—the hosts can be located anywhere on the Internet or any private internetwork. Hosts that are interested in receiving data flowing to a particular group must join the group using IGMP .

Notes:

Silicon-IPTV-Broadcast -382

Multicast Concepts

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -383

IP multicast is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to potentially thousands of corporate recipients and homes. IP multicast delivers application source traffic to multiple receivers without burdening the source or the receivers while using a minimum of network bandwidth. Multicast packets are replicated in the network at the point where paths diverge by routers enabled with Protocol Independent Multicast (PIM) and other supporting multicast protocols, resulting in the most efficient delivery of data to multiple receivers. Many alternatives to IP multicast require the source to send more than one copy of the data. Some, such as application-level multicast, require the source to send an individual copy to each receiver. Even low-bandwidth applications can benefit from using IP multicast when there are thousands of receivers. High-bandwidth applications, such as MPEG video, may require a large portion of the available network bandwidth for a single stream. In these applications, IP multicast is the only way to send to more than one receiver simultaneously. The figure shows how IP multicast is used to deliver data from one source to many interested recipients

Notes:

Silicon-IPTV-Broadcast -383

Internet Group Management Protocol (IGMP) • IGMP is used to dynamically register individual hosts in a multicast group — Normally works on a particular LAN • There are 3 versions of IGMP • Version 1 has only 2 message types — Membership query — Membership report • Version 2 has 4 message types — Membership query — Version 1 membership report — Version 2 membership report — Leave group • Version 3 adds a further Version 3 membership report

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -384

IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Hosts identify group memberships by sending IGMP messages to their local multicast router. Under IGMP, routers listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet. In version 1 IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Hosts identify group memberships by sending IGMP messages to their local multicast router. Under IGMP, routers listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet. IGMPv1 has been superceded by IGMP Version 2 (IGMPv2), which is now the current standard. IGMPv2 is backward compatible with IGMPv1. RFC 2236, Internet Group Management Protocol, Version 2, describes the specification for IGMPv2 The main difference is that there is a leave group message. With this message, the hosts can actively communicate to the local multicast router that they intend to leave the group.

Notes:

Silicon-IPTV-Broadcast -384

IGMP Version 3 RFC 3376 • IGMPv3 query message enables more reliable group control • 0x11 Membership Query • 0x22 Version 3 Membership Report Must also support these for compatability with versions 1 and 2

• 0x12 Version 1 Membership Report [RFC-1112] • 0x16 Version 2 Membership Report [RFC-2236] • 0x17 Version 2 Leave Group [RFC-2236] Query Request

Query Report

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -385

IGMP Version 3 (IGMPv3) is the next step in the evolution of IGMP. IGMPv3 adds support for "source filtering," which enables a multicast receiver host to signal to a router the groups from which it wants to receive multicast traffic, and from which sources this traffic is expected. This membership information enables Cisco IOS software to forward traffic from only those sources from which receivers requested the traffic. IGMPv3 is an emerging standard. The latest versions of Windows, Macintosh, and UNIX operating systems all support IGMPv3. At the time this document was being written, application developers were in the process of porting their applications to the IGMPv3 API.

Notes:

Silicon-IPTV-Broadcast -385

IGMPv3 Modes • IGMPv3 can operate on one of two modes — INCLUDE mode—the receiver announces membership to a host group – It provides a list of source addresses known as the INCLUDE list — EXCLUDE mode—the receiver announces membership to a multicast group – It provides a list of source addresses known as the EXCLUDE list – These are addresses from which it does not want to receive traffic – To receive traffic from all sources an empty EXCLUDE list is used – This is the behavior of IGMPv2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -386

IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMPv3, receivers signal membership to a multicast host group in the following two modes: INCLUDE mode—In this mode, the receiver announces membership to a host group and provides a list of source addresses (the INCLUDE list) from which it wants to receive traffic. EXCLUDE mode—In this mode, the receiver announces membership to a multicast group and provides a list of source addresses (the EXCLUDE list) from which it does not want to receive traffic. The host will receive traffic only from sources whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all sources, which is the behavior of IGMPv2, a host uses EXCLUDE mode membership with an empty EXCLUDE list. The current specification for IGMPv3 can be found in the Internet Engineering Task Force (IETF) draft titled Internet Group Management Protocol, Version 3 on the IETF website.

Notes:

Silicon-IPTV-Broadcast -386

IGMP State Maintained by Multicast Routers • Multicast routers implementing IGMPv3 keep state per group per attached network • state conceptually consists of a set of records of the form: — (multicast address, group timer, filter-mode, (source records)) • Each source record is of the form: — (source address, source timer) • If all sources within a given group are desired, an empty source record list is kept with filter-mode set to EXCLUDE

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -387

Multicast routers send Host Membership Query messages (hereinafter called Queries) to discover which host groups have members on their attached local networks. Queries are addressed to the all-hosts group (address 224.0.0.1), and carry an IP time-to-live of 1. Hosts respond to a Query by generating Host Membership Reports reporting each host group to which they belong on the network interface from which the Query was received.

Notes:

Silicon-IPTV-Broadcast -387

Router Filter-Mode • IGMPv3 routers keep a filter-mode per group per attached network • When a group record is received, the router filter-mode for that group is updated to cover all the requested sources • When a router filter-mode for a group is EXCLUDE, the source record list contains two types of sources — the set which represents conflicts in the desired reception state — the set of sources which hosts have requested to not be forwarded • When a router filter-mode for a group is INCLUDE, the source record list is the list of sources desired for the group

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -388

In order to avoid an "implosion" of concurrent Reports and to reduce the total number of Reports transmitted, two techniques are used: When a host receives a Query, rather than sending Reports immediately, it starts a report delay timer for each of its group memberships on the network interface of the incoming Query. Each timer is set to a different, randomly-chosen value between zero and D seconds. When a timer expires, a Report is generated for the corresponding host group. Thus, Reports are spread out over a D second interval instead of all occurring at once. A Report is sent with an IP destination address equal to the host group address being reported, and with an IP time-to-live of 1, so that other members of the same group on the same network can overhear the Report. If a host hears a Report for a group to which it belongs on that network, the host stops its own timer for that group and does not generate a Report for that group. Thus, in the normal case, only one Report will be generated for each group present on the network, by the member host whose delay timer expires first. Note that the multicast routers receive all IP multicast datagrams, and therefore need not be addressed explicitly. Further note that the routers need not know which hosts belong to a group, only that at least one host belongs to a group on a particular network.

Notes:

Silicon-IPTV-Broadcast -388

IGMP States A host may be in one of three possible states, with respect to any single IP host group on any single network interface • Non-Member state — The host does not belong to the group on the interface. This is the initial state for all memberships on all network interfaces; it requires no storage in the host. • Delaying Member state — The host belongs to the group on the interface and has a report delay timer running for that membership. • Idle Member state — The host belongs to the group on the interface and does not have a report delay timer running for that membership

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -389

Multicast routers send Queries periodically to refresh their knowledge of memberships present on a particular network. If no Reports are received for a particular group after some number of Queries, the routers assume that that group has no local members and that they need not forward remotely-originated multicasts for that group onto the local network. Queries are normally sent infrequently (no more than once a minute) so as to keep the IGMP overhead on hosts and networks very low. However, when a multicast router starts up, it may issue several closely-spaced Queries in order to build up its knowledge of local memberships quickly. When a host joins a new group, it should immediately transmit a Report for that group, rather than waiting for a Query, in case it is the first member of that group on the network. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays. A simple way to accomplish this is to act as if a Query had been received for that group only, setting the group's random report delay timer. Note that, on a network with no multicast routers present, the only IGMP traffic is the one or more Reports sent whenever a host joins a new group.

Notes:

Silicon-IPTV-Broadcast -389

Events Causing State Transitions • "join group" occurs when the host decides to join the group on the interface. • "leave group" occurs when the host decides to leave the group on the interface. • "query received" occurs when the host receives a valid IGMP Host Membership Query message. • "report received" occurs when the host receives a valid IGMP Host Membership Report message. • "timer expired" occurs when the report delay timer for the group on the interface expires. It may occur only in the Delaying Member state

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -390

Hosts respond to a Query by generating Host Membership Reports (hereinafter called Reports), reporting each host group to which they belong on the network interface from which the Query was received. In order to avoid an "implosion" of concurrent Reports and to reduce the total number of Reports transmitted, two techniques are used: When a host receives a Query, rather than sending Reports immediately, it starts a report delay timer for each of its group memberships on the network interface of the incoming Query. Each timer is set to a different, randomlychosen value between zero and D seconds. When a timer expires, a Report is generated for the corresponding host group. Thus, Reports are spread out over a D second interval instead of all occurring at once.

Notes:

Silicon-IPTV-Broadcast -390

IGMP Actions • "send report" for the group on the interface • "start timer" for the group on the interface, using a random delay value between 0 and D seconds — The maximum report delay D is 10 seconds • "stop timer" for the group on the interface

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -391

A Report is sent with an IP destination address equal to the host group address being reported, and with an IP time-to-live of 1, so that other members of the same group on the same network can overhear the Report. If a host hears a Report for a group to which it belongs on that network, the host stops its own timer for that group and does not generate a Report for that group. Thus, in the normal case, only one Report will be generated for each group present on the network, by the member host whose delay timer expires first. Note that the multicast routers receive all IP multicast datagrams, and therefore need not be addressed explicitly. Further note that the routers need not know which hosts belong to a group, only that at least one host belongs to a group on a particular network.

Notes:

Silicon-IPTV-Broadcast -391

Queries and reports • Query Message — Must be at least 8 octets long and have a correct IGMP checksum — Have an IP destination address of 224.0.0.1 — A single Query applies to all memberships on the interface from which the Query is received — It is ignored for memberships in the Non-Member or Delaying Member state • Report Message — Must be at least 8 octets long and have a correct IGMP checksum — Contain the same IP host group address in its IP destination field and its IGMP group address field — A Report applies only to the membership in the group identified by the Report, on the interface from which the Report is received — It is ignored for memberships in the Non-Member or Idle Member state

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -392

Notes:

Silicon-IPTV-Broadcast -392

IGMP State Trsnsitions

Non-Member

Leave Group (stop timer)

Leave Group Join Group (send report start timer)

DelayingMember

Query received (start timer)

Idle-Member

Report received (stop timer) Timer expired (send report) © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -393

Multicast routers send Queries periodically to refresh their knowledge of memberships present on a particular network. If no Reports are received for a particular group after some number of Queries, the routers assume that that group has no local members and that they need not forward remotely-originated multicasts for that group onto the local network. Queries are normally sent infrequently, no more than once a minute, so as to keep the IGMP overhead on hosts and networks very low. However, when a multicast router starts up, it may issue several closely-spaced Queries in order to build up its knowledge of local memberships quickly. When a host joins a new group, it should immediately transmit a Report for that group, rather than waiting for a Query, in case it is the first member of that group on the network. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays. (A simple way to accomplish this is to act as if a Query had been received for that group only, setting the group's random report delay timer. The state transition diagram below this approach. On a network with no multicast routers present, the only IGMP traffic is the one or more Reports sent whenever a host joins a new group.

Notes:

Silicon-IPTV-Broadcast -393

Manipulating IGMP access-group

IGMP group access group

helper-address

IGMP helper address

join-group

IGMP join multicast group

last-member-query-interval

IGMP last member query interval

querier-timeout

IGMP previous querier timeout

query-interval

IGMP host query interval

query-max-response-time

IGMP max query response value

static-group

IGMP static multicast group

unidirectional-link

IGMP unidirectional link multicast routing

version

IGMP version

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -394

These are the qualifiers that can be applied to “ip igmp” commands to manipulate IGMP on Cisco devices..

Notes:

Silicon-IPTV-Broadcast -394

Limiting the Joining of Groups •

To filter multicast groups allowed on an interface, use the following command in interface configuration mode: — ip igmp access-group access-list-number

•

Multicast routers send host-query messages periodically — This is used to refresh their knowledge of memberships present

•

At least one router must be present to produce these queries — Low cost switch vendors often use IGMP spoofing — This will propagate IGMP information in response to queries

•

To modify this interval, use the following command in interface configuration mode: — ip igmp query-interval seconds

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -395

Multicast routers send IGMP host-query messages to discover which multicast groups are present on attached networks. These messages are sent to the all-systems group address of 224.0.0.1 with a TTL of 1. Multicast routers send host-query messages periodically to refresh their knowledge of memberships present on their networks. If, after some number of queries, the Cisco IOS software discovers that no local hosts are members of a multicast group, the software stops forwarding onto the local network multicast packets from remote origins for that group and sends a prune message upstream toward the source. Multicast routers elect a PIM designated router for the LAN (subnet). This is the router with the highest IP address. The designated router is responsible for sending IGMP host-query messages to all hosts on the LAN. In sparse mode, the designated router also sends PIM register and PIM join messages toward the RP router.

Notes:

Silicon-IPTV-Broadcast -395

IGMP Versions 1 and 2 •

To control which version of IGMP the router uses, use the following command in interface configuration mode: — ip igmp version {2 | 1}

•

To change the query timeout in version 2, use the following command in interface configuration mode: — ip igmp query-timeout seconds

•

To change the maximum query response time, use the following command in interface configuration mode: — ip igmp query-max-response-time seconds

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -396

By default, the router uses IGMP Version 2, which allows such features as the IGMP query timeout and the maximum query response time. All routers on the subnet must support the same version. The router does not automatically detect Version 1 routers and switch to Version 1 as did earlier releases of the Cisco IOS software. However, a mix of IGMP Version 1 and Version 2 hosts on the subnet is acceptable. IGMP Version 2 routers will always work correctly in the presence of IGMP Version 1 hosts. You can specify the period of time before the router takes over as the querier for the interface, after the previous querier has stopped doing so. By default, the router waits 2 times the query interval controlled by the ip igmp query-interval command. After that time, if the router has received no queries, it becomes the querier. This feature requires IGMP Version 2. By default, the maximum query response time advertised in IGMP queries is 10 seconds. If the router is using IGMP Version 2, you can change this value. The maximum query response time allows a router to quickly detect that there are no more directly connected group members on a LAN. Decreasing the value allows the router to prune groups faster.

Notes:

Silicon-IPTV-Broadcast -396

Capture of IGMP – Client Starts First

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -397

In this example we have captured a multicast stream and filtered on IGMP. We started VLC which made two IGMPv3 requests in packet 37 and 38. The multicast stream ran until at packet 27365 when the router at 10.0.0.254 sent a membership report to 224.0.1.40 using IGMPv2. From this point on the traffic will downgrade to IGMPv2. At 27367 the router sends an IGMPv2 query to 224.0.0.1 – all systems on the LAN. At packet 27384 the receiver sends a membership report to 239.255.255.250 and then immediately after to 255.1.2.3. Following this there are repeated queries to

Notes:

Silicon-IPTV-Broadcast -397

Server and Router Start First

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -398

Notice here where the server starts first and the router sends IGMPv2 messages before the client starts, the client starts in IGMPv2. Notice at packet 52 the client joins the group for 225.1.2.3 by sending a membership report. It repeats this at packets 197 and 507. We can time the difference between these requests

Notes:

Silicon-IPTV-Broadcast -398

Setting Time Reference

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -399

By right clicking on packet 52 we can set a time reference so that we can measure time starting from this point.

Notes:

Silicon-IPTV-Broadcast -399

Timing Between Events

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -400

Now we can read off the times of the membership reports and see that the three are sent about half a second apart. At packet 2152 the router sends a query at time 6.572898 and we see that further queries are sent every 10 seconds. We configured the query interval to be shorter than the default so that it was easier to trace. Using the Timing reference see how long it takes for the client to respond to the query. This must happen within the Query Timeout time.

Notes:

Silicon-IPTV-Broadcast -400

IGMP Snooping • IGMP Snooping is a function of layer 2 switches • It causes them to look for IGMP membership reports — These are sent in response to the router IGMP queries • The layer 2 switch delivers multicasts matching the group address • At least one layer 3 device must exist to send the queries • The shorter the query interval the more responsive the switch can be

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -401

IGMP Snooping is a function of layer 2 switches that causes them to look for IGMP membership reports that are sent in response to the router IGMP queries.

Notes:

Silicon-IPTV-Broadcast -401

Multicasting and Stream Delivery

Multicast Concepts Multicast Addressing IGMP PIM Sparse Mode Configuration Analysis of Multicast Exchanges Troubleshooting Multicast Problems Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -402

Notes:

Silicon-IPTV-Broadcast -402

Multicast Distribution Trees • Shortest Path or Source Distribution Tree

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -403

Shortest Path Trees — aka Source Trees – A Shortest path or source distribution tree is a minimal spanning tree with the lowest cost from the source to all leaves of the tree. – We forward packets on the Shortest Path Tree according to both the Source Address that the packets originated from and the Group address G that the packets are addressed to. For this reason we refer to the forwarding state on the SPT by the notation (S,G) (pronounced “S comma G”). where: • “S” is the IP address of the source. • “G” is the multicast group address – Example 1: • The shortest path between Source 1 and Receiver 1 is via Routers A and C, and shortest path to Receiver 2 is one additional hop via Router E.

Notes:

Silicon-IPTV-Broadcast -403

Multicast Distribution Trees • Shortest Path or Source Distribution Tree

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -404

– Every SPT is routed at the source. This means that for every source sending to a group, there is a corresponding Shortest Path Tree. – Example 2: The shortest path between Source 2 and Receiver 1 is via Routers D, F and C, and shortest path to Receiver 2 is one additional hop via Router E.

Notes:

Silicon-IPTV-Broadcast -404

Multicast Distribution Trees • Shared Distribution Tree

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -405

Shared Distribution Trees – Shared distribution tree whose root is a shared point in the network down which multicast data flows to reach the receivers in the network. In PIM-SM, this shared point is called the Rendezvous Point (RP). – Multicast traffic is forwarded down the Shared Tree according to just the Group address G that the packets are addressed to, regardless of source address. For this reason we refer to the forwarding state on the shared tree by the notation (*,G) (pronounced “star comma G”) where: • “*” means any source • “G” is the group address

Notes:

Silicon-IPTV-Broadcast -405

Multicast Distribution Trees • Shared Distribution Tree

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -406

Shared Distribution Trees – Before traffic can be sent down the Shared Tree it must somehow be sent to the Root of the Tree. – In classic PIM-SM, this is accomplished by the RP joining the Shortest Path Tree back to each source so that the traffic can flow to the RP and from there down the shared tree. In order to trigger the RP to take this action, it must somehow be notified when a source goes active in the network. • In PIM -SM, this is accomplished by first-hop routers (i.e. the router directly connected to an active source) sending a special Register message to the RP to inform it of the active source. – In the example above, the RP has been informed of Sources 1 and 2 being active and has subsequently joined the SPT to these sources.

Notes:

Silicon-IPTV-Broadcast -406

Characteristics of Distribution Trees • Source or Shortest Path trees — Uses more memory O(S x G) but you get optimal paths from source to all receivers; minimizes delay • Shared trees — Uses less memory O(G) but you may get sub-optimal paths from source to all receivers; may introduce extra delay

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -407

Source or Shortest Path Tree Characteristics Provides optimal path (shortest distance and minimized delay) from source to all receivers, but requires more memory to maintain Shared Tree Characteristics Provides sub-optimal path (may not be shortest distance and may introduce extra delay) from source to all receivers, but requires less memory to maintain

Notes:

Silicon-IPTV-Broadcast -407

Building Distribution Trees • PIM — Uses existing Unicast Routing Table plus Join/Prune/Graft mechanism to build tree • DVMRP — Uses DVMRP Routing Table plus special Poison-Reverse mechanism to build tree • MOSPF — Uses extension to OSPF’slink state mechanism to build tree. • CBT — Uses existing Unicast Routing Table plus Join/Prune/Graft mechanism to build tree

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -408

Distribution trees are built in a variety of ways, depending upon the multicast routing protocol employed. PIM utilizes the underlying unicast routing table (any unicast routing protocol). Join: routers add their interfaces and/or send PIM -JOIN messages upstream to establish themselves as branches of the tree when they have interested receivers attached. Prune: routers prune their interfaces and/or send PIM-PRUNE messages upstream to remove themselves from the distribution tree when they no longer have interested receivers attached Graft: routers send PIM-GRAFT messages upstream when they have a pruned interface and have already sent PIM-PRUNEs upstream, but receive an IGMP host report for the group that was pruned; routers must reestablish themselves as branches of the distribution tree because of new interested receivers attached DVMRP utilizes a special RIP -like multicast routing table. Poison-Reverse: a special metric of Infinity (32) plus the originally received metric, used to signal that the router should be placed on the distribution tree for the source network. Prunes & Grafts: routers send Prunes and Grafts up the distribution similar to PIM-DM. MOSPF utilizies the underlying OSPF unicast routing protocol's link state advertisements to build (S,G) trees. Each router maintains an up-to-date image of the topology of the entire network. CBT utilizes the underlying unicast routing table and the Join/Prune/Graft mechanisms (much like PIM -SM)

Notes:

Silicon-IPTV-Broadcast -408

RPF Check Failure

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -409

Multicast Forwarding: RPF Check Fails Ex: Router can only accept multicast data from Source 151.10.3.21 on interface S1 ... multicast data is silently dropped because it arrived on an interface not specified in the RPF check (S0)

Notes:

Silicon-IPTV-Broadcast -409

RPF Check Succeeds

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -410

Multicast Forwarding: RPF Check Succeeds Ex: Router can only accept multicast data from Source 151.10.3.21 on interface S1 ... multicast data is forwarded out all outgoing on the distribution tree because it arrive on the incoming interface specified in the RPF check (S1)

Notes:

Silicon-IPTV-Broadcast -410

TTL Thresholds • What is a TTL Threshold? — A “TTL Threshold” may be set on a multicast router interface to limit the forwarding of multicast traffic to outgoing packets with TTLs greater than the Threshold • The TTL Threshold Check — 1) All incoming IP packets first have their TTL decremented byone. If <= Zero, they are dropped. — 2) If a multicast packet is to be forwarded out an interface with a non-zero TTL Threshold; then it’s TTL is checked against the TTL Threshold. If the packet’s TTL is < the specified threshold, it is not forwarded out the interface.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -411

TTL-Thresholds Non-Zero, Multicast, TTL-Thresholds may be set on any multicast capable interface. IP multicast packets whose TTLs (after being decremented by one by normal router packet processing) are less than the TTL -Threshold on an outgoing interface, will be not be forwarded out that interface. Zero Multicast TTL implies NO threshold has been set. TTL-Threshold Application Frequently used to set up multicast boundaries to prevent unwanted multicast traffic from entering/exiting the network.

Notes:

Silicon-IPTV-Broadcast -411

TTL Thresholds Example

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -412

TTL-Threshold Example In the above example, the interfaces have been configured with the following TTL Thresholds: S1: TTL -Threshold = 16 E0: TTL -Threshold = 0 (none) S2: TTL -Threshold = 64 An incoming Multicast packet is received on interface S0 with a TTL of 24. The TTL is decremented to 23 by the normal router IP packet processing. The outgoing interface list for this Group contains interfaces S1, E0 & S2. The TTL-Threshold check is performed on each outgoing interface as follows: S1: TTL (23) > TTL -Threshold (16). FORWARD E0: TTL (23) > TTL -Threshold (0). FORWARD S2: TTL (23) < TTL -Threshold (64). DROP

Notes:

Silicon-IPTV-Broadcast -412

TTL Threshold Boundaries

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -413

TTL-Threshold Boundaries TTL-Thresholds may be used as boundaries around portions of a network to prevent the entry/exit of unwanted multicast traffic. This requires multicast applications to transmit their multicast traffic with an initial TTL value set so as to not cross the TTL -Threshold boundaries. In the example above, the Engineering or Marketing departments can prevent department related multicast traffic from leaving their network by using a TTL of 15 for their multicast sessions. Similarly, Company ABC can prevent private multicast traffic from leaving their network by using a TTL of 127 for their multicast sessions.

Notes:

Silicon-IPTV-Broadcast -413

Administrative Boundaries

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -414

Administrative Boundaries Administratively-scoped multicast address ranges may also be used as boundaries around portions of a network to prevent the entry/exit of unwanted multicast traffic. This requires multicast applications to transmit their multicast traffic with a group address that falls within the Administrative address range so that it will not cross the Administrative boundaries. In the example above, the entire Administratively-Scoped address range, (239.0.0.0/8) is being blocked from entering or leaving the router via interface Serial0. This is often done at the border of a network where it connects to the Internet so that potentially sensitive company Administratively-Scoped multicast traffic can leave the network. (Nor can it enter the network from the outside.)

Notes:

Silicon-IPTV-Broadcast -414

Administrative Boundaries

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -415

Administratively-scoped multicast address ranges generally used in more than one location. In the example above, the Administratively-Scoped address range, (239.128.0.0/16) is being used by both the LA campus and the NYC campus. Multicast traffic originated in these address ranges will remain within each respective campus and not onto the WAN that exists between the two campuses. This is often sort of configuration is often used so that each campus can source high-rate multicasts on the local campus and not worry about it being accidentally “leaked” into the WAN and causing congestion on the slower WAN links. In addition to the 239.128.0.0/16 range, the entire company network has a Administrative boundary for the 239.129.0.0/16 multicast range. This is so that multicasts in these ranges do not leak into the Internet. The Admin. -Scoped address range (239..0.0/8) is similar to the 10.0.0.0 unicast address range in that it is reserved and is not assigned for use in the Internet.

Notes:

Silicon-IPTV-Broadcast -415

Types of Multicast Protocols • Dense-mode — Uses “Push” Model — Traffic Flooded throughout network — Pruned back where it is unwanted — Flood & Prune behavior (typically every 3 minutes) • Sparse-mode — Uses “Pull” Model — Traffic sent only to where it is requested — Explicit Join behavior

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -416

Dense-mode multicast protocols Initially flood/broadcast multicast data to entire network, then prune back paths that don't have interested receivers Sparse-mode multicast protocols Assumes no receivers are interested unless they explicitly ask for it

Notes:

Silicon-IPTV-Broadcast -416

Dense Mode S2

S1

R1

R2

R3

S3

R4

R5

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

R6

Silicon-IPTV-Broadcast -417

In dense mode, every stream is delivered to every interface of every router unless pruned off. If there is a small number of streams, one say, and this needs to reach every user with an AS say the dense mode is a good choice. Typically this might be for a rare event, the board of directory’s announcement annually of profits, a televised broadcast of the first person to step on the moon – or next time Mars. If streams are not being viewed dense mode can waste a great deal of capacity and slow down normal operation.

Notes:

Silicon-IPTV-Broadcast -417

Sparse Mode S2

S1

S3

RP1 RP3 RP2

R1

R2

R3

R4

R5

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

R6

Silicon-IPTV-Broadcast -418

In sparse mode streams are delivered only when requested and only to interfaces where there are subscribers requesting service. We could support thousands of streams provided nobody viewed them! We can probably support small numbers of hundreds of channels to an MSAN with perhaps one channel to each subscriber on an MSAN. If we assume that a TV stream requires 5 Mbit/s, an access speed of better than 10 Mbit/s is needed to the subscriber and for a Gbit/s backhaul on an MSAN we could support as 100 channels at 50% load.

Notes:

Silicon-IPTV-Broadcast -418

Multicast Protocols • Currently, there are 4 multicast routing protocols: • DVMRP — DVMRPv3 (Internet-draft) — DVMRPv1 (RFC1075) is obsolete and was never used. • MOSPF (RFC 1584) “Proposed Standard” • PIM-DM (Internet-draft) • PIM-SM (RFC 2362) “Proposed Standard”

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -419

DVMRPv1 is obsolete and was never used. DVMRPv2 is an old “Internet-Draft” and is the current implementation used through-out the Mbone. DVMRPv3 is the current “Internet-Draft” although it has not been completely implemented by most vendors. MOSPF is currently at “Proposed Standard” status. However, most members of the IETF IDMR working group doubt that MOSPF will scale to any degree and are therefore uncomfortable with declaring MOSPF as a standard for IP Multicasting. (Even the author of MOSPF, J. Moy, has been quoted in an RFC that, “more work needs to be done to determine the scalability of MOSPF.”) PIM-DM is in Internet Draft form and work continues to move into an RFC. CBT is also in Internet Draft form and while it has been through three different and incompatible revisions, it is not enjoying significant usage nor is it a primary focus of the IETF IDMR working group. PIM-SM moved to “Proposed Standard” in early 2000. Much of the effort in the IETF towards a working multicast protocol is focused on PIM -SM.

Notes:

Silicon-IPTV-Broadcast -419

Dense-Mode Protocols • DVMRP - Distance Vector Multicast Routing Protocol • MOSPF - Multicast OSPF • PIM DM - Protocol Independent Multicasting (Dense Mode)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -420

Notes:

Silicon-IPTV-Broadcast -420

PIM-SM (RFC 2362) • Supports both source and shared trees — Assumes no hosts want multicast traffic unless they specifically ask for it • Uses a Rendezvous Point (RP) — Senders and Receivers “rendezvous” at this point to learn of each others existence. • Senders are “registered” with RP by their first-hop router. • Receivers are “joined” to the Shared Tree (rooted at the RP) by their local Designated Router (DR). • Appropriate for… — Wide scale deployment for both densely and sparsely populated groups in the enterprise — Optimal choice for all production networks regardless of size and membership density.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -421

Utilizes a rendezvous point (RP) to coordinate forwarding from source to receivers Regardless of location/number of receivers, senders register with RP and send a single copy of multicast data through it to registered receivers Regardless of location/number of sources, group members register to receive data and always receive it through the RP Appropriate for Wide scale deployment for both densely and sparsely populated groups in the Enterprise Optimal choice for all production networks regardless of size and membership density.

Notes:

Silicon-IPTV-Broadcast -421

PIM-SM Shared Tree Joins

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -422

In this example, there is an active receiver (attached to leaf router at the bottom of the drawing) has joined multicast group “G”. The leaf router knows the IP address of the Rendezvous Point (RP ) for group G and when it sends a (*,G) Join for this group towards the RP. This (*, G) Join travels hop-by-hop to the RP building a branch of the Shared Tree that extends from the RP to the last-hop router directly connected to the receiver. At this point, group “G” traffic can flow down the Shared Tree to the receiver.

Notes:

Silicon-IPTV-Broadcast -422

PIM-SM Sender Registration

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -423

As soon as an active source for group G sends a packet the leaf router that is attached to this source is responsible for “Registering” this source with the RP and requesting the RP to build a tree back to that router. The source router encapsulates the multicast data from the source in a special PIM SM message called the Register message and unicasts that data to the RP. When the RP receives the Register message it does two things. It de-encapsulates the multicast data packet inside of the Register message and forwards it down the Shared Tree. The RP also sends an (S,G) Join back towards the source network S to create a branch of an (S, G) Shortest-Path Tree. This results in (S, G) state being created in all the router along the SPT, including the RP.

Notes:

Silicon-IPTV-Broadcast -423

PIM-SM Sender Registration

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -424

As soon as the SPT is built from the Source router to the RP, multicast traffic begins to flow natively from source S to the RP. Once the RP begins receiving data natively (i.e. down the SPT) from source S it sends a ‘Register Stop’ to the source’s first hop router to inform it that it can stop sending the unicast Register messages.

Notes:

Silicon-IPTV-Broadcast -424

PIM-SM Sender Registration

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -425

At this point, multicast traffic from the source is flowing down the SPT to the RP and from there, down the Shared Tree to the receiver.

Notes:

Silicon-IPTV-Broadcast -425

PIM-SM SPT Switchover

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -426

PIM-SM has the capability for last-hop routers (i.e. routers with directly connected members) to switch to the Shortest-Path Tree and bypass the RP if the traffic rate is above a set threshold called the “SPT-Threshold”. The default value of the SPT-Threshold” in Cisco routers is zero. This means that the default behavior for PIM-SM leaf routers attached to active receivers is to immediately join the SPT to the source as soon as the first packet arrives via the (*,G) shared tree. In the above example, the last-hop router (at the bottom of the drawing) sends an (S, G) Join message toward the source to join the SPT and bypass the RP.This (S, G) Join messages travels hop-by-hop to the first-hop router (i.e. the router connected directly to the source) thereby creating another branch of the SPT. This also creates (S, G) state in all the routers along this branch of the SPT. Finally, special (S, G)RP-bit Prune messages are sent up the Shared Tree to prune off this (S,G) traffic from the Shared Tree. If this were not done, (S, G) traffic would continue flowing down the Shared Tree resulting in duplicate (S, G) packets arriving at the receiver.

Notes:

Silicon-IPTV-Broadcast -426

PIM-SM SPT Switchover

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -427

At this point, (S, G) traffic is now flowing directly from the first -hop router to the last-hop router and from there to the receiver. Note: The RP will normally send (S, G) Prunes back toward the source to shutoff the flow of now unnecessary (S, G) traffic to the RP IFF it has received an (S, G)RP-bit Prune on all interfaces on the Shared Tree. (This step has been omitted from the example above.) As a result of this SPT-Switchover mechanism, PIM SM also supports the construction and use of SPT (S,G) trees but in a much more economical fashion than PIM DM in terms of forwarding state.

Notes:

Silicon-IPTV-Broadcast -427

PIM-SM SPT Switchover

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -428

At this point, the RP no longer needs the flow of (S, G) traffic since all branches of the Shared Tree (in this case there is only one) have pruned off the flow of (S, G) traffic. As a result, the RP will send (S, G) Prunes back toward the source to shutoff the flow of the now unnecessary (S, G) traffic to the RP Note: This will occur IFF the RP has received an (S, G)RP-bit Prune on all interfaces on the Shared Tree.

Notes:

Silicon-IPTV-Broadcast -428

PIM-SM SPT Switchover

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -429

As a result of the SPT-Switchover, (S, G) traffic is now only flowing from the firsthop router to the last-hop router and from there to the receiver. Notice that traffic is no longer flowing to the RP. As a result of this SPT-Switchover mechanism, it is clear that PIM SM also supports the construction and use of SPT (S,G) trees but in a much more economical fashion than PIM DM in terms of forwarding state.

Notes:

Silicon-IPTV-Broadcast -429

PIM-SM Frequently Forgotten Fact

“The default behavior of PIM-SM is that routers with directly connected members will join the Shortest Path Tree as soon as they detect a new multicast source.”

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -430

Unless configured otherwise, the default behaviour of Cisco routers running PIMSM is for last-hop routers to immediately switch to the SPT for any new source.

Notes:

Silicon-IPTV-Broadcast -430

PIM-SM — Evaluation • Effective for sparse or dense distribution of multicast receivers • Advantages: — Traffic only sent down “joined” branches — Can switch to optimal source-trees for high traffic sources dynamically — Unicast routing protocol-independent — Basis for inter-domain multicast routing • When used with MBGP and MSDP

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -431

Evaluation: PIM Sparse-mode Can be used for sparse of dense distribution of multicast receivers (no necessity to flood) Advantages Traffic sent only to registered receivers that have explicity joined the multicast group RP can be switched to optimal shortest-path-tree when high-traffic sources are forwarding to a sparsely distributed receiver group Inter-operates with DVMRP Potential issues Requires RP during initial setup of distribution tree (can switch to shortest-path tree once RP is established and determined sub-optimal)

Notes:

Silicon-IPTV-Broadcast -431

Conclusion

“Virtually all production networks should be configured to run PIM in Sparse mode!”

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -432

Notes:

Silicon-IPTV-Broadcast -432

Multicasting and Stream Delivery

Multicast Concepts Multicast Addressing IGMP PIM Sparse Mode Configuration Analysis of Multicast Exchanges Troubleshooting Multicast Problems Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -433

Notes:

Silicon-IPTV-Broadcast -433

Multicasting and Stream Delivery

Multicast Concepts Multicast Addressing IGMP PIM Sparse Mode Configuration Analysis of Multicast Exchanges Troubleshooting Multicast Problems Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -434

Notes:

Silicon-IPTV-Broadcast -434

PIM Version 2 Configuration •

Protocol-Independent Multicast (PIM) Version 2 features

•

Single active RP exists per multicast group with multiple backup RPs — Multiple active RPs for the same group in PIM Version 1

•

A bootstrap router (BSR) provides a fault-tolerant with automated RP discovery and distribution mechanism — Thus, routers dynamically learn the group-to-RP mappings

•

Sparse mode and dense mode are properties of a group, as opposed to an interface. — Sparse-dense mode is recommended, as opposed to either sparse mode or dense mode only.

•

PIM Join and Prune messages have more flexible encodings for multiple address families

•

A more flexible Hello packet format replaces the Query packet

•

Register messages to an RP indicate source: border router or a designated router © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -435

Notes:

Silicon-IPTV-Broadcast -435

Stages in Configuring PIM •

ip pim version [1 | 2]

•

— Default is version 2 after ios 11.3(2)T Turn On Multicasting with ip multicast-routing

• •

Configure and interface using interface type number Enable PIM on the interface with ip pim sparse-dense-mode

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -436

Notes:

Silicon-IPTV-Broadcast -436

BSRs and RPs •

Bootstrap routers (BSR) hold list of multicast groups that are reachable

•

Different BSRs are elected on each side of PIM Domain Border

•

To define a PIM Domain Border use ip pim border

•

To prevent Auto-RP messages from entering the PIM domain use Access Control List — access-list access-list-number {deny | permit} source [source-wildcard] — ip multicast boundary access-list-number

•

Configure Candidate BSRs — ip pim bsr-candidate type number hash-mask-length [priority]

•

Configure Candidate RPs — ip pim rp-candidate type number ttl group-list access-list-number

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -437

Notes:

Silicon-IPTV-Broadcast -437

Example BSR Configuration ! ip multicast-routing ! interface Ethernet0 ip address 171.69.62.35 255.255.255.240 ! interface Ethernet1 ip address 172.21.24.18 255.255.255.248 ip pim sparse-dense-mode ! interface Ethernet2 ip address 172.21.24.12 255.255.255.248 ip pim sparse-dense-mode ! router ospf 1 network 172.21.24.8 0.0.0.7 area 1 network 172.21.24.16 0.0.0.7 area 1 ! ip pim bsr-candidate Ethernet2 30 10 ip pim rp-candidate Ethernet2 group-list 5 access-list 5 permit 239.255.2.0 0.0.0.255 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -438

Notes:

Silicon-IPTV-Broadcast -438

Border Router Configuration Example ! ip multicast-routing ! ! interface Ethernet0 ip address 171.69.62.35 255.255.255.240 ! interface Ethernet1 ip address 172.21.24.18 255.255.255.248 ip pim sparse-dense-mode ip pim border ip multicast boundary 1 ! interface Ethernet2 ip address 172.21.24.12 255.255.255.248 ip pim sparse-dense-mode ! access-list 1 deny 239.0.0.0 0.255.255.255 access-list 1 deny 224.0.1.39 0.255.255.255 access-list 1 deny 224.0.1.40 0.255.255.255 access-list 1 permit 224.0.0.0 15.255.255.255 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -439

Notes:

Silicon-IPTV-Broadcast -439

Using Auto-RP •

Auto-RP is a feature that automates the distribution of group-to-RP mappings in a PIM network. Benefits: — Easy to use multiple RPs within a network to serve different group ranges. — Allows load splitting among different RPs and arrangement of RPs according to the location of group participants — Avoids inconsistent, manual RP configurations that can cause connectivity problems

•

Multiple RPs can be used to serve different group ranges or serve as hot backups of each other

•

To make Auto RP work, a router must be designated as an RP-mapping agent, which receives the RP-announcement messages from the RPs and arbitrates conflicts

•

The RP-mapping agent then sends the consistent group-to-RP mappings to all other routers

•

All routers automatically discover which RP to use for the groups they support. © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -440

Notes:

Silicon-IPTV-Broadcast -440

Using Auto-RP •

Sparse-mode environments need a default RP; sparse-dense-mode environments do not.

•

If you have sparse-dense mode configured everywhere, you do not need to choose a default RP

•

Adding Auto-RP to a sparse-mode cloud requires a default RP

•

Use that RP for the global groups, for example, 224.x.x.x

•

To designate that a router is the RP, use the following command in global configuration mode: — ip pim send-rp-announce type number scope ttl group-list access-listnumber

•

Example ip pim send-rp-announce ethernet0 scope 16 group-list 1 access-list 1 permit 239.0.0.0 0.255.255.255

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -441

Notes:

Silicon-IPTV-Broadcast -441

Assign the RP Mapping Agent •

The RP mapping agent is the router that sends the authoritative Discovery packets telling other routers which group-to-RP mapping to use. Such a role is necessary in the event of conflicts (such as overlapping group-toRP ranges)

•

Find a router whose connectivity is not likely to be interrupted and assign it the role of RP-mapping agent

•

All routers within ttl number of hops from the source router receive the Auto-RP Discovery messages

•

To assign the role of RP mapping agent in that router, use the following command in global configuration mode: — ip pim send-rp-discovery scope ttl

•

Verify the Group-to-RP Mapping using — show ip pim rp [group-name | group-address] [mapping]

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -442

Notes:

Silicon-IPTV-Broadcast -442

Prevent Join Messages to False RPs •

The addresses from which Auto-RP announcements are accepted can be limited

ip pim accept-rp default RP address 1 access-list 1 permit 224.0.1.39 access-list 1 permit 224.0.1.40

•

To filter incoming RP announcement messages, use the following command in global configuration mode: — ip pim rp-announce-filter rp-list access-list-number group-list access-listnumber

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -443

Notes:

Silicon-IPTV-Broadcast -443

Monitoring the Multicast Routing Table R99#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Candidate for MSDP Advertisement Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.255.250), 00:23:39/00:02:32, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Sparse, 00:23:39/00:02:25 Ethernet1, Forward/Sparse, 00:14:47/00:02:32 (*, 224.0.1.39), 00:21:35/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 00:21:35/00:02:23 Ethernet0, Forward/Sparse, 00:21:35/00:02:31 Ethernet1, Forward/Sparse, 00:14:47/00:02:29

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -444

This shows how to display the multicast routing table. Generally this will be quire long and stretch over many pages.

Notes:

Silicon-IPTV-Broadcast -444

Monitoring the Multicast Routing Table (*, 224.0.1.40), 00:24:03/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Sparse, 00:24:04/00:02:23 (*, 225.1.2.3), 00:01:36/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:29/00:02:26 (192.168.0.31, 225.1.2.3), 00:01:36/00:02:59, flags: CT Incoming interface: Ethernet0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:29/00:02:26

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -445

Here 192.168.0.31 is the source for the stream 225.1.2.3 which is arriving on interface Ethernet 0.

Notes:

Silicon-IPTV-Broadcast -445

Monitoring IGMP Groups

R99#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 239.255.255.250 Ethernet1 00:13:27 00:02:46 192.168.1.250 239.255.255.250 Ethernet0 00:22:19 00:02:44 192.168.0.18 224.0.1.39 Loopback0 00:20:15 never 10.1.1.1 224.0.1.39 Ethernet1 00:20:15 never 192.168.1.99 224.0.1.39 Ethernet0 00:20:15 never 192.168.0.99 224.0.1.40 Ethernet0 00:22:43 never 192.168.0.99 225.1.2.3 Ethernet1 00:00:07 00:02:53 192.168.1.250 R99#

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -446

“Show ip igmp groups” displays the groups that the router is a member of.

Notes:

Silicon-IPTV-Broadcast -446

RPF Failure •

Multicast packets are coming into e0/0 of 75a from a server whose ip address is 1.1.1.1 and sending to group 224.1.1.1. This is know as an (S,G) or (1.1.1.1, 224.1.1.1)

•

Problem: Hosts who are directly connected to R75a are getting the multicast feed. But hosts (HostA), who are directly connected to R72a, are not getting the stream R75a

R72a

Receiver A

Sender e0/0

e0/1

e3/1

e3/2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -447

Notes:

Silicon-IPTV-Broadcast -447

Look at what is going on in R75a ip22-R75a#sh ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 This is telling us that the multicast packets are being sourced from a server whose address is 1.1.1.1 which is sending to a multicast group of 224.1.1.1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -448

Since it's dense mode we can basically ignore the *,G entry and focus on the S,G entry. It's telling us that the multicast packets are being sourced from a server whose address is 1.1.1.1 which is sending to a multicast group of 224.1.1.1. The packets are coming in the ethernet0/0 interface and being forwarded out the ethernet 0/1 interface. This is perfect. So, since we know that packets are being forwarded out ethernet 0/1 to the LAN which R72a is connected, let's take a look at what R72a is doing with the packets.

Notes:

Silicon-IPTV-Broadcast -448

Look at what is going on in R72a ip22-R72a#sh ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:05:36/00:02:19, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:05:36/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:05:37/00:00:00

The necessary S,G (1.1.1.1, 224.1.1.1) is not even listed. Let's look to see if it's showing the upstream router (75a) as a pim neighbor:

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -449

The necessary S,G (1.1.1.1, 224.1.1.1) is not even listed. It's definitely not forwarding the packets. So what's going on. At least we found the trouble spot, now we'll have to probe deeper on this router. Let's look to see if it's showing the upstream router (R75a) as a pim neighbor:

Notes:

Silicon-IPTV-Broadcast -449

Examining the PIM Neighbors ip22-R72a#sh ip pim neigh PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 2.1.1.1 Ethernet3/1 2d00h 00:01:15 v2

It is showing the RPF Interface as e3/3 but ip22-R72a#sh ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) we expect it to be e3/1 RPF interface: Ethernet3/3 RPF neighbor: ? (4.1.1.2) RPF route/mask: 1.1.1.1/32 RPF type: unicast (static) RPF recursion count: 1 Doing distance-preferred lookups across tables

R75a

R72a

Receiver A

Sender e0/0

e0/1

e3/1

e3/2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -450

It's showing the rpf interface being e3/3 but it should be e 3/1 as the incoming interface. Let's further confirm with some debug, although we'll need to be careful with this as it will be busy:

Notes:

Silicon-IPTV-Broadcast -450

Confirm The Problem With Debug and Solve

ip22-R72a#debug ip mpacket *Jan 14 09:45:32.972: IP: s=1.1.1.1 *Jan 14 09:45:33.020: IP: s=1.1.1.1 *Jan 14 09:45:33.072: IP: s=1.1.1.1 *Jan 14 09:45:33.120: IP: s=1.1.1.1

(Ethernet3/1) (Ethernet3/1) (Ethernet3/1) (Ethernet3/1)

d=224.2.127.254 d=224.2.127.254 d=224.2.127.254 d=224.2.127.254

len len len len

60, 60, 60, 60,

not not not not

RPF RPF RPF RPF

interface interface interface interface

Add a static rout to solve the problem

ip22-R72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -451

Sure enough, The packets are coming in on ethernet3/1 as we want but they are being dropped because that's not the interface the unicast routing table is using for rpf check. We can either change the unicast routing to satisfy this requirement or we can add a static mroute to force multicast to RPF out a particular interface regardless of what the unicast routing table states. We'll add a static mroute: ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1 This static multicast route states that to get to the address 1.1.1.1, for rpf, use 2.1.1.1 as the next hop to get there, which is out e3/1.

Notes:

Silicon-IPTV-Broadcast -451

Confirm The Solution ip22-R72a#sh ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet3/1 RPF neighbor: ? (2.1.1.1) RPF route/mask: 1.1.1.1/32 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -452

Notes:

Silicon-IPTV-Broadcast -452

Confirm The Solution ip22-R72a#sh ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 2.1.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00

ip22-R72a#debug ip mpacket *Jan 14 10:18:29.951: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -453

The real confirmation of the solution is that host A now gets packets.

Notes:

Silicon-IPTV-Broadcast -453

Time To Live

RouterA

RouterB

Receiver R

Sender S 1.1.1.1

e0/0 1.1.1.2

e0/1 2.1.1.1

e1/1 2.1.1.2

e1/2 3.1.1.1

3.1.1.2

Problem: RouterA is not forwarding packets from source(S) to RouterB's directly connected receiver(R) sending to: 224.1.1.1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -454

Troubleshooting: Let's first look at 'sh ip mroute' on ROUTERA to see the multicast routing state:

Notes:

Silicon-IPTV-Broadcast -454

Look at RouterA MROUTE ROUTERA#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00

The Source 1.1.1.1 is not being recognised

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -455

We can ignore the 224.0.1.40 since all routers will join this Auto-RP Discovery group. But we don't have a source listed for 224.1.1.1. In addition to "*, 224.1.1.1" we should be seeing "1.1.1.1, 224.1.1.1". We don't recognize the source as being valid for some reason. Let's see if it's an RPF issue:

Notes:

Silicon-IPTV-Broadcast -455

Check the RPF ROUTERA#sh ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 1.1.1.0/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables

The RPF looks right as it is correctly pointing to e0/0

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -456

The rpf check is correctly pointing out e0/0 to get to the source's ip address. Let's see if pim is configured on the interfaces:

Notes:

Silicon-IPTV-Broadcast -456

Check the Interfaces and the Traffic ROUTERA#sh ip pim int Address Interface Version/Mode Nbr Query DR Count Intvl 1.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 1.1.1.2 2.1.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 2.1.1.2 ROUTERA#sh ip mroute active Active IP Multicast Sources - sending >= 4 kbps

The router does not see any traffic as no sources listed. You could check this with:

ROUTERA#debug ip mpacket

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -457

Perhaps the Receiver is not sending any igmp reports (joins) for group 224.1.1.1: Check this with Debug or igmp group.

Notes:

Silicon-IPTV-Broadcast -457

IGMP Group

ROUTERB#sh ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 2.1.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 3.1.1.2

3.1.1.2 has joined the group so it can only be a TTL issue if traffic is actually being sent

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -458

224.1.1.1 has been joined on e1/2 so that's fine. Perhaps ROUTERB is not sending PIM JOINS to ROUTERA informing ROUTERA that it needs to forward the traffic: Actually, ROUTERB is not going to send pim joins to ROUTERA. Dense Mode is a flood and prune protocol, so there are no joins, but there are grafts. But since ROUTERB hasn't received any flood from RouterA, it doesn't know where to send a graft. Perhaps it's a TTL (Time to Live) issue:

Notes:

Silicon-IPTV-Broadcast -458

Show IP Traffic ROUTERA#sh ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options Indication of the problem is the 63744 bad hop count Repeating the show will indicate that this is increasing

To fix this the source must increase the TTL of the multicast traffic

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -459

63744 bad hop counts, and each time I type this command, the bad hop counts increase. This is the TTL incrementing. We have found the problem. To solve the issue we need to increase the TTL on our Sender application.

Notes:

Silicon-IPTV-Broadcast -459

The Fixed TTL - RouterA ROUTERA#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (1.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -460

Notes:

Silicon-IPTV-Broadcast -460

The Fixed TTL - RouterA ROUTERB#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -461

Notes:

Silicon-IPTV-Broadcast -461

TTL Threashold

75a Receiver A

Sender 1.1.1.1

e0/0 1.1.1.2

e0/1 2.1.1.1

2.1.1.2

Problem: The sender is sending to 224.1.1.1 but receiver is not getting the multicast packets from the source

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -462

Troubleshooting: There may be several routers between the source and the 75a router, but let's first take a look at the 75a since it's directly connected to the receiver:

Notes:

Silicon-IPTV-Broadcast -462

The router is Forwarding Packets ip22-75a#sh ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -463

This is showing that 75a router is indeed forwarding the packets out ethernet0/1 so there is no need to work our way back towards the source. So, why isn't the receiver getting the packets? Perhaps the receiver is messed up. That would be the obvious conclusion. What more can the router do than to forward the packets? But the customer is saying they put an analyzer on the line and they don't see any multicast packets. So we point the finger at the PC and they point the finger at the router. We better ensure the router is forwarding the packets, just to give further ammo to the customer to take to his pc application vendor. We'll turn on debug just for this source and multicast group to help keep the chatter down a bit:

Notes:

Silicon-IPTV-Broadcast -463

Turn On Debug For The Service ip22-75a#conf t Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 1.1.1.1 host 224.1.1.1 ip22-75a(config)#end

Limit traffic to just the service required ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

Traffic is limited by the TTL threshold

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -464

The router is not forwarding the packets because of a threshold being denied. We better look in the config and find out what this is all about.

Notes:

Silicon-IPTV-Broadcast -464

Examine the Interface Configuration interface Ethernet0/1 ip address 2.1.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15 This interface will only forward traffic with a TTL greater than 15 Often people think the threshold prevent traffic with a greater value being sent The reverse is true. Reduce the threshold or delete the line to fix the problem.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -465

The customer configured a ttl threshold of 15, thinking that anything greater than a ttl of 15 will not be sent. Actually, just the opposite is configured. The application is being sent with a ttl of 15. By the time it gets to the 75a router, the multicast packets have a ttl less than 15. We better look at Multicast-Commands, and see what is going on: [no] ip multicast ttl-threshold Configures a packet TTL threshold for traffic going out the interface. Any multicast packets with a TTL less than the threshold are not forwarded out the interface. The default value is 0 which means all multicast packets are forwarded out interface. So any packets with a ttl LESS than the threshold are not forwarded. This command is usually used to provide a border to keep internal multicast traffic from drifting out of the intranet. Resolution: Either remove this command (and use 'ip pim border' instead) or lower the ttl threshold so that the traffic can pass.

Notes:

Silicon-IPTV-Broadcast -465

Multicasting and Stream Delivery

Multicast Concepts Multicast Addressing IGMP PIM Sparse Mode Configuration Analysis of Multicast Exchanges Troubleshooting Multicast Problems Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -466

Notes:

Silicon-IPTV-Broadcast -466

Chapter 8

Managing Devices with SNMP

Notes:

Silicon-IPTV-Broadcast -467

Chapter Objectives In this chapter, we will • Examine the way in which Network Management stations communicate with managed devices • Identify the structure of SNMP for management • Detail the component parts of SNMP management

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -468

Notes:

Silicon-IPTV-Broadcast -468

Managing Devices with SNMP Network Management Concepts

Management Information Base (MIB)

SNMP

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -469

Notes:

Silicon-IPTV-Broadcast -469

Modern Networks • Modern networks are complex and diverse

Router

server

Router

Router

Server

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -470

Networks tend to evolve over time. This means that there can be many different generations of technology present at the same time. A management system that can cope with only the latest technologies is therefore not the best solution in practice. Management systems must be capable of coping with multi-vendor and multitechnology infrastructures. Also service Level Management demands that all components and servers be manageable in order to be able to deliver the required level of quality and performance.

Notes:

Silicon-IPTV-Broadcast -470

OSI Model • ISO 7498 and ITU-T X.200

Application and its Services Converts bits to Objects

Application Presentation

Checkpoints and Activities

Session

End to End Error Recovery

Transport

Routing

Network

Detects Errors

Data Link

Moves Bits

Physical

7

• Provides application services

6

• Provides data representation

5

• Provides checkpointing, activity management

4

• Provides end-to-end data integrity

3

• Routes and relays

2

• Manages communication between adjacent nodes

1

• Transmits bit stream over physical medium

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -471

Finally layer 7 is where the application and all the other functions run. Indeed you the user are in layer 7 too. Layer 7 is also where the major parts of all applications sit. This might be database, Email, Multimedia Web services, E-commerce, indeed all the publicly recognized parts of computer and IT services. In general where there is any form of human interface, layer 7 services are providing it. Naturally network and services management have human interfaces so they too are largely positioned within layer 7. However unlike other user interfaces they need direct contact with lower layers in order to obtain the information needed to manage.

Notes:

Silicon-IPTV-Broadcast -471

Location of Network Management • Network Management is a Layer 7 function — Devices that do not have a full protocol stack must be enhanced

Application Presentation Session Transport

M

M

Application

Application

Presentation

M

Presentation

Session

Session

Transport

Transport

Network

Network

Network

Data Link

Data Link

Data Link

Physical

Physical

Physical

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -472

We must ask ourselves how can layer 7 obtain information about lower layers, layer 1 say. It could ask layer 6 to ask layer 5 to ask layer 4 to ask layer 3 to ask layer 2 to ask layer 1 “How are you layer 1”. Layer 1 could then reply to layer 2 that replies to layer 3 that replies to layer 4 that replies to layer 5 that replies to layer 6 that replies to layer 7 “I am fine!”. But if layer 7 is to monitor all layers for faults and try to correct them, could it trust the reply. A fault or failure in a middle layer could prevent layer 1 replies, or worse, change them. For layer 7 to reliably monitor and control it must obtain its information, as far as it can, from sources independent of the layers between. It therefore must communicate, at least for part of the time, with lower layer management entities using services independent of the main communications pathways. Also how can a device manage intermediate systems such as routers?

Notes:

Silicon-IPTV-Broadcast -472

Location of Network Management • Network Management is a Layer 7 function — Devices that do not have a full protocol stack must be enhanced

Application Presentation Session Transport

M

M

Application

Application

Presentation

M

Presentation

Session

Session

Transport

Transport

Network

Network

Network

Data Link

Data Link

Data Link

Physical

Physical

Physical

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -473

Additional services must be added to the router to provide the layers that are missing in order for the layer 7 management functions at least to communicate. In the case of SNMP this implies the addition of UDP and SNMP itself. A normal router will require UDP in any case for it to communicate with other application services including BOOTP and some routing protocols needed to undertake the normal router functions. However the instrumentation, usually special software, that provides the management services with management information and allows changes to be made in control tables within the router must be added. These are the elements found in the Agent services.

Notes:

Silicon-IPTV-Broadcast -473

Evolution of SNMP SNMP

SNMPv1 MIB-2

Recommended status

CMOT

HEMS

SGM P

1986

1987

More than 30 vendors demonstrate SNMP products at Interop

1989

RMON MIB

SNMPv2

SMI MIB-1 “standard protocols”

1990

SNMPv3

Fundamental flaws found and SNMPv2 largely abandoned

1991

1992

1993

1998

• Official internet standard is still SNMPv1 — Security limitations caused development of v2 and v3 — SNMP v3 has upen ended security model but complex to use — Management needed when network fails to function

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -474

The evolution of SNMP started in the middle 1980s when the Internet was beginning to become established and routing table errors could cause parts of the network to become unreachable. Highlevel Entity Management System (HEMS) was a monolithic process run typically within the UNIX systems that formed the main notes of the network, what are today called routers. While this proved to be useful it was not easily portable across platforms so Simple Gateway Monitoring Process (SGMP) was built which defined the protocol interacts between systems independently of the underlying platform. This was however still large and relatively complex, too complex to implement within a simple agent in a low level device. At about the same time, the end of the 1980s, OSI was under extensive standardization development. The OSI model had been agreed in 1982 and the form of the major layer 3 to 5 protocols were fixed. However the management protocols were still incomplete and extensive standardization work remained. The Internet community therefore decided that as one day OSI would replace TCP/IP, it would be silly to develop a different management approach only later to need to replace it. Better to assist in the OSI standardization and adopt compatible techniques, at least for management data access. By 1989 it was clear that it would be many years before the OSI Common Management Information Protocol (CMIP) would be complete, and that the direction being taken would yield a large complex protocol. It was therefore decided to build an interim simple protocol able to access the same data structures. This was SNMP, or what is now known as SNMPv1.

Notes:

Silicon-IPTV-Broadcast -474

SNMP Structure • Management application is user provided • An Agent runs on every managed platform • Management communications is provided by SNMP

Data

Management application

SNMP

UDP/IP

Agent

UDP/IP

Network

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -475

A management application is typically a Windows Icon Menu Pointer Graphical User Interface (WIMP-GUI) Application. It sits on top of UDP and IP sending and receiving SNMP exchanges with many agents across the network. Every device that is to be managed must have an agent to communicate with the management application in order to implement the management service. The exchange of data depends upon both manager and agent understanding the details and meaning of the Management variable in use. In practice these sit within the agent device, usually as values held in random access memory. The management application on the other hand must hold details of which variables are understood by which devices in the network so must hold more details on backing storage.

Notes:

Silicon-IPTV-Broadcast -475

SNMP within Internet Protocol Suite • SNMP runs over UDP

IPS Layer

Application

End-to-end

OSI Layer

SMTP Simple Mail Transfer Protocol

FTP TELNET virtual terminal

File Transfer Protocol

Transmission Control Protocol (TCP)

5, 6, 7 User Datagram Protocol (UDP)

4

Internet Protocol (IP)

ICMP

Internetwork

SNMP

3 ARP Physical network

Etc.

Packet radio

X.25

IEEE 802 LAN

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

2,1

Silicon-IPTV-Broadcast -476

SNMP is one of more than a hundred protocols within the Internet Protocol Suite (IPS). Often this is called TCP/IP. IP is the layer 3 protocol that undertakes routing and the delivery of data to the correct destination. IP does not guarantee reliable delivery however, it is a best efforts or datagram protocol. In most userbase applications reliable transmission is provided above IP by using Transmission Control protocol (TCP) which sequences data to keep it in order and retransmits data that is corrupted or lost. SNMP uses User Datagram Protocol which is a much simpler protocol than TCP. It can be configured to detect transmission errors and discard transfers that are corrupted by using a checksum similar to TCP. But unlike TCP it does not sequence data nor undertake retransmissions. In the event of an error in any part of the layers 1, 2 or 3 data may be lost. UDP is often termed unreliable.

Notes:

Silicon-IPTV-Broadcast -476

Why over UDP? • UDP is unreliable — don’t we want reliable management? • . . . Yes of course but • When do you need network management most? • . . . and will the network deliver data reliably then? • If we place SNMP above TCP it cannot see the flaws in the network — We need to see the network as it is in order to manage it — TCP would correct errors or crash! — The network would appear perfect or broken beyond repair • If we are not managing the network then we can use TCP — Managing end system components can be done over TCP

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -477

At first it seems strange that we should select UDP rather than TCP to carry SNMP management data. After all surely we want reliable management. However when there is a fault in the network there is little chance that all the data will arrive correctly and a protocol like TCP might never succeed in delivering a correct version of every piece of data. It might then just abandon the transmission as “broken”. Under failing conditions the management application would find it difficult to discover exactly what the failure is if no data arrives. Some faults will be completely hidden by TCP. How for example can you detect that a network is delivering data packets out of order if TCP reorders them? Indeed with TCP sitting below SNMP all networks seem either perfect or so broken that no communication is possible. The only time that TCP would offer better service would be if the management communication with the device being managed was over a different network to the network being controlled. This is known as “out-of-band” management. In reality this is often the case with telecommunications. It does however pose another question: how do you manage the management network? After all if management is important to the mission then clearly the management network must be highly reliable and management of this will be vital. This “Metamanagement” as it is known must itself then run over yet another network or must run over some kind of datagram protocol.

Notes:

Silicon-IPTV-Broadcast -477

Management Framework • Data originally defined in “two standards” — Structure of Management Information (SMI) (RFC 1155) — Management information base (MIB) (RFC 1156 replaced by 1213) — Extensive extension for different technologies, 100+s standard MIBs • Data access originally defined in SNMP protocol — SNMP defines simple protocol for transferring data (RFC 1157) • These have been modified/extended by subsequent RFCs

Networkmanagement database

Management information base (MIB)

Networkmanagement application Management workstation

Agent SNMP protocol

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -478

The framework for management data was originally defined within two standards:The structure of Management Information (RFC 1155) and the Management Information Base (RFC 1156 which was replaced by RFC 1213). While later standards have added considerably to the protocol and the SMI the documents are more difficult to read and understand. When learning about SNMP it is generally best to start from SMIv1 and then extend this knowledge to the superset formed by SMIv2. We shall do this here. Also the development of SNMPv3 has provided substantially greater security features but the documents describing the protocol are much easier to read and understand when the concepts of SNMPv1 have been mastered. We shall first concentrate on understanding SMIv1 and the MIB defined by RFC 1213 which is the minimum subset supported by all real devices. Later we will examine some of the extensions in SNMPv3 and SMIv2.

Notes:

Silicon-IPTV-Broadcast -478

Managing Devices with SNMP Network Management Concepts

Management Information Base (MIB)

SNMP

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -479

Notes:

Silicon-IPTV-Broadcast -479

SNMP MIBs use a managed Namespace Paul’s machine is working fine!

Paul

George Ringo

What did Ringo call that parameter?

Paul Peter

Mary

• Need unambiguous names © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -480

The MIB forms a managed namespace. We need this namespace to be infinitely expandable and allow different parts of its coverage to be controlled by many different authorities. While it is not a simple problem to solve, the MIB is no different to the allocation of names for domains or email addresses. In much the same way we use a tree structure so that names can be made unambiguous.

Notes:

Silicon-IPTV-Broadcast -480

ISO - CCITT Managed Namespace

0 standards

ccitt

1

iso

2

0

1

2

3

0

1

2

3

joint-ccitt-iso org (identified organizations)

1.3.6.1 internet 1.3.6.1.1 directory 1.3.6.1.2 mgmt

1

4

5

dod

6

internet

1.3.6.1.3 experimental 1.3.6.1.4 private

1

2

mgmt

1.3.6.1.5 security 1.3.6.1.6 SNMPv2

1

mib-2

3

4

5

8

private Added after RFC 1213

1.3.6.1.7 mail 1.3.6.1.8 features

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -481

The tree starts from an unnamed root node and is controlled by two standards organizations - ISO and the ITU-T (formerly known as the CCITT). Nodes within the tree are given both names and numbers and can be referred to using either. By convention the names are written using lower case and are case sensitive. The early MIBs such as RFC 1213 tend to include some cryptically coded names. “mgmt” for management and “org” for “identified organizations”. More recently added MIB extensions have taken a different direction. Multi-word names are used but are encoded starting in lower case and then concatenating words together without spaces but capitalizing the first letter of each new word.At the highest level there are nodes controlled by CCITT, by ISO and jointly controlled by both. ISO have delegated responsibility for part of its number space to other organizations and these are grouped under one node, node 3 “org”. All internet variables therefore start 1.3 or iso.org. The 6th organization is the US Department of Defense (DOD) so all nodes are under iso.org.dod (1.3.6). The DOD have delegated everything to the Internet community so all variables start iso.org.dod.internet (1.3.6.1).

Notes:

Silicon-IPTV-Broadcast -481

Private Extensions

1

1

Internet

2

Directory

3

Management

MIB

4

Experimental

1

18

20

PPP

RS-232

11

SNMP 10 8

1 System Interfaces

7

2

6 3 AT

5 4

ICMP

Private

TCP

UDP

Transmission

1

Enterprises

EGP

2 IBM

36

9

161

DEC

Cisco

Motorola

11911

Motorola

IP

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -482

Notes:

Silicon-IPTV-Broadcast -482

Branches Under Internet (1.3.6.1) in RFC 1213 • Directory (1) — Reserved for use with the OSI directory (X.500) and White Pages — Not used by SNMP • Management (2) — Objects defined in IAB-approved documents — Currently has only one entry: the SNMP MIB-2 • Experimental (3) — Objects used in Internet experiments — “Successes” migrate to mgmt(2) — Use of this branch is deprecated • Private (4) — Objects defined unilaterally — Currently has only one entry: enterprise(1) — Allows manufacturers to support capabilities not in mgmt(2)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -483

Under the internet node (1.3.6.1) RFC 1213 placed four branches. Directory node 1, which is reserved for OSI X.500 management. So far this has not been widely used. Management node 2, known as “mgmt” in RFC1213 which hold MIB-2 and all its standard extensions. Experimental node 3, which can be used during development in order to test the functioning of new features and variables without impacting operational services. Private node 4 which has a single sub node “enterprise” under which each organization that wishes to register can obtain its own node. There are now more than 12,000 registered enterprises each of which could have their own MIB variables.

Notes:

Silicon-IPTV-Broadcast -483

Later Extensions • Security (5) — Development of objects still continues for confidentiality and integrity services and mechanisims — Includes: Kerberose, MD5-DES-CBS, IPSEC and other integrity mechanisms • SNMPv2 (6) – Mechanisms developed to manage the “party MIB” used for SNMPv2 security – No longer used • Mail (7) — RFC 1495 mail management • Features (8) — Media-feature-tags RFC 2506 — Includes feasures such as pixels, DPI, color, image-coding etc

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -484

Considerable development work is currently being undertaken to develop MIBs that can be used to manage security features. Currently few of these have reached completed RFCs but are being placed under node 5. Node 6 defines SNMPv2 features. However SNMPv2 has been obsoleted by work on SNMPv3. Parts of this group can still be used to control proxy management and community naming. Node 7 is for Mail Management and RFC 1495 defines variables here. Node 8 is used for media management and details of RFCs that define variable here can be found at http://www.iana.org/assignments/media-feature-tags .

Notes:

Silicon-IPTV-Broadcast -484

Management Information Base • Data is held in a database called the MIB • Database is split into a number of management groups (areas) • MIB-1 holds data for eight managed areas - RFC 1156 — Total of 114 object definitions • MIB-2 definition RFC 1213 — Added two new categories — Improved support for multi-protocol devices — About 50 percent larger (171 object definitions)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -485

Now let us turn our attention to the standard subset of variable all devices that use IP should support, RFC 1213 MIB-2. All of the variable in MIB-1 appear in MIB-2 with some additions and improvements added.

Notes:

Silicon-IPTV-Broadcast -485

MIB-2 Variable Groups • Group — system — interfaces — at — ip — icmp — tcp — udp — egp — transmission — snmp —

Description Number of MIB variables The managed node 7 Network attachments 23 IP address translation 3 Internet Protocol 38 Internet Control Message Protocol 26 Transmission Control Protocol 19 User Datagram Protocol 7 Exterior Gateway Protocol 18 Physical interface Simple Network Management Protocol 30 Total: 171

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -486

Details of these groups are given in Appendix B. The system group is used to define the names and contacts for the managed device. It also contains sysUpTime which identifies the time since the device last rebooted in 0.01 sec units. The interfaces group includes variables that refer to layer 1 and layer 2 functions of device interfaces. The at group holds the ARP table in MIB-1but this was moved to the ip group to a table called the ipNetToMediaTable in MIB-2. The ip group includes all the details about ip addresses, routing and statistics information. The icmp group holds input and output counters for icmp messages which carry ping (echo), redirects, host unreachable and time exceeded messages among others. The tcp group holds counters for tcp transfers as well as a table giving details of current tcp connections open. The udp group holds counters of input and output udp transfers. The egp group holds details of exterior gateways status; this gives information about the direct connection to the Internet. The transmission group does not contain variables in RFC 1213 but is used to hold extensions in other RFCs that detail technology specific layer 1 information.

Notes:

Silicon-IPTV-Broadcast -486

MIB-1 and MIB-2 Groups 1.3.6.1.2.

1

1

3

5

7

system

at

icmp

udp

MIB-2

10

14

17

ospf

transmission

etc.

bridge . . . etc. . .

2

4

6

8

11

16

interfaces

ip

tcp

egp

snmp

rmon

MIB-1 RFC 1156 MIB-2 RFC-1213

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -487

Notice that MIB-2 adds the transmission and snmp groups as nodes 10 and 11. Node 9 was reserved for CMOT but has never been implemented in any RFC. Extensions for routing protocols, bridges, host services and the like normally extend beyond node 11.

Notes:

Silicon-IPTV-Broadcast -487

Structure of Management Information (SMI) • Defined by RFC 1155 (Structure of Management Information) — Expanded by RFC 1212 (Concise MIB Definitions) for MIB-2 — Further expanded by RFC 1451 (SMI for SNMPv2) — RFC 2578 SMIv2 • Defines all properties of the MIB object — Syntax for the object type — Access allowed for the object (read only, read-write, write only, or not accessible) — Status of the object (mandatory, optional, deprecated, or obsolete) — Textual description, cross-references, and default value are optional — Indexes used for lookup if a table-oriented object • MIB data defined using ASN.1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -488

Originally it was defined in RFC1155 and later expanded in RFC 1451 for SMIv2. The latest version of SMIv2 is documented in RFC 2578. There are fundamental differences between SMIv1 and SMIv2. Many products still have their MIBs documented in SMIv1 and it would be possible to document most MIBs using SMIv1 if required. SMIv2 adds some macro definitions as well as mechanisms for better documentation of notifications (Traps) and other services. Most recently developed MIBs use SMIv2 but not all management products yet support it.

Notes:

Silicon-IPTV-Broadcast -488

Abstract Syntax Notation number 1 (ASN.1) • Formal language developed and standardized by CCITT* (X.208) and ISO (ISO 8824) — Encoding rules in X.209 • Main uses: — Used to define application data independent of hardware or software — Used to define the structure of application and protocol data units — Used to define the management information base for SNMP — Used to encode the data and PDUs in SNMP • Complex syntax rather like a programming language • Possible to define MIB and compile into working manager for access • Originally used for definition of OSI protocols

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -489

Abstract Syntax Notation number 1is used to document all MIBs. This is a complex syntax rather like a programming language that can be used for documenting data structures and protocol data units. It was originally built so that protocols could be documented in a syntax that was independent of any programming language that might be used to develop implementations. The syntax is generally easy for programmers to learn but can prove difficult for people having no previous programming experience. Also syntax errors in standard MIBs are not unknown so just because a MIB exists in an RFC does not mean that it will compile without errors if submitted to a compiler.

Notes:

Silicon-IPTV-Broadcast -489

Defining Data • MIB-2 objects are defined using a subset of OSI ASN.1 types — Uses types that are directly and easily applicable to management data • UNIVERSAL class types — Integer (UNIVERSAL 2) — Octet string (UNIVERSAL 4) — Null (UNIVERSAL 5) — Object identifier (UNIVERSAL 6) — Sequence or sequence of (UNIVERSAL 16) — Enumerations of integer (UNIVERSAL 10) – Must exclude value 0

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -490

Only a subset of the OSI ASN.1 data definitions are used by SMI. Largely this is because the selected subset is enough to represent all real data implementations and the functions of those parts omitted can be achieved in some other perhaps easier way or are not in themselves practical. The major data items are defined using UNIVERSAL classes.

Notes:

Silicon-IPTV-Broadcast -490

Defining Data • Application-defined data types for SNMPv1 — IPAddress: four octets in “dotted” order — Counter: Can be incremented but not decremented, ranges from 0 to 232 – 1 and wrapping around to 0 — Gauge: Can be increased or decreased, ranges from 0 to 232 – 1 and does not wrap — TimeTicks: Non-negative integer representing the time in hundredths of a second since some “epoch” • SMIv2 renames Counter and Gauge renamed Counter32 and Gauge32 — SNMPv1 Universal INTEGER restricted to 32 bits, SMIv2 adds — NsapAddress: OSI NSAP address encoding — Counter64: For counters that could wrap in less than one hour with only 32 bits — UInteger32: For integers ranging from 0 to 4294967295

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -491

In addition to the UNIVERSAL classes a number of application defined data types are used. These data types are specific to IP and SNMP. An IP address is in practice a 32 bit field but it is always written as 4 decimal numbers separated by dots. SMI introduces a data type that is always presented in dotted decimal form with leading spaces removed. A counter can be used for counting things. It is different to an integer in that its size is fixed (32 bits) and when it reaches the maximum value held in 32 bits it wraps back to zero. The advantage of this is that provided a manager looks at a variable that is held as a counter often enough it can deduce when the wrapping has occurred and compensate by adding 232 to the value read. Also there is no need to reset counters. By reading their current value and storing this, the increase in a counter can be deduced by retrieving a later value and subtracting the stored initial number.

Notes:

Silicon-IPTV-Broadcast -491

Example Variables

MIB variables

Meaning

type

sysUpTime system ifMtu interfaces ifAdminStatus interfaces ipDefaultTTL ip icmpInRedirects icmp tcpMaxConn tcp udpOutDatagrams udp scalar

Group

Time since last reboot MTU size up/down Default TTL value used ICMP redirects seen Max. connection allowed Datagrams sent

scalar scalar scalar scalar scalar scalar

ipNetToMediaTable ipRouteTable

ARP table IP routing table

table table

ip ip

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -492

Notes:

Silicon-IPTV-Broadcast -492

Managing Devices with SNMP Network Management Concepts

Management Information Base (MIB)

SNMP

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -493

Notes:

Silicon-IPTV-Broadcast -493

SNMP Protocol Structure • Based on UDP over IP — Stateless data transfer — Simple to operate and implement — No dependence on virtual circuits — Makes NMS location independent – Can be anywhere on an internetwork • Major drawbacks — Security less easy to provide than with TCP – Overcome in SNMPv3 or by adding SSL — Network management reliant on transport – Which may be failing — No acknowledgements of data receipt

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -494

Because SNMP runs above UDP it cannot assume previous interactions will arrive in sequence so each transfer needs to be stateless. Reading individual objects is straight forward as a request will identify exactly the object to be read. However to read a table that is of unknown length and with unknown content requires stepping through the table row by row, remembering each row read and reading the next. Stateless systems are relatively simple to build but require operations to be small and self contained. Also maintaining security is not easy to achieve.

Notes:

Silicon-IPTV-Broadcast -494

SNMP the Protocol • SNMP Architecture includes the protocol, SMI and MIBs • SNMP the protocol is the set of rules for reading and changing data

SNMP manager UDP

SNMP messages (PDUs)

SNMP managed system

t rap

set

get_response

get_next

SNMP object manipulation

t rap

get_response

set

get_next

get

Management application

Managed resources SNMP managed objects

get

SNMP manager

SNMP agent UDP SNMP device

IP

IP

Link Layer

Link Layer

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -495

SNMPv1 has a relatively simple structure in that a management application can send any one of three messages to an agent and receive a get-response in reply. Also an agent can sent a uni-directional trap to the manager which is unacknowledged.

Notes:

Silicon-IPTV-Broadcast -495

SNMP Messages • SNMP uses a simple fetch–store protocol — get command to fetch a value — set command to store a value — Operations accomplished as side effects of these commands • There are no commands such as reboot • It is often called a remote debugging paradigm

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -496

SNMP is often said to have a “remote debugging paradigm”. By this is meant that the manager can fetch and store data values and observe the responses in much the same manner that a programmer debugs a program but does this potentially at least remotely. SNMP has no action messages such as that found in OSI CMIP. The reason for this is that we wish SNMP to be very general and function across a wide range of machines. Implementing an action requires service functions that just may not be available on some low level devices. If we wish to achieve an “action” effect then we must implement within the agent a function that undertakes the action when a variable in the MIB is changed in some manner. There are some MIBs that have such features, particularly within private MIBs.

Notes:

Silicon-IPTV-Broadcast -496

SNMP Actions • SNMP defines four actions that can be performed on data — Get Used to retrieve management data — Get-next Used to retrieve lists and tables of management data — Set Used to manipulate management information — Trap Used by agent to report extraordinary events • SNMP makes things happen in agent by setting an “action” variable

Management system

Get / get - next / set Agent

Tr ap/ r esponse

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -497

ANMPv1 has 4 actions. The first three are invoked by the manager and the fourth by the agent. A “get” will retrieve one or more instances of individual variables. A list of object identifiers is included in the get request and the get response includes the object identifiers together with their retrieved values. The number of identifiers included must be selected so that the response can fit within the limits of the maximum packet size supported in both agent and manager. When building agent devices it is often necessary to implement the code so that the response fits within 576 bytes - the smallest maximum transmission unit size supported within IP. This avoids the need for the response to be fragmented with the potential for fragments to get lost in a failing network.

Notes:

Silicon-IPTV-Broadcast -497

SNMP Mechanism • Data is encoded (serialized) using ASN.1 — ASN.1 Basic Encoding Rules (BER) — Gets around variations in machine architecture • Simple (trivial) authentication mechanism in use — Uses “community” name to define access rights – Very limited and easily bypassed — Replaced by Secure SNMP – Not a problem with SNMPv2 and SNMPv3 • Reliant on polling agents at regular intervals — Inefficient • Most agents trap on limited set of major events — Manager follows up trap with poll

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -498

The data fields and the SNMP protocol data units themselves are encoded using the ASN.1 basic encoding rules which are machine and language independent. SNMPv1 has very limited security. Each transfer includes a community name which the agent checks for validity and can be used to control the level of access. However because this value is carried in clear text it can relatively easily be discovered using a protocol analyzer and so is not considered secure. SNMPv3 overcomes this problem by using optionally both cryptographic authentication and encryption. Normally an agent process within a managed device would inform the management application if links failed or some other critical event occurred using a trap transfer. However since the underlying network is datagram (UDP/IP) such a trap is not sure to arrive. To overcome this and ensure that the management application can become aware of a managed device failing, the management application cannot be passive and just wait for a trap transfer to report a failure. It must from time to time send a get-request for an object that it is sure the device supports so that it can verify that the device is still operational. This is known as polling.

Notes:

Silicon-IPTV-Broadcast -498

Security • Authentication — Only authorized managers can adjust critical parameters — Masqueraders cannot probe for sensitive information • Privacy — Prevent unauthorized snooping by eavesdroppers on a LAN • SNMPv1 support limited to trivial authentication • SNMPv1 uses “community name” as only authentication — Sent in the clear with each SNMP PDU — This is sometime referred to a kidding yourself security — Defaults to “public”

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -499

As the community name used in the security is easily visible with a protocol analyzer it is generally recognized that SNMPv1 is not in itself secure enough for use on an open LAN where stations may readily read other users data. This is clearly not secure and so it is generally referred to as “kidding yourself security” as if you think it is secure you are indeed kidding yourself. By convention if you do not mind other users retrieving SNMP data from your device then allow access with the default community name “public”. Often this is the default community name used by vendors when SNMP is implemented initially within one of their products. Because this is well known it is critical that this value is changed as soon as possible when security is important.

Notes:

Silicon-IPTV-Broadcast -499

SNMPv2 and SNMPv3 Security • SNMPv2 added optional encryption and MD5 authentication — Keys could be different between each manager/agent pair — Keys could also include clocks from the two devices — In effect the key changed with each clock tick — So secure that under fault conditions it was possible to loose contact • SNMPv3 adds variable security model — Can be configured with users own authentication and encryption if required — Standard models defined too — Mechanism for aligning times and after reboot to overcome problems with SNMPv2 — New branch of the MIB used to manage security snmpUsmMIB

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -500

SNMPv2 added MD5 authentication and DES encryption. It also allowed the value of the system clock in both agent and manager to be included within the calculation of MD5 encoded values. The impact of this is in effect to change the effective key each time the clock ticks (100 times a second). This was found to be impractical in most real cases as the delay across the network was variable and often its variation well exceeded the resolution of the system clocks (0.01 sec) SNMPv3 allows a user defined security model to be used if needed so it can be made as secure as required.

Notes:

Silicon-IPTV-Broadcast -500

Error Reporting • SNMPv1 is “all or nothing” — Each PDU is treated as an atomic operation — Any syntax errors cause the operation to be aborted • SNMPv2 and SNMPv3 are more forgiving — Other mechanisms for access to tables — The impact of errors is limited to the smallest scope possible

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -501

If a management device makes a request of the agent using a message containing an error, the whole transaction is ignored. This can become a source of frustration with SNMPv1 so in SNMPv3 get-requests for objects that are correct even when some part of the message was in error will still be actioned. Error reports indicate the reason for the error and a pointer points to the incorrect syntax in the message reply

Notes:

Silicon-IPTV-Broadcast -501

SNMPv1 Functions Manager

• Get — Get-request — Get-response • Get-next — Get-next-request — Get-response • Set — Set-request — Get-response • Trap — Trap

Agent

G et R

GetR

eques

Manager

GetNe xtReq uest P DU

t PDU

se PD espon

U

se espon GetR

(a) Get values

Manager S et R

Agent eques

PDU

(b) Get-next values

Manager

Agent DU Trap P

t PDU

se PD espon GetR

Agent

U

(c) Set values

(d) Send trap

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -502

Get-request, getNext-Request and set-request all start from the management application and each have the same response — a get-response. In SNMPv3 this is retitled a Response. A trap passes from the agent to the manager and has no response.

Notes:

Silicon-IPTV-Broadcast -502

Get • Used to retrieve management information • Gets a specific instance of a specific variable • Can specify more than one item — As many as will fit in one SNMP packet • All variables must be correct or the command is ignored — Can be used to retrieve only items whose complete OID is known

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -503

The get is used to read individual scalar values. In general it is not possible to read tables with a get. References to objects must point to the individual leaf entries that contain actual values and not to nodes that represent tables or sequences of values. Tables are identified as multiple instances of the same variables identified from each other using the value of the index entries associated with the row in the table. Each row must have a unique index value and this forms part of the identification of the variables in the row. In order to reach a table with a get it is necessary to read each element one at a time and it is necessary to know the value of all indexes associated with the row. The index values are generally themselves columns of the table and so to read a table it is necessary to know already the values of the index entries. But these too are indexed with the same value so it is in practice unlikely that a management application would already know all the required index values with reading the table itself.

Notes:

Silicon-IPTV-Broadcast -503

Get-response • Returns the value requested by an SNMP Get • Consists of pairs of variable instance and value • Also used to respond to Get-Next and Set requests

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -504

The get-response includes within its reply the exact objuct identifier previously requested together with its value .

Notes:

Silicon-IPTV-Broadcast -504

GetNext-request • Function and interpretation are identical to Get with one exception — Returns the oid of the next variable instance in the MIB tree and its value, rather than the one specified in the request • Allows exploring MIBs to determine their contents — An MIB “walk” • Allows reading tables of unknown length

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -505

GetNext is used to read tables. Instead of returning the value of the object whose identifier is included in the request, getNext returns the immediately following element within the MIB together with its object identifier. The returned object identifier can then be used in the following getNext-request in order to return the next following element again. In this way the manager can step through the elements within a table or even the whole of the MIB one element at a time without needing to know the details of the contents until it drops off the end of the required table or indeed the whole MIB. This is known as “walking the MIB”.

Notes:

Silicon-IPTV-Broadcast -505

Set • Used to set an MIB variable to a specific value • Community name provides the only protection against invalid use • Each SNMP packet is “all or nothing” to prevent ambiguous results • Managed device can be instructed to take an action by setting the value of the appropriate MIB variable

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -506

A set takes the same format as a get but each object is immediately followed by a value to be used by the agent to set the required variable. The returned getresponse verifies what value has actually been set.

Notes:

Silicon-IPTV-Broadcast -506

SNMPv1 Trap • Sent by an SNMP agent to a manager • Provides asynchronous notification of an event • No response is expected • Seven generic trap types defined: • Trap — 0 — 1 — 2 — 3 — 4 — 5 — 6

Value coldStart warmStart linkDown linkUp authenticationFailure egpNeighborLoss enterpriseSpecific

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -507

The SNMPv1 trap passes from the agent to the manager and can be one of 7 types:0 coldStart sent when device is powered up from cold 1 warmStart sent when a device is reset or restarted 2 linkDown sent when a link fails 3 linkUp sent when a link returns from a failed state 4 authenticationFailure sent when a message with incorrect community name received 5 bgpNeighborLoss sent when contact with the Internet border gateway is lost 6 enterpriseSpecific Some other meaning devices by the vendor. The field following the trap type gives a vendor specific number defining the trap meaning.

Notes:

Silicon-IPTV-Broadcast -507

SNMPv2 and v3 Additional Functions • GetBulkRequest — Efficiently retrieve large blocks of information • InformRequest — Manager can reliably send a trap to another manager • SNMPv2 and SNMPv3 have significantly improved security — Authentication and privacy • Improved error handling and reporting

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -508

SNMPv2 and SNMPv3 add two additional messages. These improve the efficiency retrieving tables and provide a transfer that acts like an acknowledged form of Trap.

Notes:

Silicon-IPTV-Broadcast -508

GetBulk-request • Similar to get_next but adds two new fields — Nonrepeaters and max-repetitions • First <non-repeaters> variables in list treated as get-next • Remaining variables in list will respond as if get-next had been repeated <max-repetitions> times — Or until an MIB “leaf” other than another instance of the variable requested is returned

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -509

Within a getBulk-request two parameters are given in addition to a list of object identifiers. The first gives the number of the object identifiers that are to be retrieved once only. These will normally be scalar variable rather than tables. The remaining entries are assumed to be table objects and are repeatedly retrieved as if repeated getNext-requests had been used with the returned object identifiers used for the next request. The second parameter limits the maximum number of times the repetitions will be returned. The returns will stop either when the maximum repetitions is reach or the end of the table is reached which ever comes first.

Notes:

Silicon-IPTV-Broadcast -509

InformRequest • Sent by one SNMP manager to another SNMP manager • Similar in function to SNMPv1 trap, except it is acknowledged • The variable bindings field always contains at least two elements — sysUpTime (defined in MIB-2) — SNMPv2EventID (defined in the manager-to-manager MIB) — May include additional items if specified by the requesting manager

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -510

The InformRequest transfer acts like a reliable trap in that the receiving manager acknowledges receipt. Normally this is used between different managers to allow a remote manager to forward alarms or alerts in a reliable manner to a global management station at a distant site. It is normally used in conjunction with the manager-to-manager MIB that includes an event table. This lists events that have occurred and includes details of what they are with pointers to more information if required in a log table. The transfer needs then only to include the index entry to the event table and the time. The receiving manager can retrieve more details about the alarm if needed by using get, getNext or getBulk on the event table using the index given.

Notes:

Silicon-IPTV-Broadcast -510

Single and Multi-valued Objects • Objects have multiple instances — one for each row • Each row has an index made up from different values — Normally different columns in the same table • For simple scalar objects the instance is taken as zero Scalar object example Object name

Instance

sysContact

0

Type

Value

DisplayString

Groucho Marx

Table object example (single index) Instance 0

ifIndex Type

Value

Instance 1 Integer

1

Instance 2 Integer

2

ifDescr Type

ifType Value

Type

DisplayString Ethernet1 Integer DisplayString Ethernet2 Integer

ifMtu

Value

Type

...

Value

...

6

Integer 1500

...

6

Integer 1500

...

ifTable {1.3.6.1.2.1.2)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -511

In order to reduce the amount of code that would be needed within a agent, the format of object identifiers used for individual scalar object and for table entries are largely the same. To identify a table object the object identifier of the column object has all the values of the indexes appended to it in order. Scalar objects are assumed to have only a single index with a single value “.0” which is appended to the end of the identifier for the object to produce the “instance identifier”.

Notes:

Silicon-IPTV-Broadcast -511

Scalar Example • Object name — — — — — — — — —

tcpRtoAlgorithm tcpRtoMin tcpRtoMax tcpMaxConn tcpActiveOpens tcpPassiveOpens tcpAttemptFails tcpEstabResets tcpCurrEstab

Object identifier

Instance identifier

1.3.6.1.2.1.6.1 1.3.6.1.2.1.6.2 1.3.6.1.2.1.6.3 1.3.6.1.2.1.6.4 1.3.6.1.2.1.6.5 1.3.6.1.2.1.6.6 1.3.6.1.2.1.6.7 1.3.6.1.2.1.6.8 1.3.6.1.2.1.6.9

1.3.6.1.2.1.6.1.0 1.3.6.1.2.1.6.2.0 1.3.6.1.2.1.6.3.0 1.3.6.1.2.1.6.4.0 1.3.6.1.2.1.6.5.0 1.3.6.1.2.1.6.6.0 1.3.6.1.2.1.6.7.0 1.3.6.1.2.1.6.8.0 1.3.6.1.2.1.6.9.0

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -512

Here are some examples of instance identifiers that could be used to retrieve scalar objects in a get-request. Notice that the instance identifier is just the object identifier with “.0” appended. Out of interest these are all of the scalar values in the TCP group of MIB-2 (RFC1213).

Notes:

Silicon-IPTV-Broadcast -512

Multi-valued Index Example • tcpConnState 1.3.6.1.2.1.6.13.1.1.144.19.74.3.1453.144.19.74.99.21 • tcpConnLocalAddress 1.3.6.1.2.1.6.13.1.2.144.19.74.3.1453.144.19.74.99.21 • tcpConnLocalPort 1.3.6.1.2.1.6.13.1.3.144.19.74.3.1453.144.19.74.99.21 Index tcpConnState 1.3.6.1.2.1.6.13.1.1

Index

Index

Index

tcpConnLocalAddres tcpConnLocalPort tcpConnRemAddres tcpConnRemPor 1.3.6.1.2.1.6.13.1.2

1.3.6.1.2.1.6.13.1.3

1.3.6.1.2.1.6.13.1.4

1.3.6.1.2.1.6.13.1.5

tcpConnEntry 1.3.6.1.2.1.6.13.1

2 (listen)

0.0.0.0

12

0

0

tcpConnEntry 1.3.6.1.2.1.6.13.1

5 (established)

144.19.74.3

1453

144.19.74.99

21 (FTP)

tcpConnEntry 1.3.6.1.2.1.6.13.1

5 (established)

144.19.74.3

1768

144.19.74.99

20 (FTP-DATA)

tcpConnEntry 1.3.6.1.2.1.6.13.1

10 (timewait)

144.19.98.6

43

144.19.74.99

7

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -513

Here we see some tabular entries showing the fully qualified instance identifiers for the objects. This table shows the most complex table in MIB-2, that of the TCP connection table. This has 4 indexes. Can you work out which row of this table is being referenced with the identifier for the tcpConnState:1.3.6.1.2.1.6.13.1.1.144.19.74.3.1453.144.19.74.99.21 Notice that the object identifier for the column is 1.3.6.1.2.1.6.13.1.1 The first index entry is then 144.19.74.3 the second is 1453 the third is 144.19.74.99 the fourth is 21 We are only able to deduce how much of the identifier constitutes each index entry by consulting the definition for the columns in the table in the MIB.

Notes:

Silicon-IPTV-Broadcast -513

Overview of MIB Table ip

1

4

i pNe tToMed i aTab l e

22

i pNe tToMed i aEn t r y

1

2

3

4

i pNe tToMed i a I f I ndex i pNe tToMed i aPhysAddr ess i pNe t ToMed i aNe tAdd ress

i pNe t ToMed i aType

3

00 0 0 c0 c5 ed 9 1

144 . 19 . 7 4 . 5

3

3

00 0 0 c0 10 c e 7 0

144 . 19 . 7 4 . 6

3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -514

One of the most widely referenced tables is the ARP table which can be found as the ipNetToMediaTable (node 22) in the ip group. All tables tend to be constructed in much the same manner with a “table” definition followed by an “entry” definition under which is a node for each column of the table.

Notes:

Silicon-IPTV-Broadcast -514

Access to This Table • A get-next request can be made to each of the column entries • The first row of the table will be returned together with its identifier and index values • Get-next can be repeated using the returned object identifiers — The reply will be the next row of the table • Tables must be read row by row with SNMPv1 • SNMPv2 or v3 allows a Get-bulk — Each row will yield a repeated reply saving half the transfers

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -515

A row of a table can be read in a single transfer by using a getNext-request that refers to each of the column nodes within the object fields in the snmp message. The response will then include the fully qualified object identifiers for the next (first) entries including their index fields followed by their values.

Notes:

Silicon-IPTV-Broadcast -515

SNMP Messages • SNMP messages have the following format: — SNMP-Message ::= SEQUENCE { — version INTEGER {version-1(0)}, — community OCTET STRING, — data ANY} Authentication

SNMP message

version_1(1)

Current version number

community

data GetRequest PDU GetNextRequest PDU GetResponse PDU SetRequest PDU Trap PDU

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -516

SNMP messages are encoded in ASN.1 using the basic encoding rules. In SNMPv1 transfers the message comprises a version number, a community name and a sequence that contains any one of the standard SNMP PDU formats. The version number of SNMPv1 was originally set to zero. This is very unusual in an internet protocol since version numbers normally start from 1. 1 was chosen because the basic encoding rules normally allow values to start from zero and all CCITT/ISO standard variable started from zero. This is one less than the version of snmp. However when SNMPv2 came out the first field in the message was no longer a version number but a security wrapper. This held all the security authentication and encryption profile information. If a receiver was able to understand this security wrapper and decrypt the message then the receiver must already be aware that the PDU held SNMPv2 so it was decided not to include a version number. SNMPv2 however was not widely accepted and soon was obsoleted. Most attempts to use it had shown that while the addition of get-bulk and inform-request were of benefit, the security services were unworkable. Some people therefore started the development of a version of SNMP which used the version 1 community name for security but also employed get-bulk. To distinguish this from SNMPv1 devices it was decided by some users to select version 1 for this and others to use version 2. While no RFC was ever accepted, it is generally known as SNMPv2c. When version 3 was published the conflicts were removed by using version = 3.

Notes:

Silicon-IPTV-Broadcast -516

Managing Devices with SNMP Network Management Concepts

Management Information Base (MIB)

SNMP

Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -517

Notes:

Silicon-IPTV-Broadcast -517

Chapter Summary In this chapter we have • Examined the way in which Network Management stations communicate with managed devices • Identified the structure of SNMP for management • Detailed the component parts of SNMP management

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -518

Notes:

Silicon-IPTV-Broadcast -518

Chapter 9

Next Generation Network Technology

Notes:

Silicon-IPTV-Broadcast -519

Chapter Objectives When you have completed this chapter you will be able to • Identify the key technologies that will form the foundation of 21CN • Compare Access options • Expose the advantages of MPLS switched core • Describe how voice will be carried over the IP infrastructure • Describe how QoS can be delivered for multimedia services • Examine new applications that will lead customer demand for 21CN service

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -520

Notes:

Silicon-IPTV-Broadcast -520

Next Generation Network Technology Next Generation Architecture xDSL Technologies Deploying IEEE 802.1q VLANs Core Technologies QoS Voice Services New Applications: IPTV Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -521

Notes:

Silicon-IPTV-Broadcast -521

21CN High Level Architecture Customer Environment Complex Cost Sensitive Multi-Function Multi-Device Multi-Service Real Time and Streamed

MSAN

Simplified Aggregation and Concentration xDSL

Consumer SME Enterprise

Metro

Core

Complex, Costly, Large, Fast Multi-function Wire-speed processing Multi-access Aggregation

Optical Bulk transport

Ethernet WiFi WiMax

Application and Service Insertion Point IMS service broker requests

Big Fast Cost-effective

∼ 5500

∼ 86

∼ 20

Locations in UK:

Millions

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -522

The Architecture can be divided into 4 parts. The customer environment is today multi-functional, complex and consumer oriented. It is very cost sensitive and must deiver real-time streamed services as well as messaging and data services. The 21CN network will have an interface to the customer through the MSAN which will be simplified and reliable. Reliability will be ensured using aggregation and protection switching. At the edge the service will be simple in order to control volume costs but at the Metro level routing and customer services will be injected. The core is fast and optical.

Notes:

Silicon-IPTV-Broadcast -522

Very Large Next Generation Carrier Networks MSANs

Core

Metro Nodes

Switches © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -523

In very large country wide installations a multi level hierarchy of devices will be needed. Each MSAN might support a few thousand homes in a town or perhaps a few hundred in a rural community. Indeed some technologies that run at very high speed over copper pairs may restrict access distances to 100s of metres and so we might see MSANs on street corners providing VDSL access at 20Mbit/s. With so many distribution devices, perhaps more than 1000 and perhaps as many as 30,000 in the UK, these might be concentrated down over two levels.

Notes:

Silicon-IPTV-Broadcast -523

Next Generation Network Technology Next Generation Architecture xDSL Technologies Deploying IEEE 802.1q VLANs Core Technologies QoS Voice Services New Applications: IPTV Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -524

Notes:

Silicon-IPTV-Broadcast -524

2015 Percentage of Households Access Speed • Access by wired line or wireless

Fiber 80%

VDSL 60%

ADSL

40% 20 Mbit/s 1 km

100 Mbit/s And above 0.3 km

6 Mbit/s 3.7 km limit

20% 2 Mbit/s or less 5 km limit 1995

2000

2005

2010

2015

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

2020

Silicon-IPTV-Broadcast -525

If the demand for increasing speed continues as it has in recent times we can expect to maintain the services with current technologies until 2010 when Wireless and eventually Fiber will take over.

Notes:

Silicon-IPTV-Broadcast -525

xDSL • xDSL (digital subscriber line) refers to a family of techniques that use existing copper loops for high-bit-rate signals • There are several types of DSL modems — ADSL (asymmetric DSL) — HDSL (high-data-rate DSL) — SDSL (single-line DSL) — VDSL (very high-data-rate DSL) • DSL is transmission-level convergence — The voice and data/video signals happen to use the same physical pipe — They have no other relationship

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -526

Digital subscriber line, or loop as the US call it, is the dominant area of development for the next generation. Price per line, flexibility of downloading encoding firmware, low power requirements and high packing densities will all drive the direction of the technology.

Notes:

Silicon-IPTV-Broadcast -526

xDSL Comparison

Type ADSL

Bit rates 1.5–12 Mbit/s down, 16–640 kbit/s up

ADSL2+ 26 Mbit/s down HDSL 1.5–2.0 Mbit/s, symmetric

Distance

Application

9,000–18,000 feet (2.7– Internet access, 5.5 km) of telecommuting, 1-pair UTP video-on-demand 15,000 feet (4.5 km) of 2- or 3-pair UTP

T1/E1 replacement

SDSL

1.5–2.0 Mbit/s, symmetric

10,000 feet (3 km) of 1- T1/E1 replacement pair UTP

VDSL

13–52 Mbit/s down, 1.5–2.3 Mbit/s up

900–5,000 feet (0.3–1.5 ATM, HDTV km) of 1-pair UTP

VDSL2

100Mbit/s +

HDTV = high-definition television See www.adsl.com, www.dslforum.org and ITU-T Recommendations G.991–G.997 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -527

At the moment ADSL running over ATM dominates. Currently delivering up to about 8 Mbit/s, this is expected to evolve using ADSL.2 to perhaps 16 Mbit/s. Eventually however it is expected that VDSL running over Ethernet will become more important as already higher speeds seem achievable and Ethernet presentation at the Metro Node make this more attractive within the architecture. To reach the upper speed limits of either technology the loop length must be restricted to much less than 5 km, to perhaps 1km or even less. This will mean deploying MSANs in street furniture or even underground if loop services are to remain on copper.

Notes:

Silicon-IPTV-Broadcast -527

ADSL2+ subscriber range

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -528

There has been considerable development of these technologies over the last 5 years. The advances of ADSL to ADSL2 and then ADSL2+ has increased the downlink speed to above 16 Mbit/s and on very short loops even further. However under 40% of the loops in the UK are less than 1km and 40% over 2 km.

Notes:

Silicon-IPTV-Broadcast -528

VDSL2 • Deteriorates quickly from a theoretical maximum of 250 Mbit/s • 100 Mbit/s at 0.5 km and 50 Mbit/s at 1 km • Degrades at a much slower rate from there, and still outperforms VDSL. • Starting from 1,6 km its performance is equal to ADSL2+.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -529

VDSL2 (Very-High-Bit-Rate Digital Subscriber Line 2, ITU-T G.993.2 Standard) is an access technology that exploits the existing infrastructure of copper wires that were originally deployed for POTS services. It can be deployed from central offices, from fibre-fed cabinets located near the customer premises, or within buildings. ITU-T G.993.2 VDSL2 is the newest and most advanced standard of DSL broadband wireline communications. Designed to support the wide deployment of Triple Play services such as voice, video, data, high definition television (HDTV) and interactive gaming, VDSL2 enables operators and carriers to gradually, flexibly, and cost efficiently upgrade existing xDSL-infrastructure. ITU-T G.993.2 (VDSL2) is an enhancement to G.993.1 VDSL that permits the transmission of asymmetric and symmetric (Full-Duplex) aggregate data rates up to 200 Mbit/s on twisted pairs using a bandwidth up to 30 MHz. VDSL2 deteriorates quickly from a theoretical maximum of 250 Mbit/s at 'source' to 100 Mbit/s at 0.5 km and 50 Mbit/s at 1 km, but degrades at a much slower rate from there, and still outperforms VDSL. Starting from 1,6 km its performance is equal to ADSL2+. ADSL-like long reach (LR) performance: ADSL-like long reach performance is one of the key advantages of VDSL2. LR-VDSL2 enabled systems are capable of supporting speeds of around 1-4 Mbit/s (downstream) over distances of 4 to 5 km, gradually increasing the bit rate up to symmetric 100Mbit/s as loop-length shortens. This means that VDSL2-based systems, unlike VDSL1 systems, are not limited to short loops or MTU/MDUs only, but can also be used for medium range applications.

Notes:

Silicon-IPTV-Broadcast -529

Next Generation Network Technology Next Generation Architecture xDSL Technologies Deploying IEEE 802.1q VLANs Core Technologies QoS Voice Services New Applications: IPTV Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -530

Notes:

Silicon-IPTV-Broadcast -530

VLAN Configuration • The network manager configures the VLAN membership — Better than re-cabling — But, still requires manual effort — Someday, may be automated (artificial intelligence) • Provides isolation between different carrier services Networkmanagement station

VLAN © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -531

VLAN operation enables a manager to group ports together reflecting the manner in which they normally interact. Separation into groups improves security. Communication with devices in different groups should be rare but if required from time to time can be provided by a router, either separately connected or a a function within one of the switches.

Notes:

Silicon-IPTV-Broadcast -531

VLAN Trunking Tag Destination Address

Source Address

TPID

Ether-Type/ Length

Priority CFI

Payload

VID

CRC

Normal 802.3 Frame

TAG Inserted for 802.1P/Q

TCI

4-byte Tag Header contains: · 2-byte Tag Protocol Identifier (TPID) with a fixed value of 0x8100. Indicates that frame carries the 802.1Q/802.1p Tag information. · 2-byte Tag Control Information (TCI) with the following elements: 3-bit user_priority: 3-bit binary number capable of representing priority levels, 0 through 7. This field is used primarily by the 802.1p standard. 1-bit Canonical Format Indicator (CFI): With a CFI value of 0, it indicates canonical format; A value of 1 indicates non-canonical format used in Token Ring and FDDI 12-bit VLAN Identifier (VID): VLAN 0 and 4095 are reserved, other values represent VLANs. This field is used primarily by the 802.1Q standard. Standard allows less than the maximum 4094 VLANs to be supported. For details see IEEE Std 802.1Q, 2003 Edition © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -532

IEEE 802.1Q adds a 4 byte shim header to the Ethernet frame. The first two bytes are in effect a new Ether-type field that identifies the presence of the 802.1Q information. The second two bytes hold the 12 bit VLAN identifier plus 4 further bits used by 802.1P for priority.

Notes:

Silicon-IPTV-Broadcast -532

Additional Features on Switches:802.1P • IEEE 802.1P Priority for class of service • Allows user configuration of service class — Station assigns a priority value to each frame — Switch assigns to one of a number of queues dependent upon value — Example user_priority

Traffic Type

1

Background

2

Spare

0

Best Effort

3

Excellent Effort

4

Controlled Load

5

Video

6

Voice

7

Network Control

User Priority to Traffic Class mapping © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -533

The first three additional bits hold a priority field which give 8 different priority levels.

Notes:

Silicon-IPTV-Broadcast -533

Enabling Technologies Next Generation Architecture xDSL Technologies Deploying IEEE 802.1q VLANs Core Technologies QoS Voice Services New Applications: IPTV Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -534

Notes:

Silicon-IPTV-Broadcast -534

Delivering QoS in the Core Network • The Internet has evolved into a ubiquitous network — Not designed to give QoS to voice or other real-time users • New applications demand increased core bandwidth • Traditional routing at Layer 3 at high speed is not feasible in software — Need switching in hardware at Layer 2 or Layer 3 • Multi-Protocol Label Switching (MPLS) implemented in Label Switching Routers (LSR) LSR

LSR

LSR

LSR

LSR

LSR

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -535

We are now over the next 3 slides going to talk about MPLS. The aim is not to go into much detail but to deliver just a flavor of what MPLS can do in the core of a large network Those parts of the core which are to carry quality of service traffic would be enhanced to support MPLS. In practice this usually implies that the hardware in some manner assists the switching of packets based upon labels added at the ingess (entrance) router and removed at the egress (exit) router.

Notes:

Silicon-IPTV-Broadcast -535

Multi-Protocol Label Switching • MPLS adds a label as a shim header above the link header and below Network Layer — Includes a 20-bit label and TTL — It can use identifiers instead in ATM and frame relay • Label Edge Routers (LER) add and remove labels • LSRs use Label Distribution Protocol to agree labels for destination PPP

Shim MPLS Header

Label added

LSR

LSR 17

5

Layer 3

17

Label removed

LSR 15

15

3

5

3 LER

LER LSR

LSR

LSR

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -536

The label is normally 32 bits long and includes a 20 bits in the label and 8 bits in the TTL. The routers use LDP to obtain the labels to use for the destination and load these into switching tables used by the hardware of the LSR. The Layer 3 software is then not involved in delivery of the packets other than at entry and exit so reducing the load on the core. The actual value used I the label will be mapped and changed as packets pass from input to output interface at the LSRs. This again will be hardware assisted.

Notes:

Silicon-IPTV-Broadcast -536

Normal Routing by IP Forwarding Hop-By-Hop

D est 4 7 .1 4 7 .2 4 7 .3

Routing Table

D est 4 7 .1 4 7 .2 4 7 .3

3

O ut 1 2 3

D est 4 7 .1 4 7 .2 4 7 .3

O ut 1 2 3

O ut 1 2 3

1 47.1 1

IP 47.1.1.1

2

IP 47.1.1.1

2 IP 47.1.1.1 1 47.2

47.3 3 2 IP 47.1.1.1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -537

Once the Label Switched Path databases are complete traffic is forwarded hop by hop based upon these tables.

Notes:

Silicon-IPTV-Broadcast -537

MPLS Label Distribution

Intf Label Dest Intf Label In In Out Out 3 0.50 47.1 1 0.40

Intf Dest Intf Label In Out Out 3 47.1 1 0.50

Intf In 3

Request: 47.1 .1 t: 47 ues q 3 e R

1

47.3 3 2

Ma

g: ppin

0 0 .5

1 2

Label Dest Intf In Out 0.40 47.1 1 1

47.1

3 2

Mapping: 0.40 47.2

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -538

Labels are distributed along IP routes.

Notes:

Silicon-IPTV-Broadcast -538

Label Switched Path (LSP)

Intf Label Dest Intf Label In In Out Out 3 0.50 47.1 1 0.40 Intf Dest Intf Label In Out Out 3 47.1 1 0.50

Intf In 3

IP 47.1.1.1 1 47.1

3

3 2

1 1

47.3 3

Label Dest Intf In Out 0.40 47.1 1

2 47.2

2 IP 47.1.1.1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -539

When the complete database of LSPs is in place the service can be viewed as a tunnel from Ingress to Egress.

Notes:

Silicon-IPTV-Broadcast -539

Explicitly Routed LSP ER-LSP • We can have multiple paths based on QOS or address length Intf Label Dest Intf Label In In Out Out 3 0.50 47.1 1 0.40 Intf In 3 3

Dest 47.1.1 47.1

Intf Out 2 1

Label Out 1.33 0.50

Intf In 3

Label Dest Intf In Out 0.40 47.1 1 IP 47.1.1.1 1 47.1

3

3 2

1

1 2

47.3 3

47.2 2

IP 47.1.1.1

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -540

When complete the database of LSPs is in place the service can be viewed as a tunnel from Ingress to Egress. With Explicitly Routed LSPs the ingress router can slect which tunnel to use based upon Diffserv QOS or even IP address.

Notes:

Silicon-IPTV-Broadcast -540

MPLS Encapsulation - PPP & LAN Data Links MPLS ‘Shim’ Headers (1-n) n

•••

1 Network Layer Header and Packet (eg. IP)

Layer 2 Header (eg. PPP, 802.3)

4 Octets

Label Stack Entry Format

Label

Exp.

S

TTL

Label: Label Value, 20 bits (0-16 reserved) Exp.: Experimental, 3 bits (was Class of Service) S: Bottom of Stack, 1 bit (1 = last entry in label stack) TTL: Time to Live, 8 bits

MPLS MPLSon onPPP PPPlinks linksand andLANs LANsuses uses‘Shim’ ‘Shim’Header HeaderInserted Inserted Between Layer 2 and Layer 3 Headers Between Layer 2 and Layer 3 Headers

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -541

Shim labels will be used for encapsulation over LANs. Some carriers are now considering building long haul services over Gigabit Ethernet and these too would use shim labels.

Notes:

Silicon-IPTV-Broadcast -541

MPLS Tunneling • MPLS maps labels from input interface to output interface — LSRs can use hardware assistance to switch labeled traffic at link speed — Possible to reach speeds up to 10 Gbit/s • Selection of label and thus the path chosen can be related to QoS — Selected by protocol, TOS, RSVP flow, or other recognizable characteristics • MPLS can control the entire path — Tunnels created end-to-end and one MPLS header is wrapped within another — One header identifies the end destination network — Second outer link label can identify intermediate network point — This enables end-to-end quality issues to be coordinated for the traffic without the need to know complete path • MPLS is not a requirement for VoIP — Enables QoS to be delivered more easily in high bandwidth core networks — Thought to be feasible at higher speeds than ATM © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -542

Traffic destined for the same destination but of a different class of service may follow different paths. It is possible to control and coordinate the end to end QOS by allocating a destination label for the egress network at the LSR and adding a label referencing the class of service required. This would then be tunneled within a second label at the ingress router that address the egress LSR itself rather than the exit network. In this way the egress router can handle the exit traffic of differing QOS arriving from the same source.

Notes:

Silicon-IPTV-Broadcast -542

Pseudo Wires • IETF are developing telecommunications protocols for MPLS • Multiple labels may be carried by a packet — Outer labels defining the service or application — Inner label identifies the path to the destination • Telecommunication services would look like wires and so called PseudoWire Emulation — Uses protocol called PWE3 IP

IP

#Lp

#Lv

IP

IP

#Lp

#Lv

#L1

#L1

IP

IP

#Lp

#Lv

#L2

#L2

IP

IP

#Lp

#L3

#Lv

#L3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

IP

IP

#Lp

#Lv

Silicon-IPTV-Broadcast -543

In telecommunications services circuit switching has been in use since the invention of the telephone exchange in 1892. In a circuit, bits pass as a stream with synchronous timing in use with a network controlled constant rate clock. It is desirable that in the future we would build networks that carry both packet and circuit services but share a common core. This has been done for some time using circuit based cores deployed using ATM, but these tend to be expensive and inefficient. Current IETF thinking suggest Gigabit Ethernet technology will be the preferred option using a packet based core. MPLS can be used to deliver the required QOS and by using multiple labels. One label can define the edge service required (say phone or video) while another outer label can be used inside the network to deliver the QOS.

Notes:

Silicon-IPTV-Broadcast -543

Using MPLS in the 21CN Core

Initial Deployment • Protocols: IPv4, OSPF, MPLS, LDP (DU, LL ret) • Virtualisation: IP VPNs (RFC4364 [RFC2547bis]), PWE3 (RFC3916) • Resilience: Tx and FRR (RFC 4090) • GR (RFCs 3623, 3478, 3473) • QoS: 7 levels (6 user, 1 control) • Connectionless • Unicast

Possible Future Deployment • Many additional VPNs (000s) • Traffic engineering via RSVP-TE (RFC3209) • Capacity and failure response optimisation via a bandwidth manager – connection oriented flows • Multicast • IPv6

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -544

Across the 21CN core MPLS will deliver labelled circuits that can carry traffic with guaranteed QoS between Metro-Nodes at the edges. Using Pseudo-Wire Emulation, TDM and non-native IP services can be provided. This will include Ethernet, T1 and other PSTN truning services.

Notes:

Silicon-IPTV-Broadcast -544

Enabling Technologies Next Generation Architecture xDSL Technologies Deploying IEEE 802.1q VLANs Core Technologies QoS Voice Services New Applications: IPTV Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -545

Notes:

Silicon-IPTV-Broadcast -545

Quality Delivery Options • There are two approaches to delivering voice quality — High-bandwidth provisioning – Easy and cheap with switched LANs where Gbit/s speeds are possible – Not so easy or cheap to apply over WAN services — Use QoS tools to give voice traffic the conditions for good quality • Tools for maintaining voice quality: — QoS signaling – RSVP, IP precedence, DiffServ — Prioritization tools: queuing techniques; e.g., WFQ — Slow-link efficiency tools; e.g., MTU reduction — Call admission control — WRED

FRTS = Frame Relay Traffic Shaping RSVP = Resource Reservation Protocol WFQ = weighted fair queuing © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -546

We have already seen that the key elements that impact quality are delay and packet loss. Delay is made worse by jitter, which can be overcome only by increasing the delay. Packet loss generally occurs when queues overflow and queues are caused by varying load. There are basically two approaches we can take: 1. Make the network capacity so large delay and load are insignificant. If we size every trunk and every router so that it always runs below 50% capacity then delay will be low. But many people say they cannot afford to do this so we must find ways of ensuring that those parts of the data that need good QOS can get it even at the expense of other data. 2. Take QoS measures! We will work through the QoS measures possible (shown in the sub-bullets of the second bullet above). I personally keep returning to this slide to check off each technique as we cover it.

Notes:

Silicon-IPTV-Broadcast -546

High-Bandwidth Provisioning • Quality of service is largely limited by queues within the network • This is particularly a problem where sources of data burst to high rates — Steady rates can be sized and provisioned readily — When the maximum capacity is very high, cost of aggregated maximum becomes too great • Aggregating sources into a very high-bandwidth backbone is a solution — Peaks of demand tend to average out — The greater the number of sources, the more stable the average • A measure of bursty nature of a traffic source is sporadicity (S) — S = (Maximum throughput) / (Average throughput) – e. g. 1 stream of G.711 at 64 kbit/s voice at 40% activity: – S = 64000 / ( 64000 x .4) = 2.5 — For aggregated channels maximum value is taken using confidence level – Normally use 99% confidence level

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -547

If we remove the jitter which is caused by variations in delay then the overall delay will come down significantly. One measure of jitter is sporadicity. There is no jitter in circuit switched networks generally because the max throughput and average throughput of each channel is the same and so sporadic is 1. On VoIP networks, particularly where there is silence suppression, this is no longer true. But if we aggregate many calls into a single high bandwidth network the average sporadicity will reduce improving jitter. This really means that we are better off with a few shared high bandwidth trunks than many individual low bandwidth ones. If we size our VoIP network with no over subscription (S=1), that is on a network using 64 kbit/s G.711 codes we allow say 100 kbit/s per user then we will never have a problem as there is so much bandwidth the limit cannot be reached. On a 100-BASE-T LAN we could size at say 25 Mbit/s and so could support say 250 channels at this level of sizing. If we want to go beyond this then we can either go to switched 100-BASE-T with 100 Mbit/s each and never reach the limit or start taking the activity level into account. At .4 utilization our 25 Mbit/s of throughput would deliver say 2.5 times 250 channels. The Quality spreadsheet will calculate for you confidence intervals.

Notes:

Silicon-IPTV-Broadcast -547

Sporadicity of Aggregated Streams

• The greater the number of streams,

Sporadicity

4

the more stable the loading will be, and thus the delay will be lower and stable

• Typically work with a 99% confidence level

3

Big is beautiful! 2

1

10

100 1000 Number of streams

10000

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -548

The key message sporadicity delivers is that low bit rate links such as 56 kbit/s modem access are bad news because they have only one channel and so high spradicity. If I try to speak at 64 kbit/s then with IP headers I will need more than 64 kbit/s and a lot more than the 40 kbit/s my modem delivers. I am bound to get clipping and bad quality. If I take say 100 channels each at 64 kbit/s then it is unlikely that everyone will talk at the same time. High bandwidth provisioning requires say 100x100kbit/s = 10 Mbit/s Using circuit switching we need 6.4 Mbit/s (64000x100) Using the Quality Spreadsheet the 99% confidence level is 51 speakers, that is to say 99% of the time there will be less than 51 speakers. This will need 4.16 Mbit/s to carry the traffic, including all the overheads for IP headers.

Notes:

Silicon-IPTV-Broadcast -548

Controlling QoS With RSVP • Resource Reservation Protocol (RSVP RFC 2205) — Used by hosts to request QoS — Used by routers to provide QoS — Dynamic; responds to changing requirements • RSVP is a transport-level signaling protocol — Reserves resources along the path of the call • Routers must be capable of RSVP operation — Traffic control is required to implement RSVP – Implies a method to control the use of RSVP – Resources must be available – Authorization to use those resources – Need end-to-end capability

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -549

Notes:

Silicon-IPTV-Broadcast -549

Intserv QoS Control • Two QoS types — Controlled load (RFC 2211) – Performance should be similar to uncongested — Controlled quality (RFC 2212) – Limits on delay – Guaranteed bandwidth – Based on MTU, data rate, buffers, etc. • Specified in reservation message — From receiver to source of signal • Interpreted by routers along route — May be redefined along route • Confirmed by initial sender (source of signal)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -550

Notes:

Silicon-IPTV-Broadcast -550

RSVP and Intserv • Integrated services (Intserv) — Defines some QoS parameters, and — How to use them with RSVP • Sender (transmit end) in new session registers with RSVP — Describes the traffic to be sent — Describes sender QoS capabilities — Sent in path message to receiver • Path message processed and possibly modified by nodes along route — Describe capability to conform to the traffic defined by the source • Receiver interprets result and forms a reservation request — Based on the request of the source as modified by routers on the route — Sent back to the sender via the same route — There may be many such receivers – Reservations are merged as they are combined in the reverse direction

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -551

The integrated services model, or intserv, negotiates a particular QoS at the time it is requested. Before exchanging traffic, the sender and receiver request a particular QoS level from the network. Upon acceptance, the intermediate network devices associate the resulting traffic flow with a specific level of jitter, latency, and capacity. Resource Reservation Protocol (RSVP) is an example of such a model. Here’s Cisco’s definition of RSVP: The Resource Reservation Protocol (RSVP) is a network-control protocol that enables Internet applications to obtain special qualities of service (QoSs) for their data flows. RSVP is not a routing protocol; instead, it works in conjunction with routing protocols and installs the equivalent of dynamic access lists along the routes that routing protocols calculate. RSVP occupies the place of a transport protocol in the OSI model seven-layer protocol stack.

Notes:

Silicon-IPTV-Broadcast -551

Use of RSVP Path and Reservation Messages • Path message defines the QoS request of the sender — Nodes along the route retain the path information – Confirm or deny the ability to provide the required resources Reservation message

Path message

• Receiver verifies the accumulated confirmations — Creates a reservation message; sent back to sender along the same path — Confirms to the nodes that the reservation should be initiated — May be collected, combined with many reservation messages from several receivers © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -552

A VoIP node can signal that it will connect via RSVP and then from the source a Path message is sent containing the QOS information through each router between source and destination. If it gets through satisfactorily the respondent sends back a reservation message which follows back along the same route and each router allocates the capacity. As routes change from time to time the exchange is repeated every now and again and the old paths timeout and are removed freeing up the router resources. Netmeeting sends RSVP packets so if attendees are real interested in this, show them with a Netmeeting call and Ethereal.

Notes:

Silicon-IPTV-Broadcast -552

Problems With RSVP • RSVP reserves resources based on required bandwidth, IP address, and port (socket) — However, in H.323 call signaling, this is not determined until – After ringing starts, and – After capabilities exchange, and – Logical channels are selected — Call may be answered before RSVP can be confirmed – May not get required resources! • RSVP and queuing priorities cooperation is lacking — For example, WFQ

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -553

RSVP uses a pair of IP addresses and a pair of port numbers to form the identification of the flow. This is a layer 4 address. Routers are intended to be layer 3 devices and adding this functionality greatly increases the processing needed for every packet not just voice packets. At the heart of the internet this is a big problem and RSVP would not be feasible. This can probably only be guaranteed on a purpose-built Intranet.

Notes:

Silicon-IPTV-Broadcast -553

RSVP: Limitations • Best suited to intranets instead of Internet — Scalability is poor — More suited to broadcasts; i.e., video • Internet barriers — Contrary to best-efforts delivery for all packets — Requires billing for better service in public networks — Interconnected autonomous systems may not cooperate, and — Route control may not always be possible • Intranet barriers — Conflicting priorities between services – Which services get priority, resource reservation — May simply require more resources (bandwidth) • Eventually RSVP may be used to set up QoS MPLS paths but initially other simpler mechanisms will be used

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -554

Notes:

Silicon-IPTV-Broadcast -554

IP Precedence • IP precedence is included in the IP packet header in the TOS field • With IP precedence, voice can be given priority over data • Format of precedence in TOS byte:

Precedence RFC 000 001 010 011 100 101 110 111

791 Precedence Normal Priority Immediate Flash Flash Overide Critical Internet Management Network Management © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -555

The second byte of the IP header was originally called the Type of Service byte in RFC 791. This enabled precidence to be given to one service over another when routers routed in “seconds per packet” during the 1970s. As routing speeds incresed during the 1980s and 1990 this fell out of use. The IP TOS field can be used to hold the precedence. This can now be extended from 3 bits to 6 bits and re-titled the Differential Services Code Point or DiffServ for short. The differentiated services model, or diffserv, takes a different approach. A few, coarse classes of traffic handling-similar to gold, silver, or bronze levels of frequent flier cards-are established by the network administrator. When the sender needs a particular kind of handling, it marks the individual packets accordingly.

Notes:

Silicon-IPTV-Broadcast -555

DiffServ • Work in progress — Higher priority as a result of VoIP requirements for QoS • Objectives: — Control throughput, delay, jitter, and/or loss — Permits priority access to the data network — Deals with the special requirements of some applications — Attempts to satisfy expectations of users paying for better service — Permits differentiated pricing of Internet services • Based on use of TOS field in packet header (1 byte) — Mostly ignored except on proprietary systems – Implementation is vendor specific

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -556

The Internet Engineering Task Force (IETF) is currently working on a QoS model called "Differentiated Services" or more commonly DiffServ. DiffServ redefines the IP Type of Service (ToS) byte into the DiffServ Byte ("DS Byte"). This is used to signal the required QoS level for a packet. It is also used to identify packets as belonging to one class or another. DiffServ defines Per-Hop Behaviors (PHBs) which will foster common QoS behaviors in the network. The aim is to provide the basis for standards-based QoS in a VPN from end-to-end Note: Some BGP implementations intentionally reset the TOS bits to zero. In all cases, carrying TOS intact is optional.

Notes:

Silicon-IPTV-Broadcast -556

DiffServ and TOS Field

Differentiated services codepoint

• RFC 2474 proposes changes to the meaning of the TOS field — First 6 bits are entitled the differentiated services codepoint — Last 2 bits are unused • Eight codepoints allocated for backward compatibility with RFC 791 — xxxxx0 codes are for standard actions — YYY000 called class selector codepoints – Devices using these must offer different queues – Must give priority to YYY=110 and 111 used for routing traffic over 000 • DiffServ nodes allocate nonclass selector codepoints to different services — Have local meaning and need conversion at boundary of the domain

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -557

By allocated a different value of DSCP to each service, particularly over the customer xDSL loop, it will be possible to give precedence to voice services over Internet Web-surfing and downloading.

Notes:

Silicon-IPTV-Broadcast -557

Weighted Fair Queuing (WFQ) • Each quality-of-service technique establishes a series of router queues • The router must decide which packet to output next • We could give high-priority traffic absolute priority — But then low-priority traffic may never get through — Delays to TCP data traffic cause retransmission – This makes things even worse • Instead, we normally choose to use weighted fair queuing

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -558

We could use Priority Queuing (PQ) but that would give priority to voice say at the expense of data totally. If there was lots of voice we would pass no data at all under some circumstances. We could give voice the highest priority, but limit the size of the queue to ‘n’ packets. Traffic loads in excess of that would fall into the default queue. We could also limit high priority queues to packets of a given size, so voice packets (small MTU) and other small stuff (Hello, ICMP, ARP) all go to the highest queue(s) and other stuff falls later. Finally, data can be selected for queues using Access Control Lists. This is all covered in detail in course 481. WFQ ensures that even with lots of voice some data passes too. We can weight either flows (conversations) or classes of data to ensure that appropriate proportions of capacity are used. If the data traffic is TCP data, it naturally adjusts its retransmission timers to match the delay through the network and limits the amount of data sent with its window flow control. This means that the data circuits will eventually back off to match the capacity allocated. The voice on the other hand will probably continue to be sent at the speed of the talker but will be discarded where congestion occurs. Note that for LANs, the Cisco default is first in first out. For links at or below 2Mbit/s the default is WFQ.

Notes:

Silicon-IPTV-Broadcast -558

Forms of WFQ • There are two forms of WFQ — Flow based — Class based

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -559

Notes:

Silicon-IPTV-Broadcast -559

Forms of WFQ: Flow Based • With flow-based WFQ, packets are classified by flow — Packets for the same full association with the same TOS field belong to the same flow • Each flow corresponds to a separate output queue — WFQ allocates an equal share of the bandwidth to each active queue • Flow-based WFQ is also called Fair Queuing (FQ) because all flows are equally weighted

Flow 1

Flow 2

Flow 3

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -560

Imagine a link over which we wish to carry three different services. One, the first shown here, is a file transfer and no matter how much bandwidth is available this could consume it all if allowed to. The second is a very low bit rate application, a ping perhaps, sending 1 packet per second. The third is a voice transfer sending perhaps 50 packets per second. The link over which we might carry these three services will have some limit of transfer capacity. On a domestic DSL service the upstream rate may be 256 kbit/s. The voice service would constitute about 72 kbit/s when the user spoke and so should easily be carried without problem BUT with a file transfer running sending as many large packets as possible it is entirly possible that this would normally lock out both other applications. With flow base WFQ each flow is guaranteed an equal share of the link capacity and so the file transfer can consume as much as available after the other two services have bee guaranteed their share.

Notes:

Silicon-IPTV-Broadcast -560

Forms of WFQ: Class Based • Class based — Packets assigned to different queues based on their QoS group or the IP precedence in the TOS field — QoS group is an internal classification of packets used by the router – Configured using a class map — TOS-based WFQ classifies packets based only on the 2 low-order IP precedence bits • Weights can be allocated to each class — For example, a weight of 50 allocates at least 50 percent of the outgoing bandwidth during busy times

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -561

Class base WFQ gives even greater control.

Notes:

Silicon-IPTV-Broadcast -561

Forms of WFQ: Class Based

Class 1

Class 2

Weight = 50

Weight = 30

Class Default

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -562

The capacity of the output trunk is divided in proportion to the weights which total 100. In this case the default calls will always get 100 - 50 - 30 = 20% of the capacity. Any unused capacity form the first two classes will be diverted to the default class.

Notes:

Silicon-IPTV-Broadcast -562

Enabling Technologies Next Generation Architecture xDSL Technologies Deploying IEEE 802.1q VLANs Core Technologies QoS Voice Services New Applications: IPTV Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -563

Notes:

Silicon-IPTV-Broadcast -563

Standards for VoIP • There are two sources of standards for VoIP technology — International Telecommunication Union–Technical Standardization Section (ITU-T) — Internet Engineering Task Force (IETF) • ITU-T architecture for multimedia conferencing over packet networks — ITU-T H-series standards define transmission of non-telephone signals — H.323 Most of the currently available products use this — Interfaces easily with world’s telephone networks — Signaling is transferred from ISDN — H.248 for controlling Media Gateways • IETF SIP: the Session Initiation Protocol — Much simpler to understand and use for simple voice calls — Should be simpler to implement for developers, but… – Interfacing to ISDN is more difficult — Media Gateways and conferencing provided by MEGACO – Same as H.248 © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -564

Notes:

Silicon-IPTV-Broadcast -564

H.323 Recommendations • H.323 Multimedia communications services over Packet Based Networks — H.323 Annexes — H.225.0 (Call Signaling and RAS) — H.245 (Media control) — H.235 (security) — H.341 (SNMP) — H.450 (Supplementary Services) — H.246 (Interworking Gateways) — H.248 Gateway Control protocol (Megaco)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -565

H.323 is an overview recommendation and forms the basis for a suite of protocols defined in a family of recommendation.

Notes:

Silicon-IPTV-Broadcast -565

What Counts as Multimedia? • Voice and audio • Video • Conferences • Mixed conversation

BB

C

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -566

Voice is 3.1kHz bandwidth while Audio may be greater – even CD quality stereo with a 20kHz bandwidth.

Notes:

Silicon-IPTV-Broadcast -566

Voice and Audio • Audio signals — Encoded using standard codecs — CODer/DECoder converts to digital — G.711 at 64 kbit/s as default — Others: G.722, G.728, G.729, MPEG1 audio, and G.723 – Examine these later in the course

BB

• Formatted in digital form — Described in H.225 and RTP

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -567

All voice is audio but not all audio is voice. MPEG-3 and MPEG-4 both provide forms of encoding audio which carriers music and speech very well. By contract G.723 is optimized for speech but carries music rather badly.

Notes:

Silicon-IPTV-Broadcast -567

Video • Video signals — H.261 QCIF as minimum — QCIF: Quarter Common Intermediate Format — Other formats possible: H.263 • May include audio as well

B

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -568

Video in the context of H.323 standardization normally implies H.261 or H.263. Better video representation and much more efficient encoding is now available from MPEG-4 and this can also be carried in the same way.

Notes:

Silicon-IPTV-Broadcast -568

Conferences • Point-to-point conference: simple conversation between two terminals — The majority of IP telephony applications • Multipoint conference — Three or more people – Some mixing of the signals may be required – Normally only one person speaks at a time Hi, I am John

Robin here . .

My name is Jane

Hello: I am Jan

I am in charge!

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -569

A one to one voice call is still considered a conference but just point-to-point. Your current generation G.711 encoded GSTN voice call takes 64kbit/s in BOTH directions at the same time or a total of 128kbit/s of network capacity. Most of the time you either talk or you listen so at least half the capacity is lost. If you listen to my voice you will notice that even while I am speaking I am not producing sounds all the time. There are gaps . . . between . . . words . . . pauses . . . . . . . . . . . . . . . . . . . . for effect! Throughout a conversation the GSTN is still carrying 64kbit/ of silence. But VoIP using H.323 can remove the silence (if implemented correctly). This enables us to carry at least twice the capacity and perhaps more even without any change in the way we encode the voice itself.Also at first it would seem that the more people that joined the conference the more capacity would be required. However in practice, in voice conferences there is only one person speaking at a time so the total capacity increase is not as great as with a GSTN conference. Also with the right multicast techniques we may find that the resultant mixed signal need be carried only once over most of its passage back to all receivers.

Notes:

Silicon-IPTV-Broadcast -569

How Is a Normal Phone Call Connected? • Calls start from phones attached — Connected by lines or loops to Central Office (CO) or Local Exchange (LX) — Private branch exchanges (PBX) are owned by user organizations – Small PBXs are called key systems — Transit Exchanges (TX) join LX to distant TX or CO Loops or lines

PBX Trunks

Fax

CO

LX

TX

TX

Key system

LX

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -570

Notes:

Silicon-IPTV-Broadcast -570

Encoding the Content of Calls • Voices and multimedia contents of calls carry real time information • In traditional voice networks timing is maintained • Packet networks do not guarantee timing • Media channels are transported with RTP • Real-time Transport Protocol (RTP) includes sequence and timestamps — Defined in RFC 1889 — Silence can be removed, reducing the bits needed for a call — Receiver can reorder out-of-sequence packets — Smoothes out delay variations called jitter – Achieved by delaying samples to the speed of the slowest • Feedback is provided to the sender using RTCP — Receiver sends back quality information on jitter and packet loss — Also carries identity information

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -571

Notes:

Silicon-IPTV-Broadcast -571

Removing Silence With RTP

Sequence = 3 Timestamp=144

Sequence = 1 Timestamp=100

Sequence = 4 Timestamp=154

Sequence = 2 Timestamp=110

160

140

120

100

Silence threshold

Time

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -572

With RTP we can reduce the bandwidth by suppressing the transport of silence. When I talk to my wife I will normally use a standards “land-line” which carried her voice to me as 64 kbit/s of transmission and carries my silence back to her at the same time in another 64 kbit/s. The current phone network spends half its capacity carrying silence. High quality silence perhaps, but silence none the less. With RTP we can carry perfect silence with no capacity at all!

Notes:

Silicon-IPTV-Broadcast -572

Real-Time Transport Protocol (RTP) • TCP/IP protocol suite includes protocols for real-time applications — Real-Time Transport Protocol (RTP) — Real-Time Control Protocol (RTCP) • RTP provides — Timestamping, sequence number – For playback timing and synchronization — Setting up real-time applications – Audio and video • RTCP provides — Reporting on achieved results — Delay, packet loss statistics — Receiver report on jitter delay • Defined in RFC 1889

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -573

Notes:

Silicon-IPTV-Broadcast -573

Real-Time Applications on Packet Networks • To be intelligible, our speech must be played out with the same timing relationship between words as the original — Received packets may not all arrive with exactly the same delay – This is called jitter • Real-time Transport Protocol marks the voice samples with a timestamp — That timestamp is used to play out the packet in sequence – With the correct relative time relationship

You’re

right

This

is

an

IP

telephony

course

Sent

Received

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -574

Notes:

Silicon-IPTV-Broadcast -574

Session Initialization Protocol (SIP) • Application Layer protocol (RFC 2543) — Create, modify, terminate sessions — Two or more participants • Multimedia protocol—similar to H.323 — Not just voice — Default “well-known-port” is 5060 • Supports five main functions — User location — Terminal capabilities — User availability — Call setup — Call handling

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -575

I have taken this SIP discussion from RFC2543bis Nov 24 2000 We will look at it in overview and see how the protocol is put together. So far I have not been able to find any SIP products that work well or even close to as well as the H.323 classroom demonstrations. This section is theory, smoke and mirrors!!!!!

Notes:

Silicon-IPTV-Broadcast -575

SIP Addressing • User location — SIP address is a URL of the form sip:user@address — Must be a specific host IP and port • Caller will access the SIP server process in the called device — SIP server is the destination of the initial setup message (invite) – Server can provide correct destination or relay the request — To locate the SIP server, the calling terminal can use DNS — SIP URL domain name must have SRV, MX, CNAME or Type A DNS records — These are checked to locate a sip.udp or sip.tcp record • Directing the call at a server permits the endpoint to move — Endpoint address may change; e.g., DHCP assigned — Increases the stability of the DNS cache

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -576

SIP default “well known”port is 5060. This is used to pass signaling messages between servers.

Notes:

Silicon-IPTV-Broadcast -576

Simple SIP Call Setup • SIP signaling based on requests and responses, called transactions in SIP — Text based (rather than encoded binary messages used in H.323) – Based on HTTP/1.1 (RFC 2068) • Step 1 is to open a signaling channel with an Invite message — Sent to the SIP address URL (which may include a port number) — Can use UDP or TCP to well-known port 5060 at user IP address — Invite message contains enough information to immediately establish a media channel to the caller – Includes addressing and codec capabilities INVITE: address and codec Media channel 200 OK address & codec Media channel ACK ACK = acknowledgment © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -577

This is a simple point to point call with signals passing from client port to 5060 on the destination.

Notes:

Silicon-IPTV-Broadcast -577

SIP Entities SIP Registrar

Location Server

SIP Proxy (outbound)

SIP Registrar

SIP Proxy

SIP Redirect Server SIP User Agent pc.work.com

home.net Bestneutral.com © Copyright: All rights reserved. Not to be reproduced without prior written consent.

SIP User Agent bed.home.net Silicon-IPTV-Broadcast -578

Notes:

Silicon-IPTV-Broadcast -578

SIP Proxy • SIP allows an organization the opportunity to use a SIP Proxy — This handles the inward and outward transfer of SIP calls — Can undertake address conversion, security and integrity operations Alice’s SIP phone

Bob’s SIP phone atlanta.com Proxy

INVITE 100 Trying

INVITE 100 Trying 180 Ringing

180 Ringing 200 OK

biloxi.com Proxy

200 OK

INVITE 180 Ringing 200 OK

ACK Media Session BYE 200 OK © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -579

An organization might not wish to allow calls to be made and received into and out of its organization in an uncontrolled manner. Also calls made to an individual that did not answer could be lost rather than being directed to an attendant or to the location a user had moved to. A SIP proxy allows an organization to overcome these problems. It will relay on the request for calls in the form of the INVITE but may modify its contents and map addresses if required. On the inward side it could bar access or redirect the caller as needed. A SIP Proxy can also require authentication using user names, passwords or authentication headers to prevent unauthorized use of the service of gateways or other network resources. It also enables an organization to use simple short form domain addressing internally and to convert this to the fully qualified Internet domain at the exit of the local domain.

Notes:

Silicon-IPTV-Broadcast -579

Megaco Protocol (RFC 3015) • Megaco Protocol Version 1.0 in RFC 3015 — Replaces 0.8 in RFC2885 – Previously known as Media Gateway Control Protocol (MGCP) • Purpose of Megaco: — Control of distributed gateways between IP networks and GSTN • Implements the signaling layers of H.323 — Specifically for voice — Purpose is similar to gatekeeper controlling access to a gateway – Now common protocol with H.248 • Provides for both a media gateway and a signaling gateway — Interface to the PSTN signaling network – Common Channel Signaling System #7 • Master/slave protocol allowing intelligence to be held within service MGCP = Media Gateway Control Protocol © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -580

MEGACO and H.248 have been developed jointly by a single IETF/ITU combined group. The aim is to provide a means of signaling between media gateways and their controllers that can interface to signaling systems in the phone network. In general this will be SS7 or Q.931.

Notes:

Silicon-IPTV-Broadcast -580

Purpose of Megaco • Megaco provides a protocol for control of media gateways — Media gateways could be IP phones, IP PBXs – Could also be attachments to circuit switched networks • Enables service features to be built as part of network — Enables simple end systems to be used with limited intelligence — Enables telephone services to be built over IP networks • Provides mechanisms for building attachments to public SS7 networks

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -581

Notes:

Silicon-IPTV-Broadcast -581

H.248 Packages • Annex E: Basic packages — E.1 generic — E.2 base root package — E.3 Tone Generator – E.5 Basic DTMF Generator (extends E.3) – E.7 Call Progress Tone Generator (extends E.3) — E.4 Tone Detection – E.6 DTMF Detection (extends E.4) – E.8 Call Progress Tone Detection (extends E.4) — E.9 Analog Line Supervision — E.10 Basic Continuity test — E.11 Network Terminations (generic) – E.12 RTP (extends E.11) – E.13 TDM Circuit (extends E.11)

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -582

Notes:

Silicon-IPTV-Broadcast -582

New H.248 Division H.248 (Main body and Annexes A to E)

H.248.1

Gateway control protocol Version 2

H.248, Annex F

H.248.2

Facsimile, text conversation and call discrimination packages

H.248, Annex G

H.248.3

User interface elements and action packages

H.248, Annex H

H.248.4

Transport over SCTP

H.248, Annex I

H.248.5

Transport over ATM

H.248, Annex J

H.248.6

Dynamic tone definition package

H.248, Annex K

H.248.7

Generic announcement package

H.248, Annex L

H.248.8

Error codes and service change reason description

H.248, Annex M.1

H.248.9

Advanced media server packages

H.248, Annex M.2

H.248.10

Media gateway resource congestion handling package

H.248, Annex M.3

H.248.11

Media gateway overload control package

H.248, Annex M.4

H.248.12

H.248 packages for H.323 and H.324 interworking

H.248, Annex M.5

H.248.13

Quality alert ceasing package

H.248, Annex M.6

H.248.14

Inactivity timer package

H.248, Annex N

H.248.15

SDP H.248 package

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -583

Notes:

Silicon-IPTV-Broadcast -583

Next Generation Network: Soft Switch Model SS7 Network Signaling Gateway

SS7 SIGTRAN/TALI/Q.2111 Q-BICC/SIP-T

SS7 SS7 Gateway Controller

Gateway Controller Wireless Access

MEGACO/H.248

Trunking Gateway

Enterprise

MEGACO/H.248

Media Gateway

IP/ATM

PSTN Access

NEW DOMAIN

RTP/RTCP ASP

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -584

Next generation switches will be soft and will depend upon a family of protocols.

Notes:

Silicon-IPTV-Broadcast -584

Enabling Technologies Next Generation Architecture xDSL Technologies Deploying IEEE 802.1q VLANs Core Technologies QoS Voice Services New Applications: IPTV Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -585

Notes:

Silicon-IPTV-Broadcast -585

Typical IPTV Architecture IPTV Head End

Decoders and Transcoders

Video End Head (VEH) Video Hub Office (VHO)

VoD Server

Video Serving Office (VSO)

Management and Control system

Streamers

Core

Internet

Access

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -586

This is a representation of a typical IPTV architecture. The Video On Demand server is a computer with programs stored on hard disk that can be downloaded by subscribers and played. Some implementations allow these to be played during the download in real time wile others download into local storage contained in the customer set-top box or PC. Live TV will be streamed out of a streamer and carried over multicasting protocols across the core network to the access and then on to the receivers.

Notes:

Silicon-IPTV-Broadcast -586

IPTV Applications and there Needs • What is IPTV? • Web TV — Video viewed from the Internet live or stored on a server — Access made through a web browser interface — Needs web access and core capacity at speed compatible with service • Video played on Demand over IP network on a PC or viewer — Each user is typically a stream of packets sent by the server — User interface generally allows pause/rewind/forward like video recorder — Can be used for premium movie services — Needs web access and core capacity at speed compatible with service • Multicast broadcast TV played over the Internet or private IP network — Many viewers watching the same single stream at the same time — May or may not be able to store and replay locally — Core capacity for all channels being viewed — Access capacity for number of channels viewed in parallel © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -587

There is a big debate in the industry about exactly what is and what is not IPTV. Web TV is video and TV programs accessible though web browser interfaces. Normaly this is not multicast and may not even be live TV. Some call VoD IPTV while other people suggest that this is not television but an internet version of a video player. To deliver live TV, particularly quality HDTV over IP a very well engineered and managed network is necessary. If the network is shared with Internet access quality of service protocols need to be run on the routers and switches to give preferences to the TV signals over other Internet services.

Notes:

Silicon-IPTV-Broadcast -587

Encoding and Trans-coding • An important part of the Headend function is encoding TV signals • Feeds may arrive in one satellite modulation format and be re-coded to another for more efficient onward transmission • NTSC feeds may be converted to PAL • Encoding of analogue to MPEG-2 or even MPEG-4 may be required • The selection of the vendor for headend equipment is often based upon the quality of such codecs and trans-coding

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -588

The Integrated Receiver Transcoder (IRT) receives a modulated QPSK carrier and transcodes it into a more bandwidth efficient 64 QAM format. The unit accepts L Band input from a satellite down-link converter and produces a signal appropriate to transmission in a 6 MHz television RF channel. The IRT decrypts and performs Forward Error Correction (FEC) on the incoming satellite data stream. It then clears information streams not intended for local cable transmission and inserts new information streams for this purpose. It prepares the signal for transmission across the terrestrial cable system by re-encrypting programs under local headend control. IRTs are linked via an Ethernet connection in a local headend LAN. The IRT provides local generation and insertion of program specific data, including tier level, purchaseability, price and rating codes. The unit can also be controlled via a management system. IRTs may be optionally daisy chainedtogether via the multidrop port and controlled remotely over the satellite link where no Ethernet connectivity exists. The IRT also provides an expansion interface port so that external devices can be cascaded to allow for processing beyond the capacity of a single IRT.

Notes:

Silicon-IPTV-Broadcast -588

Control Systems • Headend equipment must be controlled • Older systems use illuminated buttons • Latest units based on Windows PCs — Easy-to-use graphical user interfaces to configure equipment — Control conditional access and MPEG encoding rates — Broadcast equipment and receivers — Easy ‘drag and drop’ grouping feature for your receiver base — Graphical user interface to schedule receiver control and conditional access parameters on an — Immediate, one time, daily or weekly basis — On-line help — Password protection on user interfaces — Full redundancy and back-up options — Remote access of head-end control station

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -589

European companies currently lead the world in TV control systems. TANDBERG has a complete range of management system for both small and large MPEG-2 broadcast head-ends for configuration, system monitoring and redundancy. Ideally suited to controlling and monitoring satellite, cable and terrestrial super head-ends, especially where n+m multiplexing is required to save costs. Powerful remultiplexing capabilities make it perfect for digital turnaround applications. Cost effective device only control is available for the simpler regional head-end. These have recently been installed in the largest cable systems in the world and continue to dominate the control of state of the art headend control. The latest generation systems introduced in 2005 have the capability to work using all IP services. While the channel and studio side has been IP enabled on many systems for a year or so, now even distribution can be based on IP. The first All IP system deploying MP4 encoding for HDTV was installed in Europe during 2004. This is likely to spread throughout the whole industry over the next few years.

Notes:

Silicon-IPTV-Broadcast -589

Program Distribution • Switches switch Ethernet Frames and/or IP packets in hardware — By using hardware they are faster than routing in software • Routers route IP packets based upon IP addresses — Able to direct traffic towards the exact destination

Primary Streamer

Backup Streamer

Layer 2 Switches

Multicast Routers

IP Distribution Network

Control station uses SNMP to switch streamers if necessary Streamers stream from same IP address Routers use VRRP/HSRP to guarantee router reachability © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -590

Were a network is to be used for distributing commercial television services including advertising relibility of service is critical. TV industry standards require services that can automatically recover from any failure within 10 seconds or less. Where paid-for advertising is in use penalties may result from an interruption of service of only 3 seconds. Early designs of set-top services map TV channels on to multicast groups at Layer 3 with fixed source addresses. This requires that alternate sources are available within the distribution network which will take on the same IP source address in the event of a primary failure. Network service detectors can be used to verify that channels are received correctly down-stream and the service management system deployed to use SNMP for switching network components when failures occur.

Notes:

Silicon-IPTV-Broadcast -590

Resilience • When designing TV distribution reliability is key • Industry standard requires switch-over on any failure within 10 seconds • Penalties can result if advertisements are interrupted by even 3 seconds • Services may use downstream detectors to verify channel reception Primary Streamer

Backup Streamer

Layer 2 Switches

Multicast Routers

IP Distribution Network

Control station uses SNMP to switch streamers if necessary Streamers stream from same IP address Routers use VRRP/HSRP to guarantee router reachability © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -591

Were a network is to be used for distributing commercial television services including advertising relibility of service is critical. TV industry standards require services that can automatically recover from any failure within 10 seconds or less. Where paid-for advertising is in use penalties may result from an interruption of service of only 3 seconds. Early designs of set-top services map TV channels on to multicast groups at Layer 3 with fixed source addresses. This requires that alternate sources are available within the distribution network which will take on the same IP source address in the event of a primary failure. Network service detectors can be used to verify that channels are received correctly down-stream and the service management system deployed to use SNMP for switching network components when failures occur.

Notes:

Silicon-IPTV-Broadcast -591

Satellite Access IPTV Head End

• Commercial channels distributed by satellite

Decoders and Transcoders

• Decoders deliver service that may be transcoded to match distribution standards

VoD Server Management and Control system

Streamers

• Operators may use telecommunications carriers service on agency basis

Core

• Time-slip TV produced by storage on server farm near downlink

Internet

Access

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -592

Because so many TV stations exist in the USA and originate content there, most commercial cable and IPTV networks need to take the programming from these sources. The primary means of distribution is still satellite although as high bandwidth broadband telecommunications networks with fiber optic cores become available across the world this is expected eventually to change. For now a key part of an IPTV head end is satellite feeds.

Notes:

Silicon-IPTV-Broadcast -592

Core Network IPTV Head End

• Core network is high bandwidth

Decoders and Transcoders

• Must deliver high reliability over long range

VoD Server Management and Control system

Streamers

• Multiple QoS • May interface to the Internet — Must use BGP routing at the interface to the Internet — Often MPLS for speed inside

Core

Internet

Access

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -593

Any IPTV operator that wishes to deliver consistent quality service to their customer needs to engineer the core network that carries traffic to within a few kilometres of each subscriber with care. Indeed the closer to the customer we can reach with high speed fiber core switches, the better will be the services.

Notes:

Silicon-IPTV-Broadcast -593

Video On Demand • Take-up of video on demand services is key to design of network • The greater the take-up the shorter the distance needed to the user • Possible Designs Low Take-up System

High Take-up System

Core

Access

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -594

The best way to design the delivery of VoD depends upon take-up. Where strong broadcast/multicast services are available then take-up will be low and a low capacity single system serving many access racks can be an acceptable answer. The key disadvantage with this kind of access is that all services may need to pass across the core and so cause major loading problems. Where high usage us expected a VoD server located in the distribution network serving those users closely coupled in the same rack offers a distributed solution that can be scaled to a larger size. The problem with the distributed solution is then delivering to each VoD server the library of content for access. Physical media transfer (a man in a van) is still the lowest cost solution for moving content and is well suited to moves. Time-slip TV on the other hand might be better delivered in two stages. Local distributed servers can be configured to access and store locally programs when first requested. By dividing programming into content of 1 hour or less – typical TV programming – files for transfer of even HDTV quality rarely exceed 2 Gbytes. Over a core supporting 1 Gbit/s this will take less than 15 seconds. Take-up of VoD services will be reduced where the viewer has access to local storage of programs. The use of Tivo systems with hard drives in the set-top boxes allows the intelligent recording of broadcast content and then reduces the demand for time-slip viewing perticularly where this is charged at a premium rate.

Notes:

Silicon-IPTV-Broadcast -594

Internet Access Services • Interconnection to Internet designed for required bandwidth and reliability • Typically dual homes connection • QoS services might be available for external services — Must be available for internal voice and video

Core

Internet

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -595

To deliver Internet access the user needs either a PC connection to the access or a set-top service delivering access. Most new IPTV systems provide set-top access through the TV and with increasing deployment of wide screen HDTV this becomes more usable – perhaps as good as a PC. The core network must be connected to the Internet and users expect normal Internet services such as Email, Web page storage, Domain name storage and news services.

Notes:

Silicon-IPTV-Broadcast -595

Triple Play Network • Voice support must be provisioned with required capacity needs — Call controller call rates must be sized and supported — Resilience of call server might be an issue and must be considered — QoS over the access will probably be required – Perhaps with DiffServ and/or VLAN for voice — Interconnection to external SS7 gateway services must be considered — Gateway to International ISDN services may be required GW Core

ISDN

Internet

Call Servers

Residential Gateway

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -596

Adding VoIP support results is little increase in bit rate demand but major increases in revenue. However to deliver good quality voice it may be necessary to ensure QoS over at least the access. Making a phone call while downloading big files over the Internet access will be a problem without it. This requires QoS support in the customer loom termination (typically a domestic DSL router) and matching service in the access concentrator.

Notes:

Silicon-IPTV-Broadcast -596

Enabling Technologies Next Generation Architecture xDSL Technologies Deploying IEEE 802.1q VLANs Core Technologies QoS Voice Services New Applications: IPTV Chapter Summary

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -597

Notes:

Silicon-IPTV-Broadcast -597

Chapter Summary Now you have completed this chapter you can • Identify the key technologies that will form the foundation of 21CN • Compare Access options • Consider VLAN implementation using IEEE 802.1q • Expose the advantages of MPLS switched core • Describe how voice will be carried over the IP infrastructure • Describe how QoS can be delivered for multimedia services • Examine new applications that will lead customer demand for 21CN service

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -598

Notes:

Silicon-IPTV-Broadcast -598

Chapter 10

The Customer Home Network

Notes:

Silicon-IPTV-Broadcast -599

Chapter Objectives When you have completed this chapter you will be able to • Identify the functions and construction of IPTV set top boxes • Appreciate how Next Generation home interfaces will function • Describe home interfacing to Triple-Play networks

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -600

Notes:

Silicon-IPTV-Broadcast -600

Next Generation and Future Technology Structure of home media interface Next Generation Set-top Box Home Interface to Triple Play Networks Protected Broadcast Architecture Encryption and Authentication Systems Watermarking Digital Rights Management Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -601

Notes:

Silicon-IPTV-Broadcast -601

Multimedia Home Platform Context

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -602

At its simplest level, the MHP is set in the following context. The software of the MHP has access to flows of streams and data, and may write some data to storage. The platform may be able to route streams and data outwards to a sink or store.

Notes:

Silicon-IPTV-Broadcast -602

Multimedia Home Platform

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -603

The platform will receive inputs from Viewer input devices and output communications through a screen or other outputs like loudspeakers to present to the viewer. The platform may have access to communications with remote entities. The diagram shows a possible set of external interfaces between an MHP and the outside world. This is one example only but it serves to illustrate a series of principles. The resources of the MHP, accessible by an application, may be contained in a series of different but connected physical entities. The local cluster may connect a number of MHP terminals and resources. A cluster may also include resources which are not part of the MHP infrastructure and are not available to the application. The local cluster is understood to be consistent with the DVB IHDN specification. The detailed description of the MHP in the local cluster is not in the .first version of the specification.

Notes:

Silicon-IPTV-Broadcast -603

Basic MHP Architecture

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -604

The Architecture describes how the MHP software elements are organized. The MHP model considers 3 layers Resources The hardware entities in the platform include a number of functions. They are represented by hardware or software resources. There is no assumption about how they are grouped. The model considers that there can be more than one hardware entity in the total Platform. From an abstract point of view it makes no difference if the logical resources are mapped into one or several hardware entities. What is important is that resources are provided to the MHP transparently. An application should be able to access all locally connected resources as if they were elements of a single entity. System software Applications will not directly address resources. The system software brings an abstract view of such resources. This middle layer isolates the application from the hardware, enabling portability of the application. The implementations of the Resources and System software are not specified in this document. Application Manager The system software includes an application management function, which is responsible for managing the lifecycle of all applications, including Interoperable ones. Application Applications implement interactive services as software running in one or more hardware entities. The interface for MHP applications is a top view from application to the system software. The API lies between the Applications and the System Software seen from the perspective of an application.

Notes:

Silicon-IPTV-Broadcast -604

Interfaces Interfaces Between Between an an MHP MHP Application Application and and the the MHP MHP System System

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -605

Applications use the API to access the actual resources of the receiver, including: databases, streamed media decoders, static content decoders and communications. These resources are functional entities of the receiver and may be finally mapped onto the hardware of the receiver in some manner.

Notes:

Silicon-IPTV-Broadcast -605

Plug-ins

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -606

A "plug-in" is a set of functionality that can be added to a generic platform in order to provide interpretation of application and content formats not specified by this specification to be included in MHP terminals. NOTE: Those organisations concerned with interoperation between the standard MHP platform and other platforms need to specify the plug-in properly for such platforms. The choice of which plug-ins to use must be in the hands of the end-user in order that he can have a choice of sources of service. This option can be exercised in a number of ways, including the purchase of equipment with "built-in" plug-in functionality, the positive selection of a download, or the automatic selection of a download where there is no memory resource limitation. The plug-in may stay resident where the design of the platform implementation allows. The MHP including the plug-in must behave, once the plug-in is loaded and operational, in the same way as a platform supporting the format of the delegated applications without the use of a plug-in.

Notes:

Silicon-IPTV-Broadcast -606

Block Diagram of ETSI Standard Interface Box

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -607

Notes:

Silicon-IPTV-Broadcast -607

Broadcast Channel Protocol Stack

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -608

Except in the case of MPEG-2 sections when an MHP application attempts to access conditional access scrambled data through one of these broadcast channel protocols, the MHP terminal shall attempt to initiate descrambling of this data without the application needing to explicitly ask for it. Attempts to access conditional access scrambled data at the level of MPEG-2 sections shall not happen without the application explicitly asking for this.

Notes:

Silicon-IPTV-Broadcast -608

Interaction Channel Protocols Stack

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -609

Th Interaction channel provides programme selection and control of services provided. The set of DVB defined interaction channel protocols that are accessible by MHP applications in some or all profiles are based on world wide web Internet protocols. The UNO-RPC consists of the Internet Inter-ORB Protocol (IIOP) as specified in CORBA/IIOP. Applications are likely to be deployed using Java virtual machines in order to maintain hardware independence

Notes:

Silicon-IPTV-Broadcast -609

Next Generation and Future Technology Structure of home media interface Next Generation Set-top Box Home Interface to Triple Play Networks Protected Broadcast Architecture Encryption and Authentication Systems Watermarking Digital Rights Management Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -610

Notes:

Silicon-IPTV-Broadcast -610

Next Generation Set Top Box

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -611

The architecture now mirrors PC structures. Notice the interface at the bottom for Ethernet. This allows IPTV access to LAN interfaces. Also the TV out can be for High definition plasma screens or projection systems. The key aspect that is still undecided is how much hard coded software will be built into the silicon. Will for example MPEG decoding logic be hard coded or will this be held in flash ROM. Also on the left side is an interface to a hard disk drive. As the years go by the capacity of hard disks goes up but the base price does not change. We might expect 200 or even 500 Gbytes for about $50. As time goes by the capacity may increase but the price is not likely to vary much. Will the market stand a set-top box that is as expensive as a low end PC?

Notes:

Silicon-IPTV-Broadcast -611

Next Generation Set-Top Box • Convergence of computing, communications and consumer electronics. • Software codecs for Windows Media* Video 9 • MPEG-1, MPEG-2 and MPEG-4 compression formats • Ultra Low Voltage Processor 800 MHz delivers scalable processing • Ethernet controller providing integrated network connectivity — 10BASE-T and 100BASE-TX physical layer capabilities • The next generation media centres will have high quality outputs — Surround sound using Dolby 5.1 audio — HDTV digital outputs

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -612

The next generation will provide high quality outputs for display and sound technology as well as common decoding for digital video standards from what ever source is used. Convergence of cable, over the air and Internet delivered TV will be a key feature of the future. Internet delivered television will become a major challenge to governments and regulators who in some countries wish to restrict public access to some kinds of service.

Notes:

Silicon-IPTV-Broadcast -612

Software in Set-Top Box • Core middleware software building blocks — Advanced compression encoding for digital video enabling service providers to distribute video-on-demand — Middleware for Network Media Processing — Digital Rights Management software — Flash memory over-network download • Distribution over IP — Provides common transport across all distributions

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -613

The middleware is a set of software tools that can be used by programme makers and delivery systems to provide user functionality with minimal network bandwidth implications. The ability to upload such service software dynamically into flash memory will enable the next generation of set top box to grow in functionality over time.

Notes:

Silicon-IPTV-Broadcast -613

Internet Television Portals

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -614

The fastest growing area is Internet distribution of TV. Most of the early systems are news or shopping related. However once set top boxes are IP enabled there will not be any material difference between one distribution and another. The Internet provides a vary low cost mechanism and allows almost any user to become a TV distributor at the price of little more than broadband access and a PC.

Notes:

Silicon-IPTV-Broadcast -614

Web TV From North America

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -615

IPTV is television over IP, in effect over the Internet. Web TV is access via the World Wide Web. In practice these are much the same thing.

Notes:

Silicon-IPTV-Broadcast -615

Web TV From Europe

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -616

Notes:

Silicon-IPTV-Broadcast -616

Web TV From Europe

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -617

Notes:

Silicon-IPTV-Broadcast -617

High Definition Television (HDTV) • Definition: The high-resolution subset of our DTV system. • The US FCC has no official definition for HDTV. • The ATSC defines HDTV as a 16:9 image with twice the horizontal and vertical resolution of our existing system, accompanied by 5.1 channels of Dolby Digital audio • The CEA defines HDTV as an image with 720 progressive or 1080 interlaced active (top to bottom) scan lines. 1280:720p and 1920:1080i are typically accepted as high-definition scan rates • Another definition is to say television that delivers:-

“A picture 4 feet wide when viewed from a distance of 12 feet that delivers resolution at the eye similar to that obtained in a movie theatre”

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -618

In most corners of TV and technology industries, high-definition (HDTV) is being heralded as the biggest thing to happen to the television since colour. HD essentially makes TV picture quality at least four times better than now. But there is real concern that people are not getting the right information about HD on the High Street. Thousands of flat panel screens - LCDs (liquid crystal displays), plasma screens, and DLP rearprojection TV sets - have already been sold as "HD", but are in fact not able to display HD. The UK is the largest display market in Europe but of all the flat panel screens sold, just 1.3% are capable of getting high-definition, or so say industry experts. They may be fantastic quality TVs, but many do not have adaptors in them - called DVI or HDMI (High-Definition Multimedia Interface) connectors - which let the set handle the higher resolution digital images. The industry already recognised that it would be a challenge to get the right information about it across to those of us who will be watching it. Eventually, that will be everyone. The BBC is currently developing plans to produce all its TV output to meet HDTV standards by 2010. Preparations for the analogue switch-off are already underway in some areas, and programmes are being filmed with HD cameras. BSkyB plans to ship its first generation set-top boxes, to receive HDTV broadcasts, in time for Christmas. Like its Sky+ boxes, they will also be personal video recorders (PVRs). The company will start broadcasts of HDTV programmes, offering them as "premium channel packages", concentrating, to start with, on sports, big events, and films, in early 2006. But the set-top box which receives HDTV broadcasts has to plug into a display - TV set - that can show the images at the much higher resolution that HD demands, if HDTV is to be "real". By 2010, 20% of homes in the UK will have some sort of TV set or display that can show HD in its full glory.

Notes:

Silicon-IPTV-Broadcast -618

Next Generation and Future Technology Structure of home media interface Next Generation Set-top Box Home Interface to Triple Play Networks Protected Broadcast Architecture Encryption and Authentication Systems Watermarking Digital Rights Management Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -619

Notes:

Silicon-IPTV-Broadcast -619

TV Down the Phone Line • Today we deliver digital TV using MPEG-2 over channels of about 5 Mbit/s • With MPEG-4 we can deliver HDTV with 5.1 Dolby sound and 5 caption channels in the same bandwidth • We can now deliver this over a phone line carrying 10 Mbit/s • BT is to spend £10,000,000,000 over 5 years enabling this to every UK home • Services are already feasible in parts of Sweden

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -620

Internet TV has been talked about since the start of the web as we know it now. Early attempts to do it - the UK's Home Choice started in 1992 - were thwarted by the lack of a fast network. Now that broadband networks are bedding down, and it is becoming essential for millions, the big telcos are keen to start shooting video down the line. In the face of competition from cable companies offering net voice calls, they are keen to be the top IPTV dogs. Internet Protocol TV is seen as the future of television, and it sits neatly with its vision of the connected entertainment experience. Telcos have been wanting to do video for a long time. The challenge has been the broadband network, and the state of technology up until not so long ago did not add up to a feasible solution. Compression technology was not efficient enough, the net was not good enough. A lot of stars have aligned in the last 18 months to make it a reality. Last year, he said, was all about deal making and partnering up; shaping the IPTV ecosystem. This year, those deals will start to play out and more services will come online. 2006 is where it starts ramping up and expanding to other geographies - over time as broadband becomes more prevalent in South America, and other parts of Asia, it will expand. What telcos really want to do is to send the "triple-play" of video, voice, and data down one single line, be it cable or DSL (Digital Subscriber Line). Some are talking about "quadruple play", too, with mobile services added into the mix. It is an emerging new breed of competition for satellite and cable broadcasters and operators. According to technology analysts, TDG Research, there will be 20 million subscribers to IPTV services in under six years.

Notes:

Silicon-IPTV-Broadcast -620

Internet Video Magazines and Webcasts

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -621

Integrating video with Web services makes it feasible to produce hybrid services that combine features of many technologies.

Notes:

Silicon-IPTV-Broadcast -621

Triple Play Networks • Triple play networks deliver Video, Voice and Data services over the same network — By adding mobility this may also be called Quadruple Play • Such networks could be wired or wireless — Most currently are wired based upon UTP — Future services could be offered over fiber at even higher speeds • The attraction to the customer is low cost high quality varied services — Hundreds of channels of TV from anywhere in the world — Better TV definition and quality: Cinema quality in the living room — Information rich Internet access: — Near free interpersonal communications: Voice, text and possible video — Opportunities for new applications and businesses from anywhere – Interactive gaming around the world – Enabling new business ideas for little initial investment Delivering what the Internet promised in the 1990s © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -622

Notes:

Silicon-IPTV-Broadcast -622

Convergence Protocol Stacks • To deliver Triple Play or even Quadruple Play we need common flexible protocol stacks • The protocols must be open and proven to be interoperable • Data will run over IP and so the foundation of all new services is IP

MPEG HTTP

RTP

TCP

UDP IP © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -623

Quadruple play adds mobility to triple play services. By providing the same services via mobile phone technologies the same services can be delivered into the hands of the you who are the most enthusiastic users of the new technologies.

Notes:

Silicon-IPTV-Broadcast -623

MPEG Compression Protocols • MPEG-1 ISO/IEC JTC1/SC29/WG11 ISO 11172 parts 1 to 4 • MPEG-2 ISO/IEC JTC1/SC29/WG11 ISO 13818 parts 1 to 10 • MPEG-3 abandoned but audio encoding • MPEG-4 ISO/IEC JTC1/SC29/WG11 N4668 • MPEG-7 ISO/IEC JTC1/SC29/WG11N6828 — Adds descriptions language for multimedia • MPEG-21 ISO/IEC JTC1/SC29/WG11/N5231 — Adds digital rights management

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -624

Moving Picture Experts Group (MPEG) a working group of ISO/IEC in charge of the development of standards for coded representation of digital audio and video. Established in 1988, the group has produced MPEG-1, the standard on which such products as Video CD and MP3 are based, MPEG-2, the standard on which such products as Digital Television set top boxes and DVD are based, MPEG-4, the standard for multimedia for the fixed and mobile web and MPEG-7, the standard for description and search of audio and visual content. Work on the new standard MPEG-21 "Multimedia Framework" has started in June 2000. So far a Technical Report and two standards have been produced and three more parts of the standard are at different stages of development. Several Calls for Proposals have already been issued

Notes:

Silicon-IPTV-Broadcast -624

Next Generation and Future Technology Structure of home media interface Next Generation Set-top Box Home Interface to Triple Play Networks Protected Broadcast Architecture Encryption and Authentication Systems Watermarking Digital Rights Management Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -625

Notes:

Silicon-IPTV-Broadcast -625

Conditional Access Systems

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -626

A conditional access system comprises a combination of scrambling and encryption to prevent unauthorised reception. Encryption is the process of protecting the secret keys that are transmitted with a scrambled signal to enable the descrambler to work. The scrambler key, called the control word must, of course, be sent to the receiver in encrypted form as an entitlement control message (ECM). The CA subsystem in the receiver will decrypt the control word only when authorised to do so; that authority is sent to the receiver in the form of an entitlement management message (EMM). This layered approach is fundamental to all proprietry CA systems in use today.

Notes:

Silicon-IPTV-Broadcast -626

Digital Encryption Standard: Simulcrypt

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -627

Way back in 1988, an attempt was made by France Telecom and others to develop a standard encryption system for europe. The result was Eurocrypt. Unfortunately, in its early manifestations it was not particularly secure and multiplex operators went their own way. Thus, in 1992 when the DVB started their consideration of CA systems, they recognised that the time had passed when a single standard could realistically be agreed and settled for the still difficult task of seeking a common framework within which different systems could exist and compete. They therefore defined an interface structure, the Common Interface, which would allow the set top box to receive signals from several service providers operating different CA systems. The common interface module contains the CA system, rather than the STB itself, if necessary allowing multiple modules to be plugged into a single STB. However, there were serious objections to the common interface from many CA suppliers on the grounds that the extra cost would be unacceptable so the DVB stopped short of mandating the Common Interface, instead recommending it, along with simulcrypt. The Common Interface was endorsed by CENELEC in May 1996 and the DTG unanimously adopted its use for digital terrestrial transmission in the UK at its meeting on 13th May 1996. Since then the European Commission has required the use of a common interface mechanism for all integrated tv sets (excluding STBs which may employ embedded CA systems) and this is likely to be the eventual outcome - an embedded CA system in subsidised STBs and Common Interface slots in all other devices. It should be noted that the Common Interface connector allows plug-in cards for other functions besides CA; for example it is proposed to provide audio description for the visually impaired using a common interface card. Simulcrypt allows two CA systems to work side by side, transmitting separate entitlement messages to two separate types of STU, with different CA systems. It also gives the multiplex provider the opportunity to increase his viewer base by cooperating with other multiplex operators. Technical simulcrypt is the same thing but within a single multiplex, thus giving the multiplex operator some leverage with the CA suppliers. The simulcrypt system is shown diagramatically below. Note that it requires cooperation between CA suppliers - something which does not come naturally! If a viewer wishes to receive services from different providers who do not simulcrypt each other's ECMs, the only option is to acquire separate decryption for each CA system. The Common Interface enables a multicrypt environment, allowing an additional CA system to be added as a module. This is not quite the panacea it seems, since it still requires the CA vendor to develop the module, something he is unlikely to be keen on if his best customer doesn't approve. In practice, the possibility of multicrypt encourages the parties to conclude a simulcrypt agreement.

Notes:

Silicon-IPTV-Broadcast -627

Conditional Access Identifications • CA identifiers

0x0001 0x0100 0x0200 0x0300 0x0400 0x0500 0x0600 0x0700 0x0800 0x0900 0x0A00 0x0B00 0x0C00 0x0D00 0x0E00 0x0F00 0x1000 0x1100 0x1200 0x1300 0x1400 0x1500 0x1600 0x1700

to to to to to to to to to to to to to to to to to to to to to to to to

0x00FF 0x01FF 0x02FF 0x03FF 0x04FF 0x05FF 0x06FF 0x07FF 0x08FF 0x09FF 0x0AFF 0x0BFF 0x0CFF 0x0DFF 0x0EFF 0x0FFF 0x10FF 0x11FF 0x12FF 0x13FF 0x14FF 0x15FF 0x16FF 0x17FF

Standardized systems Canal Plus CCETT Deutsche Telecom Eurodec France Telecom Irdeto Jerrold/GI Matra Communication News Datacom Nokia Norwegian Telekom NTL Philips Scientific Atlanta Sony Tandberg Television Thomson TV/Com HPT - Croatian Post and Telecommunications HRT - Croatian Radio and Television IBM Nera BetaTechnik © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -628

Notes:

Silicon-IPTV-Broadcast -628

Copy Protection Schemes • The Copy Control Information (CCI) communications the conditions under which a consumer is authorized to make a copy. — CCI: CGMS + APS + Other •

Copy Generation Management Information (CGMS-A or D) — 0,0 “Copy-free” — 0,1 Undefined (to be used for “No-more-copies”) — 1,0 “Copy-once” — 1,1 “Never-copy”

•

Analog Protection System (APS) Trigger Bits — 0,0 Off — 0,1 PSP on; inverted split color burst off — 1,0 PSP on; 2-line inverted split color burst on — 1,1 PSP on; 4-line inverted split color burst on

•

Other

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -629

One of the most important documents on the future of digital television has recently been approved by the DVB Project. The work of the Multimedia Home Platform committee, it sets out a migration path to an open standards future which will allow the market the freedom to develop wide ranging innovative products. Up to now, digital television services, although based on DVB standards, have proprietary elements within them which make it difficult, for example, to add a satellite 'sidecar' to a terrestrial receiver, or vice versa. Obviously multiplex operators who started services before recent standards emerged, defend their positions and rightly claim that the standards making work, which includes strategies for migration and gives them time to deal with legacy boxes without jeopardising their commercial investment. The UK Terrestrials have no reason to be smug, however. Although the MHEG-5 API they have adopted is likely to have a place in the new standard, the fact is that everyone will have to cope with regular upgrades, just as Windows 3.1 moved to Windows 95. The analogy is not complete however, becauseWindows 3.1 users could chose to continue just as they were - in a broadcast situation, users of older spec machines expect them to continue to work when the broadcaster upgrades,even if they can't avail themselves of all of the new features. The need for 'backward compatibility' is at the heart of the debate and the DVB Project, based at the EBU headquarters in Geneva, offers the right forum for industry experts to come up with the best technical for the commercial requirement. In the UK, the ITC are proposing to add support for the MHP standards as a requirement to licensees. None of this matters very much to the viewer who, today, just wants to watch television but for an industry beginning to come to grips with the issues of convergence, some quiet satisfaction is in order that they have managed to get the 'route map' in place.

Notes:

Silicon-IPTV-Broadcast -629

Content Protection Technologies • Content protection technologies offer methods prevent unauthorized access (for playback or recording) — May include text, graphics, pictures, audio and video •

Two important technologies — Encryption — Watermarking

•

Encryption-based technologies transform copyrighted digital content into unintelligible or unviewable format.

•

Watermark-based technologies embed data directly into copyrighted digital content.

•

Hybrid technologies: Combine features from encryption and watermarking technologies.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -630

As technology progresses so too do the commercial threats from the theft of intellectual property. Content protection must deliver the ability to restrict access and to trace breaches in access protection.

Notes:

Silicon-IPTV-Broadcast -630

Types of Piracy • Commercial piracy: a commercial entity steals content, makes a master, and begins making and selling illegitimate copies — Commercial entities with a manufacturing facility will always be able to get to a clear bit stream, or simply duplicate a prerecorded content •

“Garage” piracy: an individual with smaller resources makes a few hundred illegitimate copies, and sells or barters them — A “garage” pirate, skilled in engineering, will be able to take apart his TV/VCR/STB, and probe a PC board for a clear bit stream

•

“Ant” piracy: an individual wants to make a few copies for his friends, relatives, or even for his own use. — An “ant” pirate will have very limited resources

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -631

Piracy of programming becomes a problem when the intellectual property is of high value (or at least high price). It is probably true that any protection system built could be circumvented eventually with the expenditure of enough resources. The countermeasures must defeat the major threats long enough to allow commercial exploitation to deliver profitable distribution. Intellectual property values reduce with time very quickly so protection for days or weeks may be enough for some services. However major films can retain value for many years if protection can be maintained.

Notes:

Silicon-IPTV-Broadcast -631

Information Security Objectives • Confidentiality: protecting information from unauthorized disclosure — Primary tool: Encryption •

Data integrity: providing assurance that information has not been altered in an unauthorized way — Primary tool: Hashing

•

Authentication: — Message authentication: providing assurance of the identity of the sender (gives no guarantees of timeliness or uniqueness). — Primary tool: Digital signatures — Entity authentication: providing assures of both the identity of — the sender and his active participation in the protocol. — Primary tool: Challenge-response protocols

•

Non-repudiation: preventing a party from denying a previous action. — Primary tool: Trusted third party service

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -632

Notes:

Silicon-IPTV-Broadcast -632

Next Generation and Future Technology Structure of home media interface Next Generation Set-top Box Home Interface to Triple Play Networks Protected Broadcast Architecture Encryption and Authentication Systems Watermarking Digital Rights Management Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -633

Notes:

Silicon-IPTV-Broadcast -633

Encryption: Types of Cipher • Symmetric key cipher: enciphering and deciphering keys are the same or can be easily determined from each other. •

Stream cipher: breaks the message M into successive characters or bits m1, m2,..., and enciphers each mi with the ith element ki of a key stream K=k1k2... — Examples: RC4 and SEAL. Stream ciphers can either be symmetric-key or public-key.

•

Block cipher: breaks the message M into successive blocks M1, M2,..., and enciphers each Mi with the same key K. — Examples: DES, FEAL, IDEA, and RC5. Block ciphers can either be symmetric-key or public-key.

•

Asymmetric (public) key cipher: enciphering and deciphering keys differ in such a way that at least one key is computationally infeasible to determine from the other. — Examples: RSA, ElGamal, and Merkle-Hellman

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -634

Notes:

Silicon-IPTV-Broadcast -634

Symmetric Encryption

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -635

The key characteristic of symmetric systems is that the key is the same at both ends. For broadcast systems the same key would be held within every user device and so protection of this is critical to intellectual property. By keeping the key the same and the algorithm simple to implement speed of operation can be delivered. Each user could be provided with a different key if each distribution was separately encrypted by distributed elements in the network. However this demands massive processing in the network and probable not yet available in current networks.

Notes:

Silicon-IPTV-Broadcast -635

Asymmetric Encryption

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -636

Asymmetric systems generally need longer keys with more complex algorithms but can be dramatically more secure. Generally different keys must be used in each direction but each user can be provided with different keys and so different identification. Asymmetric public key systems, where one key and algorithm is public while the other secret, allows a very secure mechanism to be used but processing power required can be too large for real-time encoding. Generally public key systems are used to deliver symmetric keys in a secure manner. This allows the secure distribution of session keys lasting a few weeks, days, hours or even just minutes. By regular and frequent key changes, a network can protect itself from compromising of a single symmetric key.

Notes:

Silicon-IPTV-Broadcast -636

Comparison of Encryption Characteristics Characteristic

Symmetric

Asymmetric

Speed

Faster

Slower

Secret information

Shared Key

Private Key

Key length

Shorter

Longer

Key Period

Shorter

Longer

Major Problem

Key Distribution

Public Key Authentication

Main Use

Protection of Content

Protection of Keys

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -637

Notes:

Silicon-IPTV-Broadcast -637

Digital Signatures • Digital signature: data string which associates a message with some originating entity •

Digital signature scheme: signature generation algorithm & associated verification algorithm.

• Two general classes of digital signature schemes: — digital signature schemes with appendix — digital signature schemes with message recovery •

Digital signature scheme with appendix: DS scheme which requires the message as input to the verification algorithm — Examples: DSA, ElGamal, and Schnorr.

•

Digital signature scheme with message recovery: DS scheme which does not require a priori knowledge of the message forthe verification algorithm. — Examples: RSA, Rabin, Nyberg-Rueppel.

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -638

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of over 270 broadcasters, manufacturers, network operators, software developers, regulatory bodies and others in over 35 countries committed to designing global standards for the global delivery of digital television and data services. Services using DVB standards are available on every continent with more than 110 million DVB receivers deployed. The networking of communications and access to content anytime, anywhere are becoming the guiding principles by which the converging broadcast, telecommunications and IT industries are preparing for the future. It is in this context that the DVB Project has considered how it can use its strengths to build a further set of specifications and guidelines to support the transition to this connected world. This short PowerPoint presentation introduces DVB 3.0, the work programme that will take the DVB Project into the next phase of its existence. See http://www.dvb.org/

Notes:

Silicon-IPTV-Broadcast -638

Public Key Infrastructure •

Public-Key Infrastructure (PKI) — Combination of software/hardware products, encryption technologies, and services that enables enterprises to protect their communications on the Internet or other types of networks. — Integrates digital certificates, public-key cryptography, and certificate authorities into a total, enterprise-wide network security architecture.

•

A typical PKI encompasses: — Issuance of digital certificates to individual users and servers — End-user enrollment software; integration with corporate certificate directories — Tools for managing, renewing, and revoking certificates

•

A typical PKI encompasses: — Issuance of digital certificates to individual users and servers — End-user enrollment software; integration with corporatecertificate directories — Tools for managing, renewing, and revoking certificates

•

Certificate authorities are the digital world’s equivalent of passport offices

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -639

Notes:

Silicon-IPTV-Broadcast -639

Public Key Certificates • Issued by a Trusted Third Party (TTP) — “data” part : issuer, owner, public key, validity period, etc. — “signature” part: digital signature over the data part. •

X.509 (ITU-T Recommendation & ISO/IEC Standard) — Version — Serial number — Signature algorithm identifier — Issuer name — Validity period — Subject name — Subject’s public key information — Issuer unique identifier (optional) — Subject unique identifier (optional) — Signature

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -640

Digital signatures can be produced by encrypting identity information using the private key of a crypto system so that any user can confirm the identity using the corresponding public key to decrypt. These can be turned into digital certificates of identity by further signing these using the keys held by a certification authority. These could be used to identify a customer, or at least the set top box of a customer, that is entitled to a service.

Notes:

Silicon-IPTV-Broadcast -640

Next Generation and Future Technology Structure of home media interface Next Generation Set-top Box Home Interface to Triple Play Networks Protected Broadcast Architecture Encryption and Authentication Systems Watermarking Digital Rights Management Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -641

Notes:

Silicon-IPTV-Broadcast -641

Data Hiding: Watermarkeing • Data Hiding: process of embedding data(watermark) into multimedia such as image, video, and audio — Invisibility: degree of distortion introduced by the watermark — Robustness: resistance against attacks and normal A/V processes. – noise, filtering, resampling, scaling, rotation, cropping – lossy compression – A-D-A & D-A-D conversions — Capacity: amount of data that can be represented by the embedded watermark •

Typical use of watermarks — Identification of the origin of content distributed copies of the content — Identification of the origin of tracing illegally distributed copies of the content — Disabling unauthorized access to the content

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -642

Notes:

Silicon-IPTV-Broadcast -642

Watermarking Scheme

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -643

Watermarking takes the copyright image and modifies it to embed the watermark so that the transmission source can be identified. A copyright owner can then identify the source of an illicit version that is discovered.

Notes:

Silicon-IPTV-Broadcast -643

Classification of Watermarking •

Domain Type — Pixel: Pixel values are modified to hold the watermark — Transform: Transform Coefficients are modified to hold watermark – Discrete Cosine Transform (DCT) – Discrete Wavelet Transform (DWT) – Discrete Fourier Transform (DFT).

•

Watermark Type — Pseudo Random Number (PSN) sequence (Mean zero Variance 1) – Allows the detector to statistically detect the presence – Generated by feeding the generator with a secret seed — Visual Watermark: The watermark is actually reconstructed and its visual quality is evaluated.

•

Information Type — Non-blind: Both the original image and secret keys — Semi-blind: Watermark and Secret Keys — Blind: Only Secret Keys

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -644

Notes:

Silicon-IPTV-Broadcast -644

Watermark Scaling Factor • The scaling factor controls the intensity of the watermark

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -645

The scaling factor used to add the watermark will have two impacts. The larger the value the easier it is to extract the watermark. The lower the value of the scaling factor the smaller will be the impact of the watermark on the distributed image but the harder it will be to recover the watermark.

Notes:

Silicon-IPTV-Broadcast -645

Discrete Wavelength Transform Watermarking

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -646

Using different transforms of the watermark in different parts of an image the more difficult it is for an enemy to circumvent the impact of the watermarking.

Notes:

Silicon-IPTV-Broadcast -646

Example of Watermarking

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -647

Notes:

Silicon-IPTV-Broadcast -647

Attacks

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -648

Typical attacks on defeating watermarks are processing images using software tools that change the image in technical ways that do not significantly vary the visual performance.

Notes:

Silicon-IPTV-Broadcast -648

Extracted Watermarks

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -649

Good watermarking techniques are now capable of defeating such attacks as these examples show.

Notes:

Silicon-IPTV-Broadcast -649

Extracted Watermarks

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -650

Notes:

Silicon-IPTV-Broadcast -650

Pure SVD Extractions

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -651

Notes:

Silicon-IPTV-Broadcast -651

Conditional Access (CA) Systems • A conditional access (CA) system allows access to services based on certain conditions: — Payment — Identification — Authorization — Registration •

Service providers — Satellite broadcasters: DirecTV, Dish Network — Terrestrial broadcasters: ABC, CBS, NBC — Cable operators: Time-Warner, AT&T, Comcast

•

Services — Subscription — Pay-Per-View — Video-on-Demand — CA vendors: NDS, Canal+, Nagravision © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -652

Conditional access systems are the key to successful paid commercial distribution systems.

Notes:

Silicon-IPTV-Broadcast -652

CA System Architecture

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -653

Notes:

Silicon-IPTV-Broadcast -653

Digital Rights Management • A Digital Rights Management (DRM) system protects, distributes, modifies and enforces the rights associated with digital content. • Primary responsibilities of a DRM system — Secure delivery of content — Prevention of unauthorized access — Enforcement of usage rules — Monitoring of the use of content •

•

Superdistribution: a relatively new concept for redistributing content across the Internet — Allows the customers to forward encrypted content to other — customers — The content forwarded to a potential buyer cannot be accessed — unless the new rights are obtained — May help widen the market penetration DRM system vendors: Intertrust, Microsoft, IBM © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -654

Notes:

Silicon-IPTV-Broadcast -654

Next Generation and Future Technology Structure of home media interface Next Generation Set-top Box Home Interface to Triple Play Networks Protected Broadcast Architecture Encryption and Authentication Systems Watermarking Digital Rights Management Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -655

Notes:

Silicon-IPTV-Broadcast -655

Digital Rights Management (DRM) System Architecture

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -656

Notes:

Silicon-IPTV-Broadcast -656

Interoperability of DRM Systems • Today there are many standards that ensure the interoperability of consumer electronics devices. A consumer may buy a Sony TV set and connect it to a RCA DVD player •

Interoperability is also essential for content protection systems like Content Scramble System (CSS) for DVD player .

•

Unfortunately, a client device supporting the DRM system X can only download content protected by the same system

•

Currently, there is no interoperability among the DRM systems for a number of important reasons: — Every DRM system has secret keys/algorithms. DRM vendors are concerned about sharing secret keys/algorithms — Metadata is data about data that describes the content, quality, condition, and other characteristics of data. Although Rights expression languages (RELs) are emerging as essential components of DRM systems, they are not standardized yet

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -657

Notes:

Silicon-IPTV-Broadcast -657

The Complete Package • Conditional Access (CA) — Satellite, cable & terrestrial content — Content is protected in delivery — Consumer has access to content based on a condition — Privately defined system •

Digital Rights Management (DRM) — Primarily Internet content — Content is protected in delivery and storage — Consumer purchases usage rights — Privately defined system

•

Copy Protection (CP) — Prevention of illegal copying — Interface protection & storage protection — CA + DRM + CP = Content protection

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -658

Notes:

Silicon-IPTV-Broadcast -658

Next Generation and Future Technology Structure of home media interface Next Generation Set-top Box Home Interface to Triple Play Networks Protected Broadcast Architecture Encryption and Authentication Systems Watermarking Digital Rights Management Chapter Summary © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -659

Notes:

Silicon-IPTV-Broadcast -659

Chapter Summary Now you have completed this chapter you will be able to • Examine methods for content protection • Appreciate how content can be protected using conditional access • Compare Conditional Access with Digital Rights Management • Describe how watermarking of content can be achieved

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -660

Notes:

Silicon-IPTV-Broadcast -660

Chapter 11

Industry Trends

Notes:

Silicon-IPTV-Broadcast -661

Chapter Objectives When you have completed this chapter you will be able to • Describe the short term future industry changes • Appreciate the long term trend in the technologies

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -662

Notes:

Silicon-IPTV-Broadcast -662

Switch to HDTV • Growth of HDTV base upon Japan and Korean experience

million 120 Switchover 100 million

100 80

Beijing Olympics 36 million

60 World Cup 12 million

40 20 0 2004

2006

2008

2011

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -663

Recently published predictions of global HDTV sales shows that there are now about 12 million HDTV devices. The sales of these devices are driven by peer pressure and so it is expected that each market will grow in the same manner that Japanese and Korean markets have grown where these products have been available for some time. Sales are often driven by major TV events. The first TV boom in many countries was driven by the 1953 boom in sales to watch the coronation of Elizabeth II in the UK. The switch to colour TV came in the same way by a series of sporting events. Once a new technology becomes established and widely accepted the main international exchanges of TV migrate. This has already happened inside the network for moving programs. This was done in the 1990s via analogue recordings on tape then digital recordings on DAT tape. Now exchanges are made in MPEG-2 files and with stereo sound tracks. These files are now generally moved via IP network connections. The next evolution is likely to be the migration to HDTV format using MPEG-4.

Notes:

Silicon-IPTV-Broadcast -663

IPTV and VOD • Commitment to next generation broadband access network is critical enabler for sufficient quality of service — NTT target of 30m FTTH customers by 2010 in Japan • Innovation and market development being held back by uncertain regulatory environments • Demand could be tempered by dual screen environment rather than convergence • Growing market for consumer electronics able to timeshift viewing may affect IPTV take up — Sales of DVD HDD recorders reached 5.5m in 2005 — Sony X Video Station to launch this year. A PVR with 8 tuners and 2 terabytes of hard disk memory

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -664

VoD services already exist in Japan, Korea and parts of the USA. There are small pockets around Europe too. Early indications are that take-up is price sensitive as one might expect. Where Time-slip TV is offered this is attractive to viewers and results in greater usage than premium rate moves. Even within subscribers the usage rarely reached 15% of subscribers at any time. Usage is more dependent upon what programming on free-to-air channels was. Where this was strong most viewers would not invest the time to decide what movie to watch!

Notes:

Silicon-IPTV-Broadcast -664

Efficient Distribution • Efficient distribution may require the duplication of some services — VoD services are best located near to subscriber — Broadcast channels of recorded video and moves may work best duplicated

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -665

To avoid transferring large amounts of data from one side of the network to another duplication of servers will be necessary in many networks. Bulk transfer of content is probably best achieved by man-in-a-van transfer.

Notes:

Silicon-IPTV-Broadcast -665

Modem and DSL Access Speeds • Access speed increases about four times every four years Access Speed in Kbit/s 100000.0 10000.0

10000

1000.0

1000 512

100.0 14.4

10.0 1.2

1.0

28.8

56

2.4

0.3 0.1 1980

1985

1990

1995

2000

2005

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

2010

2015

Silicon-IPTV-Broadcast -666

The current technology limit to high speed services is at the loop. We can already build core network infrastructures with virtually limitless capacity but the last mile, or at least the last 5 km is still the limitation economically. Part of the limitation is the historic dependence upon copper loops. If we dug up the streets again and replaced these with fiber the situation would change but there is not the economic, or in Britain, the political will to do this yet. If we look at technical development of copper based loop technology the speed has been increasing year by year in a predictable way. The upper limit on this is though to be a bit less than 10 Mbit/s over 5 km, but perhaps 50 Mbit/s if we drop to 500m.

Notes:

Silicon-IPTV-Broadcast -666

Home IPTV Profile • At the moment access speeds limit IPTV services • We need 5 Mbit/s for each HDTV channel viewed in parallel • 2 TV households are the norm • Access needs to double average useage rate — 20 Mbit/s is target for dual HDTV service

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -667

Notes:

Silicon-IPTV-Broadcast -667

Channel Surfing • Channel surfing is a problem to be solved • Switching channels with MPEG-4 takes several seconds – up to 6 • IGMP traffic could overload access routers with many surfers during advertising breaks • Solution might be variable rate services 10 sec

5 Mbit/s

5 sec

2 Mbit/s

3 sec

250 kbit/s

1 sec

64 kbit/s

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -668

Notes:

Silicon-IPTV-Broadcast -668

Commercial Success • Telephony carriers are losing money as competition drives down voice revenue — Solution is seen as IPTV to increase revenues of broadband access • Cable companies see expansion into voice as a way of increasing profits — IPTV delivery gives common network to deliver services • Digital TV transition delivers better security of content — Content owners see DRM as a way of protecting who plays content and how • Migration from Analogue to Digital increases channel space — More channels means fewer viewers per channel and lower advertising revenue — Will we have hundreds of low quality channels nobody wants to watch? • Is it feasible to deliver user created content?

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -669

Notes:

Silicon-IPTV-Broadcast -669

User Created Media: Shoutcast.com

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -670

SHOUTcast is Nullsoft's Free Winamp-based distributed streaming audio system. Thousands of broadcasters around the world are waiting for you to tune in and listen. Take a peek through the SHOUTcast directory (immediately listed below) to start browsing the most popular stations. Be sure to select your connection speed and then what kind of music you're looking for over on the right hand side for optimal listening pleasure. All you need is a player (we recommend Winamp) and you're set to go! Wanna be a broadcaster? It's Free! Check the online docs to get started!

Notes:

Silicon-IPTV-Broadcast -670

Yospace.com

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -671

Case Study: MCP Community Gallery Powers 3 UK's See Me TV Mobile media company 3 was first to utilise the MCP Community Gallery technology to power their successful "reality TV" consumer service, See Me TV. The service was launched in mid-October 2005, and as the UK's first ever mobile community video download gallery, it has been a phenomenal success. 3 UK's customers can submit video clips by MMS to shortcode 32323. The clips are moderated and accepted clips are placed into an appropriate category within the handset based gallery. The original sender is informed of the clip's acceptance by text message, which also invites them into See Me TV if they are a first-time contributor. Any of 3 UK's 3.2 million customers can use their video mobile to browse, search and download clips from the gallery. The clips range in price from 10p to 50p. Customers who have submitted clips into the gallery can manage their clips from the service and view how many downloads they've had. Contributors are paid a small share of revenue generated from their submitted content, which is paid in cash on a monthly basis. The repayments are handled by Yospace's integration with PayPal. See Me TV is hosted and managed by Yospace with integration into 3's messaging, portal and billing systems.

Notes:

Silicon-IPTV-Broadcast -671

Chapter Summary Now you have completed this chapter you can • Describe the short term future industry changes • Appreciate the long term trend in the technologies

© Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -672

Notes:

Silicon-IPTV-Broadcast -672

Course Summary

Notes:

Silicon-IPTV-Broadcast -673

Course Summary Now you have completed this course you can • Understand the equipment and software used to deliver IPTV and VoD services • Describe the architecture of a these modern TV services • Compare Cable, over-air terrestrial, satellite and Internet delivery systems • Appreciate the trend in the technologies • Understand addressing schemes for IP network prefix configurations • Examine resilience for MAC/IP mappings for reliable redundancy switching • Select the best routing and switching strategy for server and delivery networks • Analyze protocols used to carry multimedia and troubleshoot services problems • Appreciate how multicast routing protocols function • Specify requirements for firewall transit of video services • Compare how DiffServ, DSCP, RSVP, WFQ, MPLS and 802.1P/Q can provide quality of service • Select the most appropriate quality of service option © Copyright: All rights reserved. Not to be reproduced without prior written consent.

Silicon-IPTV-Broadcast -674

Notes:

Silicon-IPTV-Broadcast -674