Professional Documents
Culture Documents
IPTV Course
IPTV Course
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
Chapter 2
Chapter 3
Chapter 4
Layer 2 Addressing
Chapter 5
Layer 3 Addressing
Chapter 6
Routing
Chapter 7
Multicasting
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Industry Trends
Chapter 12
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
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
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -17
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -19
Notes:
Silicon-IPTV-Broadcast -19
Resolutions
Horizontal Vertical
Pexils
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
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
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
1250
1000
700
700
2.4
16/9
1125
1080
540
600
3.3
16/9
20
NTSC
i
conv.
NTSC prog. p
525
484
242
330
4/3
4.2
PAL
conv.
PAL prog
625
575
290
425
4/3
5.5
625
575
400
425
4.3
4/3
5.5
625
575
290
465
4/3
625
575
400
465
4.3
4/3
HDTV
USA,
analog
HDTV
Europe,
analog
HDTV NHK
SECAM
conv.
SECAM
prog
525
484
340
330
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -27
Notes:
Silicon-IPTV-Broadcast -27
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.
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 nations 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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -30
Notes:
Silicon-IPTV-Broadcast -30
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -40
Notes:
Silicon-IPTV-Broadcast -40
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
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
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
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
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
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
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
VideoExpressvideo codecs such as the DVT for NTSC or the VT34A3 for PAL.
Notes:
Silicon-IPTV-Broadcast -47
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
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
Notes:
Silicon-IPTV-Broadcast -51
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
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
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 indexa 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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -57
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
Aerial Cable/Self-Supporting
Armored Cable
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -59
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
+20
0.5
+10
0.4
0.3
-10
DWDM
0.2
-20
1300
1400
1500
Wavelength (nm)
Dispersion (ps/nmxkm)
Attenuatiom (dB/km)
0.6
1600
Silicon-IPTV-Broadcast -61
Notes:
Silicon-IPTV-Broadcast -61
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -63
Notes:
Silicon-IPTV-Broadcast -63
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -64
Notes:
Silicon-IPTV-Broadcast -64
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
+20
0.5
+10
0.4
DWDM
0.3
-10
0.2
-20
1300
1400
1500
Wavelength (nm)
Dispersion (ps/nmxkm)
Attenuatiom (dB/km)
0.6
1600
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
1600
800
400
200
100
Optimal Operating
Region
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
Attenuation
Dispersion
+20
SSMF
0.5
+10
0.4
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
Notes:
Silicon-IPTV-Broadcast -68
Attenuation
+20
0.5
+10
0.4
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
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
Notes:
Silicon-IPTV-Broadcast -72
Network Topologies
Point-to-Point
T1
T3
ADM
(terminal mode)
ADM
(terminal mode)
T1
T3
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
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
Alarm !
Working
backup
No data
Data
Break
Data
Normal Operation
APS
APS
Silicon-IPTV-Broadcast -76
Notes:
Silicon-IPTV-Broadcast -76
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -77
Notes:
Silicon-IPTV-Broadcast -77
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
Silicon-IPTV-Broadcast -80
Notes:
Silicon-IPTV-Broadcast -80
Silicon-IPTV-Broadcast -81
Notes:
Silicon-IPTV-Broadcast -81
* 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
BBC One
BBC Two
Includes regional variations; digital variations from analogue in Wales and Northern Ireland
ITV1
In England, Wales, Southern Scotland, the Isle of Man and the Channel Islands2
STV
UTV
In Northern Ireland2
Channel 4
Except Wales
S4C Digidol
Wales only
A3
Five
A3
ITV2
BBC Three
Broadcasts 1900-0600
Channel 4
Wales only
TeleG
BBC Four
Broadcasts 1900-0600
10
ITV3
11
Sky Three
12
UKTV History
13
More4
14
E4
15
ABC1
16
QVC
2
C
Broadcasts 0500-0100
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -84
Notes:
Silicon-IPTV-Broadcast -84
17
UKTV Gold
18
The Hits
19
Broadcasts 0600-1800
20
Ftn
Broadcasts 1800-0600
21
TMF
22
Ideal World
23
bid tv
24
price-drop tv
25
TCM
26
UKTV Style
27
Discovery Channel
28
ITV4
Broadcasts 1800-0600
29
Film4
30
E4+1
31
ITV Play
32
Film4+1
33
British Eurosport
34
Setanta Sports 1
Pay-per-view service (from Top Up TV); broadcasts dependent on SPL match times
35
Five US
36
Five Life
Broadcasts 0500-2300
37
SmileTV
Broadcasts 0100-0500
D
D
Reduced hours in Wales (only broadcasts 0600-1900)
A
A
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -85
Notes:
Silicon-IPTV-Broadcast -85
38
Top Up TV Anytime 1
39
Top Up TV Anytime 2
40
Top Up TV Anytime 3
42
43
Top Up TV Promo
70
CBBC Channel
Broadcasts 0600-1900
71
CBeebies
Broadcasts 0600-1900
72
Cartoon Network
75
CITV Channel
80
BBC News 24
81
BBC Parliament
82
Sky News
83
86
S4C2
A3
87
Community Channel
Broadcasts 0600-0900
88
Teachers' TV
Broadcasts 1100-1300
97
Television X
98
Red Hot TV
501
BBC HD Trial
CH31
503
ITV HD Trial
CH27
504
Channel 4 HD Trial
CH27
505
Five HD Trial
CH27
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -86
Notes:
Silicon-IPTV-Broadcast -86
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
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
Satellite
Receivers
HPA
Decoder
Modulation &
Encryption
Tree top
House top
Receive Antenna
(may be omni or
directional)
Decoded
Receiver
Frequency
Translation
Silicon-IPTV-Broadcast -90
Notes:
Silicon-IPTV-Broadcast -90
av
ow
icr
RST
System
controller
RST
RST
Fiber
Local Concentrator
exchange
Cell
site
System Cell
controller site
Fax machine
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
Nokia
DAXnode 2000
Ericsson
RAS 1000
Motorola
WiLL
Northern Telecom
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
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
802.10 Security
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -95
Notes:
Silicon-IPTV-Broadcast -95
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 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
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
Notes:
Silicon-IPTV-Broadcast -99
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 3GPPs IMS
IMS
HSS
FIXED
MOBILE
xDSL
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -101
Notes:
Silicon-IPTV-Broadcast -101
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -102
Notes:
Silicon-IPTV-Broadcast -102
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
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
Notes:
Silicon-IPTV-Broadcast -107
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -111
Notes:
Silicon-IPTV-Broadcast -111
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -112
Notes:
Silicon-IPTV-Broadcast -112
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
Notes:
Silicon-IPTV-Broadcast -115
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -117
Notes:
Silicon-IPTV-Broadcast -117
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
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 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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -123
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -125
Notes:
Silicon-IPTV-Broadcast -125
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -126
Notes:
Silicon-IPTV-Broadcast -126
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -127
Notes:
Silicon-IPTV-Broadcast -127
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
Notes:
Silicon-IPTV-Broadcast -129
Part 2 of MPEG2
Multiview 4:2:2
Simple
Main
High level
High-1440
level
Main level
Low level
SNR
scalable
Spatial
scalable
High
X
X
X
X
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -130
Notes:
Silicon-IPTV-Broadcast -130
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -131
Notes:
Silicon-IPTV-Broadcast -131
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -132
Notes:
Silicon-IPTV-Broadcast -132
MPEG-Layer3 Overview
Silicon-IPTV-Broadcast -133
Notes:
Silicon-IPTV-Broadcast -133
sound quality
bandwidth
mode
bitrate
reduction ratio
telephone sound
2.5 kHz
mono
8 kbps *
96:1
4.5 kHz
mono
16 kbps
48:1
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -135
Notes:
Silicon-IPTV-Broadcast -135
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -140
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
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
Length of
run of zeros
0
Value of nonVariable-length
zero
Code-word
coefficient
12
0000 0000 1101 00
0010 0001 0
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
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
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -151
Notes:
Silicon-IPTV-Broadcast -151
Versions of MPEG4
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -152
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 objects or scene descriptions 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-2s 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
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
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -161
Notes:
Silicon-IPTV-Broadcast -161
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. JVTs 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
Silicon-IPTV-Broadcast -163
Notes:
Silicon-IPTV-Broadcast -163
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -164
Notes:
Silicon-IPTV-Broadcast -164
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
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
2nd Generation
Encoder
5
3rd Generation
Encoder
MPEG-2
Mbit/s
MPEG-4
4th Generation
Encoder
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
2nd Generation
Encoder
5
3rd Generation
Encoder
MPEG-2
Mbit/s
MPEG-4
H.26L
4th Generation
Encoder
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
2nd Generation
Encoder
5
3rd Generation
Encoder
Mbit/s
MPEG-2
MPEG-4
H.26L
4th Generation
Encoder
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
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
Channels
AAC
Total bit
rate
320 kb/s
640 kb/s
impairment
4.6
AAC
128 kb/s
impairment
4.8
AAC
96 kb/s
impairment
4.4
MPEG-1 Layer II
192 kb/s
impairment
4.3
128 kb/s
impairment
4.1
AAC
24 kb/s
quality
4.2
quality
3.7
quality
3.6
6 kb/s base,
18 kb/s enh.
6 kb/s base,
18 kb/s enh.
18 kb/s
quality
3.2
G.723
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
Channels
Total bit
rate
Wideband CELP
18.2 kb/s
quality
2.3
BSAC
96 kb/s
quality
4.4
BSAC
80 kb/s
quality
3.7
BSAC
64 kb/s
quality
3.0
64 kb/s
quality
4.4
G.722
64 kb/s
quality
4.2
32 kb/s
quality
3.4
Narrowband CELP
6 kb/s
quality
2.5
Twin VQ
6 kb/s
quality
1.8
HILN
16 kb/s
quality
2.8
HILN
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -174
Notes:
Silicon-IPTV-Broadcast -174
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
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
MD
Bitstream
Output
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -176
Notes:
Silicon-IPTV-Broadcast -176
Quality
Y-PSNR [dB]
39
38
37
36
35
34
33
32
31
30
29
28
27
JVT/H.264/AVC
MPEG-4
MPEG-2
H.263
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
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
Silicon-IPTV-Broadcast -181
Notes:
Silicon-IPTV-Broadcast -181
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
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -190
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
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
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
Chapter 2
Addressing
Chapter 3
Routing
Chapter 4
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
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
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
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
Network Links
IP
Applications
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -205
Notes:
Silicon-IPTV-Broadcast -205
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -206
Telephone companies (Telcos) are optimized for voice. (Shannons 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. Doesnt it make sense to
put voice on the data network rather than the other way around? Isnt 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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -209
Notes:
Silicon-IPTV-Broadcast -209
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
P rovide s da ta
re pre s e nta tion
P rovide s e nd-to-e nd
da ta inte grity
Route s a nd re la ys
Ma na ge s communica tion
be twe e n a dja ce nt node s
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
P rovide s da ta
re pre s e nta tion
P rovide s e nd-to-e nd
da ta inte grity
Route s a nd re la ys
Ma na ge s communica tion
be twe e n a dja ce nt node s
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 Murphys 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
P rovide s da ta
re pre s e nta tion
P rovide s e nd-to-e nd
da ta inte grity
Route s a nd re la ys
Ma na ge s communica tion
be twe e n a dja ce nt node s
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -213
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
P rovide s da ta
re pre s e nta tion
P rovide s e nd-to-e nd
da ta inte grity
Route s a nd re la ys
Ma na ge s communica tion
be twe e n a dja ce nt node s
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
P rovide s da ta
re pre s e nta tion
P rovide s e nd-to-e nd
da ta inte grity
Route s a nd re la ys
Ma na ge s communica tion
be twe e n a dja ce nt node s
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
Transport
Routing
Network
Detects Errors
Data Link
Moves Bits
Physical
P rovide s da ta
re pre s e nta tion
P rovide s e nd-to-e nd
da ta inte grity
Route s a nd re la ys
Ma na ge s communica tion
be twe e n a dja ce nt node s
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
Transport
Routing
Network
Detects Errors
Data Link
Moves Bits
Physical
P rovide s da ta
re pre s e nta tion
P rovide s e nd-to-e nd
da ta inte grity
Route s a nd re la ys
Ma na ge s communica tion
be twe e n a dja ce nt node s
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 Kirks 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
Presentation
Checkpoints and
Activities
Session
Transport
Routing
Network
Detects Errors
Data Link
Moves Bits
Physical
P rovide s da ta
re pre s e nta tion
P rovide s e nd-to-e nd
da ta inte grity
Route s a nd re la ys
Ma na ge s communica tion
be twe e n a dja ce nt node s
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 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
Network Links
IP
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
Silicon-IPTV-Broadcast -221
Notes:
Silicon-IPTV-Broadcast -221
Application
Application
Transport
Transport
Internet
Internet
Network interface
Hardware
TCP/IP
Network interface
Hardware
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
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
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.52.0 Mbit/s,
4.5 km
symmetric
of 2- or 3-pair UTP
SDSL (single-line DSL)
SDSL 1.52.0 Mbit/s,
3 km of
ADSL (asymmetric DSL)
symmetric
1-pair UTP
ADSL 1.59 Mbit/s down,
High bit rate downstream
2.55 km of 1-pair
16640 kbit/s up
UTP
Low upstream
VDSL 1352 Mbit/s down, 0.31.5 km of
VDSL (very high-data-rate DSL)
1.52.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
Network Links
IP
Applications
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -226
Notes:
Silicon-IPTV-Broadcast -226
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
SMTP
POP
FTP
Etc.
SNMP
TCP
RIP
Etc.
Transport
UDP
IP
ICMP
Application
Internet
ARP
Data link
Network interface
Physical
Hardware
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
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
Ver
IHL
TOS
Length
M D
0 F F
Datagram ID
TTL
31
Prot
Fragoff
Checksum
20 bytes
Source address
Destination address
Options
Data
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
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
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
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
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
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
Notes:
Silicon-IPTV-Broadcast -236
Ethernet
Network
1,500
1,518
4,440
4,500
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
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
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
Network Links
IP
Applications
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -240
Notes:
Silicon-IPTV-Broadcast -240
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
10
16
Source port
24
31
Destination port
Sequence number
Acknowledgment number
HLEN
Reserved
Code bits
Checksum
Window
Urgent pointer
Padding
Data
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
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
Network Links
IP
Applications
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -245
Notes:
Silicon-IPTV-Broadcast -245
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
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
Youre
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 ProtocolAdds minimum of 12 bytes
V: VersionRFC 1889 currently 2
P: Padding =1 if packet contains padding
X: Extension bitif 1, then there is an extension header
CC: CSRC countthe number of CSRC identifiers following
M: Markerprofile may use this bit to define frame boundaries
PT: Payload typedefines the type of encoding
Sequence number increments by 1 for each RTP data packet
V=2 P X
CC
PT
Sequence number
Timestamp
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -255
Notes:
Silicon-IPTV-Broadcast -255
Network Links
IP
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
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
802.1 overall
standards
Type 1
Type 2
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
. . .
Assigned
to the vendor
(3 bytes)
Payload data
CRC
Assigned
by the vendor
(3 bytes)
1100 0000
0
- - -
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -262
Notes:
Silicon-IPTV-Broadcast -262
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
Meaning
Half duplex twisted pair, cat 3 or cat 5 (at 10 Mbit/s) 100m
TX
FX
SX
LX
LH
CX
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
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
Heavy traffic!
Lighter traffic!
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -266
Notes:
Silicon-IPTV-Broadcast -266
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
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -273
Notes:
Silicon-IPTV-Broadcast -273
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -274
Notes:
Silicon-IPTV-Broadcast -274
Recommended or
Default value
3.0
2.0
20.0
15.0
6
Permitted
Range
6.040.0
4.030.0
110
Compatibility
Range
1.02.0
6.040.0
4.030.0
110
Recommended
or default value
32 768
128
Range
061 440 in steps of 4096
0240 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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -276
Notes:
Silicon-IPTV-Broadcast -276
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -277
Notes:
Silicon-IPTV-Broadcast -277
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
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
Notes:
Silicon-IPTV-Broadcast -279
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
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
Silicon-IPTV-Broadcast -282
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
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 Actors 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 Actors state variables for the port, encoded as individual bits within a single octet.
Notes:
Silicon-IPTV-Broadcast -284
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 Actors 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 Actors Receive machine is in the
EXPIRED state; if ALSE (encoded as a 0), this .ag indicates that the Actors Receive machine is not in the EXPIRED state.
Notes:
Silicon-IPTV-Broadcast -285
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 Partners 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 Actors view of the Partners state variables, depicted in Figure 438 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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -287
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
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
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
Subnetworking
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -293
Notes:
Silicon-IPTV-Broadcast -293
192 . 168 . 1
.10
Host
Network
255.255.255
Mask
.0
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -294
Notes:
Silicon-IPTV-Broadcast -294
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
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
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
Staticby 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
Subnetworking
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -298
Notes:
Silicon-IPTV-Broadcast -298
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
N
0xxxxxxxx
1126
N
10xxxxxxx
128191
N
110xxxxxx
192223
Special addresses
Local host: 127.0.0.1
Broadcast:
Local 255.255.255.255
Directed; e.g., 192.168.1.255
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
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
Subnetworking
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -302
Notes:
Silicon-IPTV-Broadcast -302
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -306
Notes:
Silicon-IPTV-Broadcast -306
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -307
Notes:
Silicon-IPTV-Broadcast -307
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
Subnetworking
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -309
Notes:
Silicon-IPTV-Broadcast -309
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -314
Notes:
Silicon-IPTV-Broadcast -314
139.21.1.0
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -315
Notes:
Silicon-IPTV-Broadcast -315
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -316
Notes:
Silicon-IPTV-Broadcast -316
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
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
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
D
C 1
D 0
A 1
B 0
C 1
A 1
B
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
Notes:
Silicon-IPTV-Broadcast -324
C
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
B 1 1 0
C 0 1 1 1
D 1
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
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
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
C
A 2 1
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
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
C
A 3 2
B 2 1
C 1 0
D 0 1
A C
A 1 0 1
B 0 1 1
C 1 2 0
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
C
A 3 2
B 2 1
C 1 0
D 0 1
A C
A 1 0 1
B 0 1 1
C 1 2 0
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
Tables Updated
D
B 2 3
C 1 0
D 0 1
A
A 1 0
B 0 1
C 3 2
D 4 3
A 4
D
3
B 3
C 0
D 1
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
C
A 5 4
B 4 3
C 1 0
D 0 1
A
A 1 0
B 0 1
C 5 4
D 6 5
A 6
D
5
B 5
C 0
D 1
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
C
C 1 0
D 0 1
A
A 1 0
B 0 1
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
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
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
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
R1
Net 2
R4
My links to Net 2 and
Net 3 are up!
Net 5
Net 1
Net 3
CRASH
R2
Net 4
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
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 hosts 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
ISPs 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
hostmaster@ripe.net 19990730
jamieb@uk.uu.net 20020905
philip.bridge@orange.co.uk 20020905
philip.bridge@orange.co.uk 20040624
RIPE
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -342
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
Silicon-IPTV-Broadcast -343
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
.
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -347
Notes:
Silicon-IPTV-Broadcast -347
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -348
Notes:
Silicon-IPTV-Broadcast -348
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -349
Notes:
Silicon-IPTV-Broadcast -349
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -351
Notes:
Silicon-IPTV-Broadcast -351
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
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
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
Notes:
Silicon-IPTV-Broadcast -354
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
My ISP
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
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
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
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
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
Notes:
Silicon-IPTV-Broadcast -367
Multicast Advantages
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -368
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
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
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
Range
224.0.0.0/24
224.0.1.0 to 238.255.255.255
232.0.0.0/8
GLOP Addresses
233.0.0.0/8
239.0.0.0/8
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -372
Notes:
Silicon-IPTV-Broadcast -372
Address
Usage
224.0.0.1
224.0.0.2
224.0.0.5
OSPF routers
224.0.0.6
224.0.0.12
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -377
Notes:
Silicon-IPTV-Broadcast -377
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 addressestheir 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
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
environmentCisco 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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -382
Notes:
Silicon-IPTV-Broadcast -382
Multicast Concepts
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -383
Notes:
Silicon-IPTV-Broadcast -383
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -384
Notes:
Silicon-IPTV-Broadcast -384
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 modethe receiver announces membership to a host group
It provides a list of source addresses known as the INCLUDE list
EXCLUDE modethe 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 modeIn 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 modeIn 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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -387
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
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
Notes:
Silicon-IPTV-Broadcast -389
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -390
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -392
Notes:
Silicon-IPTV-Broadcast -392
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
Notes:
Silicon-IPTV-Broadcast -393
Manipulating IGMP
access-group
helper-address
join-group
last-member-query-interval
querier-timeout
query-interval
query-max-response-time
static-group
unidirectional-link
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -395
Notes:
Silicon-IPTV-Broadcast -395
To control which version of IGMP the router uses, use the following
command in interface configuration mode:
ip igmp version {2 | 1}
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -397
Notes:
Silicon-IPTV-Broadcast -397
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -403
Notes:
Silicon-IPTV-Broadcast -403
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -405
Notes:
Silicon-IPTV-Broadcast -405
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -406
Notes:
Silicon-IPTV-Broadcast -406
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -407
Notes:
Silicon-IPTV-Broadcast -407
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -409
Notes:
Silicon-IPTV-Broadcast -409
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -410
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 its TTL is checked against the TTL Threshold. If the
packets 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
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
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
Notes:
Silicon-IPTV-Broadcast -415
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -416
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 directorys 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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -421
Notes:
Silicon-IPTV-Broadcast -421
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
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
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 sources first hop router to inform it that it can stop
sending the unicast Register messages.
Notes:
Silicon-IPTV-Broadcast -424
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
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
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
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
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
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
Notes:
Silicon-IPTV-Broadcast -431
Conclusion
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -432
Notes:
Silicon-IPTV-Broadcast -432
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
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
Single active RP exists per multicast group with multiple backup RPs
Multiple active RPs for the same group in PIM Version 1
PIM Join and Prune messages have more flexible encodings for multiple
address families
Silicon-IPTV-Broadcast -435
Notes:
Silicon-IPTV-Broadcast -435
ip pim version [1 | 2]
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -436
Notes:
Silicon-IPTV-Broadcast -436
Bootstrap routers (BSR) hold list of multicast groups that are reachable
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -437
Notes:
Silicon-IPTV-Broadcast -437
Silicon-IPTV-Broadcast -438
Notes:
Silicon-IPTV-Broadcast -438
Silicon-IPTV-Broadcast -439
Notes:
Silicon-IPTV-Broadcast -439
Using Auto-RP
Multiple RPs can be used to serve different group ranges or serve as hot
backups of each other
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
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
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)
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -442
Notes:
Silicon-IPTV-Broadcast -442
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -443
Notes:
Silicon-IPTV-Broadcast -443
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
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
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
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
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -452
Notes:
Silicon-IPTV-Broadcast -452
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
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
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
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
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
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
Silicon-IPTV-Broadcast -460
Notes:
Silicon-IPTV-Broadcast -460
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
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
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
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 <ttl-value>
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
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
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
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
Presentation
Checkpoints and
Activities
Session
Transport
Routing
Network
Detects Errors
Data Link
Moves Bits
Physical
Provides application
services
Provides data
representation
Provides checkpointing,
activity management
Provides end-to-end
data integrity
Manages communication
between adjacent nodes
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
Application
Presentation
Session
Transport
Application
Application
Presentation
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
Application
Presentation
Session
Transport
Application
Application
Presentation
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
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
Notes:
Silicon-IPTV-Broadcast -475
IPS Layer
Application
End-to-end
OSI Layer
SMTP
Simple
Mail
Transfer
Protocol
FTP
TELNET
virtual
terminal
File
Transfer
Protocol
5, 6, 7
User Datagram Protocol (UDP)
ICMP
Internetwork
SNMP
3
ARP
Physical
network
Etc.
Packet
radio
X.25
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
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
SNMP
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -479
Notes:
Silicon-IPTV-Broadcast -479
Paul
George
Ringo
Paul
Peter
Mary
Silicon-IPTV-Broadcast -480
Notes:
Silicon-IPTV-Broadcast -480
0
standards
ccitt
iso
joint-ccitt-iso
org (identified organizations)
1.3.6.1 internet
1.3.6.1.1 directory
1.3.6.1.2 mgmt
dod
internet
1.3.6.1.3 experimental
1.3.6.1.4 private
mgmt
1.3.6.1.5 security
1.3.6.1.6 SNMPv2
mib-2
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
Internet
Directory
Management
MIB
Experimental
18
20
PPP
RS-232
11
SNMP
10
8
1
System
Interfaces
6
3
AT
5
4
ICMP
Private
TCP
UDP
Transmission
Enterprises
EGP
2
IBM
36
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
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
Notes:
Silicon-IPTV-Broadcast -484
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
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
Notes:
Silicon-IPTV-Broadcast -486
system
at
icmp
udp
MIB-2
10
14
17
ospf
transmission
etc.
bridge . . . etc. . .
11
16
interfaces
ip
tcp
egp
snmp
rmon
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
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
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
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
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
SNMP
Chapter Summary
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -493
Notes:
Silicon-IPTV-Broadcast -493
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
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
Notes:
Silicon-IPTV-Broadcast -495
SNMP Messages
SNMP uses a simple fetchstore 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
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
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
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
se
espon
GetR
Manager
S et R
Agent
eques
PDU
Manager
Agent
DU
Trap P
t PDU
se PD
espon
GetR
Agent
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -502
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
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
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
Instance
sysContact
Type
Value
DisplayString
Groucho Marx
ifIndex
Type
Value
Instance 1 Integer
Instance 2 Integer
ifDescr
Type
ifType
Value
Type
ifMtu
Value
Type
...
Value
...
Integer 1500
...
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
Index
Index
Index
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
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
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
22
i pNe tToMed i a I f I ndex i pNe tToMed i aPhysAddr ess i pNe t ToMed i aNe tAdd ress
00 0 0 c0 c5 ed 9 1
144 . 19 . 7 4 . 5
00 0 0 c0 10 c e 7 0
144 . 19 . 7 4 . 6
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -515
Notes:
Silicon-IPTV-Broadcast -515
SNMP Messages
SNMP messages have the following format:
SNMP-Message ::= SEQUENCE {
data
ANY}
Authentication
SNMP message
version_1(1)
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -521
Notes:
Silicon-IPTV-Broadcast -521
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -524
Notes:
Silicon-IPTV-Broadcast -524
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.512 Mbit/s down,
16640 kbit/s up
Distance
Application
T1/E1 replacement
SDSL
1.52.0 Mbit/s,
symmetric
VDSL
VDSL2
100Mbit/s +
Silicon-IPTV-Broadcast -527
Notes:
Silicon-IPTV-Broadcast -527
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
Notes:
Silicon-IPTV-Broadcast -529
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
Source
Address
TPID
Ether-Type/
Length
Priority CFI
Payload
VID
CRC
Normal 802.3
Frame
TCI
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
Traffic Type
Background
Spare
Best Effort
Excellent Effort
Controlled Load
Video
Voice
Network Control
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
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
Label
added
LSR
LSR
17
Layer 3
17
Label
removed
LSR
15
15
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
D est
4 7 .1
4 7 .2
4 7 .3
Routing Table
D est
4 7 .1
4 7 .2
4 7 .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
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
Intf
In
3
Request: 47.1
.1
t: 47
ues
q
3
e
R
47.3 3
2
Ma
g:
ppin
0
0 .5
1
2
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
Notes:
Silicon-IPTV-Broadcast -538
Intf
In
3
IP 47.1.1.1
1 47.1
3
2
1
1
47.3 3
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
Dest
47.1.1
47.1
Intf
Out
2
1
Label
Out
1.33
0.50
Intf
In
3
3
2
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
1
Network Layer Header
and Packet (eg. IP)
Layer 2 Header
(eg. PPP, 802.3)
4 Octets
Label Stack
Entry Format
Label
Exp.
TTL
MPLS
MPLSon
onPPP
PPPlinks
linksand
andLANs
LANsuses
usesShim
ShimHeader
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
Notes:
Silicon-IPTV-Broadcast -543
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
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
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
Big is beautiful!
2
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -549
Notes:
Silicon-IPTV-Broadcast -549
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -550
Notes:
Silicon-IPTV-Broadcast -550
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.
Heres Ciscos 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
Path message
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -557
Notes:
Silicon-IPTV-Broadcast -557
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -561
Notes:
Silicon-IPTV-Broadcast -561
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
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
BB
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
BB
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -568
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -571
Notes:
Silicon-IPTV-Broadcast -571
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -573
Notes:
Silicon-IPTV-Broadcast -573
Youre
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -575
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 knownport is 5060. This is used to pass signaling messages
between servers.
Notes:
Silicon-IPTV-Broadcast -576
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
home.net
Bestneutral.com
Copyright: All rights reserved. Not to be reproduced without prior written consent.
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
Alices SIP phone
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
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
H.248.1
H.248, Annex F
H.248.2
H.248, Annex G
H.248.3
H.248, Annex H
H.248.4
H.248, Annex I
H.248.5
H.248, Annex J
H.248.6
H.248, Annex K
H.248.7
H.248, Annex L
H.248.8
H.248.9
H.248, Annex
M.2
H.248.10
H.248.11
H.248.12
H.248.13
H.248.14
H.248, Annex N
H.248.15
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -583
Notes:
Silicon-IPTV-Broadcast -583
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
Decoders and
Transcoders
VoD
Server
Management
and
Control
system
Streamers
Core
Internet
Access
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -586
Notes:
Silicon-IPTV-Broadcast -586
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
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
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
Silicon-IPTV-Broadcast -590
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
Silicon-IPTV-Broadcast -591
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
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
Decoders and
Transcoders
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
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
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
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
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
Silicon-IPTV-Broadcast -601
Notes:
Silicon-IPTV-Broadcast -601
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
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
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
Notes:
Silicon-IPTV-Broadcast -606
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -607
Notes:
Silicon-IPTV-Broadcast -607
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -608
Notes:
Silicon-IPTV-Broadcast -608
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -609
Notes:
Silicon-IPTV-Broadcast -609
Silicon-IPTV-Broadcast -610
Notes:
Silicon-IPTV-Broadcast -610
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
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -616
Notes:
Silicon-IPTV-Broadcast -616
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -617
Notes:
Silicon-IPTV-Broadcast -617
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
Silicon-IPTV-Broadcast -619
Notes:
Silicon-IPTV-Broadcast -619
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
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
Silicon-IPTV-Broadcast -622
Notes:
Silicon-IPTV-Broadcast -622
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -624
Notes:
Silicon-IPTV-Broadcast -624
Silicon-IPTV-Broadcast -625
Notes:
Silicon-IPTV-Broadcast -625
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -626
Notes:
Silicon-IPTV-Broadcast -626
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -630
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
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
Notes:
Silicon-IPTV-Broadcast -631
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -632
Notes:
Silicon-IPTV-Broadcast -632
Silicon-IPTV-Broadcast -633
Notes:
Silicon-IPTV-Broadcast -633
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.
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
Symmetric
Asymmetric
Speed
Faster
Slower
Secret information
Shared Key
Private Key
Key length
Shorter
Longer
Key Period
Shorter
Longer
Major Problem
Key Distribution
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -638
Notes:
Silicon-IPTV-Broadcast -638
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -639
Notes:
Silicon-IPTV-Broadcast -639
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -640
Notes:
Silicon-IPTV-Broadcast -640
Silicon-IPTV-Broadcast -641
Notes:
Silicon-IPTV-Broadcast -641
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -651
Notes:
Silicon-IPTV-Broadcast -651
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
Silicon-IPTV-Broadcast -654
Notes:
Silicon-IPTV-Broadcast -654
Silicon-IPTV-Broadcast -655
Notes:
Silicon-IPTV-Broadcast -655
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -656
Notes:
Silicon-IPTV-Broadcast -656
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -657
Notes:
Silicon-IPTV-Broadcast -657
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -658
Notes:
Silicon-IPTV-Broadcast -658
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
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
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
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
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -670
Notes:
Silicon-IPTV-Broadcast -670
Yospace.com
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Silicon-IPTV-Broadcast -671
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