IPTV Course

IPTV Broadcasting, Protocols
and Switching
Notes:
Silicon-IPTV-Broadcast -1
Course Objectives
When you have completed this course you will be able to
Understand the equipment and software used to deliver IPTV and VoD services
Describe the architecture of a these modern TV services
Compare Cable, over-air terrestrial, satellite and Internet delivery systems
Appreciate the trend in the technologies
Understand addressing schemes for IP network prefix configurations
Examine resilience for MAC/IP mappings for reliable redundancy switching
Select the best routing and switching strategy for server and delivery networks
Analyze protocols used to carry multimedia and troubleshoot services problems
Appreciate how multicast routing protocols function
Specify requirements for firewall transit of video services
Compare how DiffServ, DSCP, RSVP, WFQ, MPLS and 802.1P/Q can provide quality
of service
Select the most appropriate quality of service option
Copyright: All rights reserved. Not to be reproduced without prior written consent.
Notes:
Course Materials
Course Notes
Copies of all slides and supplemental presentation material
Notes:
Course Contents
Chapter 1
Television Architecture and Evolution
Chapter 2
Broadband Distribution Systems
Chapter 3
IP Delivery of Multimedia Services
Chapter 4
Layer 2 Addressing
Chapter 5
Layer 3 Addressing
Chapter 6
Routing
Chapter 7
Multicasting
Chapter 8
Management of Devices With SNMP
Chapter 9
Next Generation Network Technology
Chapter 10
Customer Home Network
Chapter 11
Industry Trends
Chapter 12
Summary and Evaluation

Notes:
Course Schedule
Each day, the course will follow this schedule:
Start class
9 a.m.
Morning break
10:15 a.m. (approximately)
Lunch
Noon
Resume class
1 p.m.
Afternoon break(s)
As needed
Adjourn
4:30 p.m.
Notes:
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
Notes:
Course Instructor
Background and education
Current position
Experience
Notes:
Attendee Introductions
Your name
Organization name
Current position
Experience in: Television Technology
Networking and LANs
Telecommunications Technology
Expectations
Notes:
Chapter 1
Television Architectures and

Evolution
Notes:
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
Notes:
Television Architectures and Evolution
What is Television Today?

Analogue and Digital Compared
Delivery Systems: What are they
Chapter Summary
Notes:
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
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:
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
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:
Mixing Colours
Primary colours can be mixed in proportion to form white
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:
The Colour Pallet
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:
Forming Television Picture Colour Test Pattern
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:
PAL D1 test Pattern
On CRT displays it is difficult to maintain straight lines and focused colour

mapping. Modern flat panel display systems are able to maintain this with less
difficulty.
Notes:
Widescreen
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:
Digital Image Standards Compared
Improving the resolution and interlacing, displaying alternate lines in consecutive

frames, provide better picture quality. Interlacing delivers better movement quality
with limited increase in transmission bandwidth and complexity.
Notes:
Resolutions
Horizontal Vertical
Pexils
RGB Color Detail %
Television:
NTSC
427
525
224,175
100/100/100
HDTV
1050
600
630,000
100/100/100
VGA
640
480
307,200
100/100/100
SVGA
800
600
480,000
100/100/100
Computer:
Camera:
One Mega
1280
960
1,228,800
25/50/25
Two Mega
1600
1200
1.920,000
25/50/25
Three Mega
2048
1536
3,145,728
25/50/
Resolution means picture sharpness and is measured in lines of horizontal resolution.

If you looked through a window with a giant Venetian blind and could observe a distant ladder and
count 625 rungs on that ladder, then you could say you had a vertical resolution of 625 lines. If you
couldn't count the rungs, because they were fuzzy or blocked by the slats of the Venetian blind, you
would have less than 625 lines of vertical resolution. You could have someone bring the ladder
closer and eventually you could count all the rungs. In reality we have 575 not 625 visible lines.
It would seem that 575 scan lines would give you a vertical
resolution of 575 discernable lines on our ladder. This is not really the case. If one scan line
displayed one rung, the next scan line would need to show the space between the rungs, and the
following line would show the next rung in order for the
rungs on the ladder not to merge together. Put another way, if each scan line saw a rung, then the
ladder would look like it was made of solid rungs with no spaces. Thus, an image that goes "rungspace-rung-space" is defined as 4 lines of vertical resolution and it took four scan lines to do it.
Thus, 575 scan lines can show only 288 actual rungs on the ladder, but still the TV industry still calls
the vertical resolution 625 lines!
I have oversimplified. The vertical resolution available from 575 scan lines calculates to .7 x 575 =
403 lines of resolution. Why the .7? Imagine for a moment that you looked
through your Venetian blind at the ladder and could see all the rungs inbetween the slats. Now if you
moved your head up just a little bit, all of the rungs would be hidden behind the slats and you would
see only the spaces between the rungs, erroneously
coming to the conclusion that the ladder had no rungs.
Notes:
PAL
SYSTEM
Line/Field
Horizontal
Frequency
Vertical
Frequency
Colour Sub
Carrier
Frequency
Video Bandwidth
Sound Carrier
PAL
B,G,H
625/50
15.625
kHz
50 Hz
PAL I
PAL D
PAL N
PAL M
625/50
15.625
kHz
625/50
15.625
kHz
625/50
15.625
kHz
525/60
15.750
kHz
50 Hz
50 Hz
50 Hz
60 Hz
4.433618 4.433618 4.433618 3.582056 3.575611

MHz
MHz
MHz
MHz
MHz
5.0 MHz
5.5 MHz
5.5 MHz
6.0 MHz
6.0 MHz
6.5 MHz
4.2 MHz
4.5 MHz
4.2 MHz
4.5 MHz
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:
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
Asp.
ratio
16/9
freq.
MHz
8
4/3
4.2
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:

Chapter Summary
Notes:
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
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:
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
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:
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
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:

Chapter Summary
Notes:
Television Broadcasting Industry
Programme
Production
Film
News
TV Production
Content
Channels
Marketing and Delivery
Entertainment
Government and Politics
Religion
Education
Community
Distribution
Over-the-air
Cable
Satellite
Internet and IP
Delivery
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:
Architecture of Cable TV Distribution
Programme
Production
Film
News
TV Production
Content
Channels
Entertainment
Government and Politics
Religion
Education
Community
Distribution
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:
Cable Distribution System
In a modern cable network other non-TV services might be added. In particular

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

Expanded services are those that go beyond the distribution of TV
programs
Provision of Telephony services
Information services
Internet access
Interactive Gaming
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:
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
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:
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
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:
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
In the end all services can be viewed in one way or another as information.
Notes:
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
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:

Chapter Summary
Notes:
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
Notes:
Chapter 2
Broadcast Distribution Systems
Notes:
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
Notes:
Cable TV Delivery Systems

Terrestrial Delivery
IP Delivery
Encoding Methods
Chapter Summary
Notes:
Components of a Cable TV System

Interface to programme,
channel and content
suppliers
Set-top box for

conditional access,
interfacing
and decoding
Headend: Control,
switching, encoding and
management
Fiber and coax

cable distribution
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:
Traditional Cable TV Head End Components
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:
Enhanced Cable TV Network Services
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:
Enhanced Head End
Internet
Network
Access
Extra
Channels
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:
Multiple Cable Operators
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:
Interconnected Head Ends
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:
SDH Connected Head Ends
Internet
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:
Head End Signal Reception

Digital Satellite Receiver
Encrypted and Direct Video Broadcast (DVB) modes of operation
3 to 40 Mbit/s operation
Advanced Serial Interface (ASI) input and output
Most advanced units now support Gigabit Ethernet instead
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:
Encoding and Trans-coding

An important part of the Headend function is encoding TV signals
Feeds may arrive in one satellite modulation format and be re-coded to
another for more efficient onward transmission
NTSC feeds may be converted to PAL
Encoding of analogue to MPEG-2 or even MPEG-4 may be required
The selection of the vendor for headend equipment is often based upon
the quality of such codecs and trans-coding
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:
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
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:
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
European companies currently lead the world in TV control systems. TANDBERG

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

The goal of design is to deliver good signal levels to each consumer
Cables, taps, splitters and combiners cause loss
Amplifiers increase signals but also add noise
Signal to noise ratio limits demodulation and thus the size of system
Device
Loss (-dBmV)
2-Way Splitter/Combiner
4.0
6.5
8.0
12.0
100 ft RG6
4.0
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:
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
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:
Migration to Digital Fiber Systems

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

Transmitter
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:
Fiber Optic Transmission
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:
Fiber Types
Step Index Multimode Fiber
Graded Index Multimode Fiber
Single Mode Fiber
GRADED-INDEX MULTIMODE FIBER contains a core in which the refractive

index diminishes gradually from the center axis out toward the cladding. The higher
refractive index at the center makes the light rays moving down the axis advance
more slowly than those near the cladding. Also, rather than zigzagging off the
cladding, light in the core curves helically because of the graded index, reducing its
travel distance. The shortened path and the higher speed allow light at the periphery
to arrive at a receiver at about the same time as the slow but straight rays in the core
axis. The result: a digital pulse suffers less dispersion.
SINGLE-MODE FIBER has a narrow core (eight microns or less), and the index of
refraction between the core and the cladding changes less than it does for
multimode fibers. Light thus travels parallel to the axis, creating little pulse
dispersion. Telephone and cable television networks install millions of kilometers
of this fiber every year.
Notes:
Fiber Connectors
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:
Fiber Cables
Indoor/Outdoor Tight Buffer
Indoor/Outdoor Breakout Cable
Aerial Cable/Self-Supporting
Armored Cable
Indoor/Outdoor Tight Buffer

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

Historically transmission at 1310 nm dominated
Characteristics of dispersion at 1500 nm needed addressing
Attenuation
Standard Single-mode fiber

Dispersion
+20
0.5
+10
0.4
0.3
-10
DWDM
0.2
-20
1300
1400
1500
Wavelength (nm)
Dispersion (ps/nmxkm)
Attenuatiom (dB/km)
0.6
1600
Single Channel Transmission at 1330 nm

The three principal windows of operation, propagation through a cable, are

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

Traditional fiber connection requires at least one fiber per subscriber
Couplers at each end attach transceiver
Heavy on fiber and transceiver costs but resilient solution
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:
Active Fiber Distribution

Active distribution can significantly reduce fiber costs
Less fiber and fewer transceivers
Active plant outside local exchange reduces resilience
Last half Kilometre could be Copper

Or fiber
To do a proper selection of a commercially available Transmitter you have to be

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

Advanced splitters divide on wavelength
Only passive components as outside plant
All Fiber with different wavelengths for each subscriber
Eventually it should be possible to deliver a fully passive optical solution. Each

distribution would be over a different wavelength controlled optically at a passive
splitter using a control wavelength. This would deliver two way channels to each
user if required enabling not just TV but interactive information services at multimegabit speeds.
Notes:
Technology: Active Ethernet and PON
Considerations:
CAPEX/OPEX, Reliability, Standardization, Scalability, Futureproofing
Notes:
Standard Single Mode Fiber Profile

Historically transmission at 1310 nm dominated
Characteristics of dispersion at 1500 nm needed addressing
Attenuation

Dispersion
+20
0.5
+10
0.4
DWDM
0.3
-10
0.2
-20
1300
1400
1500
Wavelength (nm)
Attenuatiom (dB/km)
0.6
1600
Single Channel Transmission at 1330 nm

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:
Actual Fiber Performance
1600
G bit/s per fiber
800
400
200
100
Optimal Operating
Region
Actual Single Mode Fiber

Performance
Bit Rate < 10 Gbit/s
Unamplified
2.5
10
100
500
2000
10000
Transmission Distance in km
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:
Fiber for Course Wavelength Division Multiplexing (CWDM)
Attenuation
Dispersion
+20
SSMF
0.5
+10
0.4
0.3
-10
LWPF
0.2
1300
1400
1500
Wavelength (nm)
-20
Attenuatiom (dB/km)
0.6
1600
Low Water Peak Fiber allows CWDM over full available spectrum
By using different wavelengths of light down the same fiber it is possible to

increase the data carried.
Course Wavelength Division Multiplexing can be undertaken on most fibers, and
by improving the water peak up to about 8 wavelengths can be carried.
Notes:
Long Haul Fiber With Dense WDM
Attenuation

Dispersion
+20
0.5
+10
0.4
0.3
0.2
-10
Long Haul
Fiber
1300
-20
1400
1500
Wavelength (nm)
Attenuatiom (dB/km)
0.6
1600
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:
ITU-T Standard Spacing for DWDM Channels

There is now an ITU-T standard for DWDM with 240 different wavelengths
Standard ITU Wavelengths for DWDM 50 GHz, and 100 GHz Spacing
L
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
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:
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
SDH (ITU)
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:
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
SDH networks can be constructed from many SDH components.

Synchronous Add/Drop multiplexers can insert and remove synchronous payloads
as multiples of E1, E2, E3 or E4 as required. These would be dropped initially into
STM-1 or STM-4 services.
Wideband multiplexers can combine STM-1s and lower rates into STM-4 services
at 622 Mbit/s.
Broadband multiplexers can then combine STM-4s into STM-16s.
Notes:
Network Topologies
Point-to-Point
T1
T3
ADM
(terminal mode)
ADM
(terminal mode)
T1
T3
Dial Single Mode Fiber
Bus
Add Drop Multiplexers can add in and drop off SPEs as required
T1
T3
ADM
(terminal mode)
ADM
T3
ADM
(terminal mode)
T1
T3
T1
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:
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
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:
Automatic Protection Switching

SONET/SDH includes standardized mechanisms for Automatic Protection
Switching (APS)
Benefits of APS
Faster restoration of service when failure occurs (or service deteriorates)
Optical path may be severed
Electronic equipment may fail or lose power
Standardization allows APS in a multivendor environment
Protection switching may be used during maintenance or testing
APS requires a pre-provisioned protection facility (backup route)
Operates using section (multiplexer section) APS channels
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:
Self Healing Rings
Alarm !
Working
backup
No data
Data
Break
Data
Fiber Break Causes Alarm
Normal Operation
APS
APS
Automatic Rerouting Re-establishes Service

With APS implemented throughout a ring it is possible to produce self healing

rings. Typically a network would be constructed by interconnecting these self
healing rings at two or more points so producing networks which have multiple
paths between sites each able to offer highly reliable services.
Notes:

IP Delivery
Encoding Methods
Chapter Summary
Notes:
Over-The Air Broadcasting

Transmissions are sent over radio links
Generally dedicated licensed channels in the VHF or UHF Bands
Range is limited to line of sight
Over flat terrain may be 50 km
In hilly or mountainous areas
range my be only a few km
Multiple frequencies used
to deliver each channel in adjacent areas
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:
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
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:
DVB-T Services Mux 1 and 2

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

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

Multiplex C
Operated by National Grid Wireless; broadcasts nationwide in 16QAM mode
at 18 megabits/second
TV: Sky Three, UKTV History, E4+1, SmileTV, Sky News, Sky Sports News
Radio: talkSPORT, 3C, Premier Christian Radio, Virgin Radio
Text/Interactive: Sky Text, TVTV Digital
Multiplex D
Operated by National Grid Wireless; broadcasts nationwide in 16QAM mode
at 18 megabits/second
TV: The Hits, UKTV Bright Ideas, Ftn, TMF, Ideal World, Film4, ITV Play
Radio: BBC World Service, The Hits Radio, Smash Hits, Kiss 100, Magic
105.4, Q, Oneword, 102.2 Smooth FM, Kerrang!
Text/Interactive: 4TVInteractive
* Pay TV Services
Notes:
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
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:
LCN1
Channel
Notes
Multiplex
BBC One
Includes regional variations
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
In Central and Northern Scotland2
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
Scotland only; broadcasts 1800-1900
BBC Four
10
ITV3
11
Sky Three
12
UKTV History
13
More4
14
E4
15
ABC1
Not available in Wales; broadcasts 0600-1800
16
QVC
Reduced hours in Wales (not broadcast 0900-1700 Tuesday-Thursday)
2
C
Logical Channel Number

ITV1 is the brand name for 12 of the 15 regional ITV Network franchises for
England, Wales, southern Scotland, the Isle of Man and the Channel Islands. Each
of these 12 franchises has a separate brand name used prior to local programming,
see ITV1. STV is the brand name for the franchises for central and northern
Scotland. UTV operates the franchise for Northern Ireland. All 15 franchises
broadcast 0925-0600; GMTV operates the franchise for national breakfast
television and broadcasts 0600-0925.
Five, S4C and S4C2 will move to a public service multiplex at the start of digital
switchover, using the bandwidth created by switching from 16QAM to 64QAM
mode, so will be transmitted from all 1,154[7] UK transmitters. Multiplexes A, C
and D will only be transmitted from the current 80 transmitters after switchover but
with higher powered signals (and in 64QAM mode).
Notes:
17
UKTV Gold
18
The Hits
Top Up TV; broadcasts 1600-0100
19
UKTV Bright Ideas
20
Ftn
21
TMF
22
Ideal World
23
bid tv
24
price-drop tv
25
TCM
26
UKTV Style
27
Discovery Channel
28
ITV4
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
37
SmileTV
D
D
Reduced hours in Wales (only broadcasts 0600-1900)
A
A

Notes:
38
Top Up TV Anytime 1
Subscription service; not yet launched
39
Top Up TV Anytime 2
40
Top Up TV Anytime 3
42
Discovery Real Time
43
Top Up TV Promo
Not yet launched
70
CBBC Channel
71
CBeebies
72
Cartoon Network
75
CITV Channel
Broadcasts 0600-1800; not broadcast while Setanta Sports 1 is on air
80
BBC News 24
81
BBC Parliament
82
Sky News
83
Sky Sports News
86
S4C2
Wales only; broadcasts 0900-1700 Tuesday-Thursday
A3
87
Community Channel
88
Teachers' TV
97
Television X
Top Up TV (additional subscription); broadcasts 2300-0500
98
Red Hot TV
Pay-per-view service; placeholder (no longer broadcasting)
501
BBC HD Trial
BBC High Definition Test Channel; London only
CH31
503
ITV HD Trial
ITV High Definition Test Channel; London only
CH27
504
Channel 4 HD Trial
C4 High Definition Test Channel; London only
CH27
505
Five HD Trial
Five High Definition Test Channel; London only
CH27

Notes:
DVB-T Testing in Ireland

Multiplex 1
Reserved for existing terrestrial services
Television
RT One, RT Two, TV3 Ireland, TG4
Radio
RT Radio 1 FM, RT Radio 1 AM, RT 2FM, Raidi na Gaeltachta, RT
Lyric FM, Today FM
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:
Wireless Standards
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:
Multipoint Distribution Services

Two versions of MDS have evolved:
LMDS Local MDS
Single-duplex channel to a local hub
Generally uses 28, 35, 38 GHz bands
Can provide high speed data where wired infrastructure is inadequate
Typical range: 58 km
MMDS Multichannel MDS
Multiple simplex or duplex channels to a local hub
Generally employed in 2.4, 5 GHz bands
CATV distribution over MMDS
Typical range: 55 km
Wimax: IEEE 802.16 is addressing physical/MAC layer, and frequency
coexistence standards
In the USA and Canada wireless local loop technologies have been used for some
time.
Notes:
Example MMDS System

Omni transmit
antenna
LNB
Satellite
Receivers
HPA
Decoder
Modulation &
Encryption
Tree top
House top
Receive Antenna
(may be omni or
directional)
Decoded
Receiver
Frequency
Translation
HPA = High Power Amplifier

LNB = Low Noise Block Convector
Notes:
Typical Wireless Loop Installation
av
ow
icr
RST
System
controller
RST
RST
Fiber
Local Concentrator
exchange
Cell
site
System Cell
controller site
Fax machine
RST = radio subscriber terminal
Notes:
Existing Technologies
Some suppliers use cellular equipment to provide wireless loops
Vendor
Product
Alcatel
7390 LMDS
AT&T
Wireless Subscriber System
Nokia
DAXnode 2000
Ericsson
RAS 1000
Motorola
WiLL
Northern Telecom
DMS-MTX and 800
Most major telecom vendors have developed wireless loop technologies. However
these are converging onto a common future set of standards.
Notes:
Licensed and Licensed-exempt Spectrum
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:
IEEE 802 LANs

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

802.1 Management
802.10 Security
IEEE founded the 802 committee to standardize LANs in 1980
Data
802.1d Bridging
Link
Layer
802.3
802.4
802.5
802.6
CSMA/CD
Token
Token
DQDB
Bus
Bus
Ring
MAN
802.11
Wireless
LAN
802.16
WiMAX
Wireless
Access
802.20
Wireless
Broadband
Physical
Layer
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:

IP Delivery
Encoding Methods
Chapter Summary
Notes:
Set Top Boxes

Set top boxes are evolving to increase their functionality
Initially they provided
Cable Decoder
Free to air Digital
Combination
with Personal
Video Recorder
with HDD
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:
European Telecommunications Standards Institute
European Standards
Mobile Phone (GSM/UMTS)
Tracks 3GPP
Fixed Line Standards
IP Multimedia Services (IMS)
TISPAN for fixed
DVB
Standards download free!
The European Telecommunications Standards Institute (ETSI) is an independent,

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

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

Advanced Networking (TISPAN)
TISPAN specifies a Next Generation Network which:
Offers standardised multimedia services based on xDSL
Uses the 3GPP IMS for service handling, ensuring FMC
Supports legacy POTS services (PSTN/ISDN Emulation)
Same as the PSTN/ISDN Telephony service over an IP infrastructure
Enables use of ISDN Supplementary services and phone at home
So NGN will replace the soon becoming obsolescent PSTN
Supports a set of fully-defined Supplementary Services (Simulation)
including Voice
Similar - but not identical - to existing PSTN service
Based on IMS capabilities
TISPANs specific needs to accommodate Wireline access to IMS are
covered by a collaboration between TISPAN and 3GPP: TISPAN-specific
IMS extensions are prepared in TISPAN and proposed for inclusion to
3GPP IMS Rel-7. Joint meetings between TISPAN and 3GPP.
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:
Role of ETSI-TISPAN
TISPAN defines:
The Fixed Core Network
TISPAN addresses
Fixed-access impacts
on 3GPPs IMS
IMS
HSS
FIXED
MOBILE
xDSL
To meet the rising demands relative to IP multimedia applications, the 3rd

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

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

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

Video
IPTV with MPEG2 compression
Standard Definition
High Definition
IPTV with MPEG4 compression
Standard Definition
High Definition
3.5 - 4.5 Mbps

12 -19.3 Mbps
1.5 - 2.0Mbps
5.0 - 8.0Mbps
Access speeds for triple play might need to reach double the aggregate
How fast would access need to be?
Most locations cannot achieve this over long copper loops
Need to replace with fiber loops or accept lower quality
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:
Centralized Architectures?
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:
Distributed Architectures?
By delivering video content regionally or even closely coupled to the access it

becomes less necessary to carry large numbers of VOD sessions over the core. A
centralized storage of content for long-term access could still be of benefit but
would be transferred to regional or local servers for multiple local access.
Notes:
Network Dimensioning Is Critical
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:
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
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:
Winamp
Notes:
Video LAN Client
Notes:
Microsoft Media Player
Notes:

IP Delivery
Encoding Methods
Chapter Summary
Notes:
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
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:
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
There are multiple forms of compression available. These have evolved

independently in many cases. We will examine static images first and then MPEG2
which will include many of the sound compressions elements used then we will
examine MPEG4 and H.264. Finally we will address MPEG7 for completeness.
Notes:
JPEG Compression: Basics

Human vision is insensitive to high spatial frequencies
JPEG Takes advantage of this by compressing high frequencies more
coarsely and storing image as frequency data
JPEG is a lossy compression scheme.
Losslessly compressed image, ~150KB
JPEG compressed, ~23KB
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:
GIF 89a examples vs. JPEG
GIF Image, 7.5KB,

optimal encoding
JPEG, blotchy spots in single-color

areas
Notes:
JPEG Compression Rates
67k
37k
27k
22k
Notes:
Wavelet Image Compression

Optimal for images containing sharp
edges, or continuous curves/lines (fingerprints)
Compared with DCT, uses more
optimal set of functions to
represent sharp edges than cosines.
Wavelets are finite in extent as
opposed to sinusoidal functions
Several different families of wavelets.
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:
Wavelet Transforms
Wavelet transforms comprise an infinite set
Wavelet subclasses distinguished by the number of coefficients
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:
Wavelet vs. JPEG compression
Wavelet compression
file size: 1861 bytes
compression ratio - 105.6
JPEG compression
file size: 1895 bytes
compression ratio - 103.8
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:
Wavelet compression advantages
Fourier basis functions, time-frequency

tiles, and coverage of the timefrequency plane.
Daubechies wavelet basis functions, timefrequency tiles, and coverage of the timefrequency plane
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:
MPEG Compression Protocols

MPEG-1 ISO/IEC JTC1/SC29/WG11 ISO 11172 parts 1 to 4
MPEG-3 abandoned but audio encoding
MPEG-4 ISO/IEC JTC1/SC29/WG11 N4668
MPEG-7 ISO/IEC JTC1/SC29/WG11N6828
Adds descriptions language for multimedia
MPEG-21 ISO/IEC JTC1/SC29/WG11/N5231
Adds digital rights management
Moving Picture Experts Group (MPEG) a working group of ISO/IEC in charge of

the development of standards for coded representation of digital audio and video.
Established in 1988, the group has produced MPEG-1, the standard on which such
products as Video CD and MP3 are based, MPEG-2, the standard on which such
products as Digital Television set top boxes and DVD are based, MPEG-4, the
standard for multimedia for the fixed and mobile web and MPEG-7, the standard
for description and search of audio and visual content. Work on the new standard
MPEG-21 "Multimedia Framework" has started in June 2000. So far a Technical
Report and two standards have been produced and three more parts of the standard
are at different stages of development. Several Calls for Proposals have already
been issued
Notes:
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
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:
MPEG2 Standard Parts

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

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

pictures and associated audio information -- Part 6: Extensions for DSMCC (available in English only)
ISO/IEC 13818-6:1998/Amd 1:2000 Additions to support data broadcasting
ISO/IEC 13818-6:1998/Amd 2:2000 Additions to support synchronized
download services, opportunistic data services and resource
announcement in broadcast and interactive services (available in English
only)
pictures and associated audio information -- Part 7: Advanced Audio
Coding (AAC) (available in English only)
Notes:

pictures and associated audio information -- Part 9: Extension for real time
interface for systems decoders (available in English only)
pictures and associated audio information -- Part 10: Conformance
extensions for Digital Storage Media Command and Control (DSM-CC)
Notes:
Part 1 of MPEG2
Part 1 of MPEG-2 addresses the combining of one or more elementary streams of

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

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

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

Human hearing limited to values lower than ~20kHz in most cases
Human hearing is insensitive to quiet frequency components to sound
accompanying other stronger frequency components
Stereo audio streams contain largely redundant information
MPEG audio compression takes advantage of these facts to reduce extent
and detail of mostly inaudible frequency ranges
Notes:
MPEG-Layer3 Overview
MP3 Compression Flow Chart

Notes:
MPEG Layer-3 performance
sound quality
bandwidth
mode
bitrate
reduction ratio
telephone sound
2.5 kHz
mono
8 kbps *
96:1
better than short

wave
4.5 kHz
mono
16 kbps
48:1
better than AM radio
7.5 kHz
mono
32 kbps
24:1
similar to FM radio
11 kHz
stereo
56...64 kbps
26...24:1
near-CD
15 kHz
stereo
96 kbps
16:1
CD
>15 kHz
stereo
112..128kbps
14..12:1
Notes:
MPEG-2 Advanced Audio Coding (AAC)

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

Input Time Signal
Notes:
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
Part 4 and 5 of MPEG-2 correspond to part 4 and 5 of MPEG-1. They have been
finally approved in March 1996.
Manager (SRM) which provides a (logically) centralized management of the DSMCC Sessions and Resources.
Notes:
Part 9 of MPEG2
Part 9 defines the Transport Stream for MPEG2
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:
MPEG Transport over IP
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:
MPEG Video Compression

Supports JPEG and H.261 through downward compatibility
Supports higher Chrominance resolution and pixel resolution (720x480 is
standard used for TV signals)
Supports interlaced and noninterlaced modes
Uses Bidirectional prediction in Group Of Pictures to encode difference
frames.
Group Of Pictures inter-frame dependencies in a stream
Source: Parallelization of Software Mpeg Compression

http://www.evl.uic.edu/fwang/mpeg.html
Notes:
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
'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:
MPEG 1 & 2 Bitstream
The MPEG data hierarchy
Source: http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol4/sab/report.html
Notes:
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
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:
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
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:
MPEG-2 Encoding
Example encoding of a string of coefficients:
12, 6, 6, 0, 4, 3, 0, 0, 0...0
First step is to group them into a string of zeros followed by non-zero
(12), (6), (6), (0, 4), (3) EOB
Length of
run of zeros
0
Value of nonVariable-length
zero
Code-word
coefficient
12
0000 0000 1101 00
0010 0001 0
0000 0011 000
0010 10
EOB
10
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:
MPEG-2 Motion Compensation

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

Profiles
SNR
Spatial
High
Multiview
4:2:0
4:2:0
4:2:0;4:2:2
4:2:0
Enhancement
1920 X 1151/60
1920 X 1151/60
Lower
960 X 576/30
1920 X 1151/60
Bitrate
100, 80,25
130, 50, 80
Levels
High
Enhancement
1440 X 1152/60
1440 X 1152/60
1920 X 1152/60
Lower
720 X 576/30
720 X 576/30
1920 X 1152/60
High-1440
Bitrate
Enhancement
Main
Low
60, 40, 15
720 X 576/30
Lower
Bitrate
15, 10
Enhancement
352 X 288/30
80, 60, 20
100, 40, 60
720 X 576/30
720 X 576/30
352 X 288/30
720 X 576/30
20, 15, 4
Lower
Bitrate
25, 10, 15
352 X 288/30
352 X 288/30
4, 3
8, 4, 4
Notes:
Pro MPEG For Error Tolerance

Adding Forward Error recovery to MPEG protocols improves quality
During transmission on satellite and terrestrial broadcast errors occur
Over IP networks packets of frames are lost when errors occur
On copper cables error rates of 1 bit in 109 are typical
On fiber cables error rates of 1 bit in 1012 are expected
Gigabit Ethernet frames are 1500 bytes or 12,000 bits long
Even over fiber this results in 12 errors per second on average!!
Codes of Practice define how to add FEC to MPEG streams
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:
Pro-MPEG CoP3 Forward Error Correction (FEC)
Normal MPEG-2 Transport streams pack

several video frames in an Ethernet Transfer
Pro-MPEG takes consecutive

packets and adds FEC
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:
Pro-MPEG CoP3 Forward Error Correction (FEC)
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:
COP 4 for SMPTE 292M

RFC3497, RTP Payload Format
Society of Motion Picture & Television Engineers (SMPTE) 292M Video
Commercial Code of Practice issued by the Pro-MPEG forum
Used to carry uncompressed HDTV
The serial digital interface, SMPTE 292M , defines a universal medium of

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

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

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

Scalable Coding of Video Objects
Robustness in Error Prone Environments
Resynchronization
Data Recovery
Error Concealment
Fast recovery in real-time coding
Improved temporal resolution stability with low buffering delay
A special technique of use in real-time encoding situations is Dynamic
Resolution Conversion (DRC)
It is a way to stabilize the transmission buffering delay
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:
VLBV: Very Low Bit-rate Video
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:
Example of Sprite Coding of Video Sequence

The sprite panoramic background image is constructed and sent
This is held in a sprite buffer
Foreground object is transmitted separately as an arbitrary-shape video
object
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:
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
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:
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)
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:
Carriage of MPEG-4 over IP

MPEG-4 can be carried over RTP/UDP/IP
UDP Delivers multiplexing by using port numbers
RTP adds a time stamp and sequence number to provide synchronization
IP provides addressing and routing
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:
H.264 and MPEG-4 Part 10

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

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

Same design to be approved in both ITU-T and MPEG
In ITU-T this will is new & separate standard
ITU-T Recommendation H.264
ITU-T systems (H.32x) to be modified to support it
In MPEG this will be a new part in the MPEG-4 suite
Separate codec design from prior MPEG-4 visual
New part 10 called advanced video coding (similar to AAC position in
MPEG-2 as separate codec)
Not backward compatible with prior standards (incl. the prior MPEG-4 visual
spec. core technology is different)
MPEG-4 Systems / File Format modifying to support it
H.222.0 | MPEG-2 Systems will also be modified to support it
IETF working on RTP payload packetization:
RTP Payload Format for H.264 Video RFC 3984
Notes:
JVT Project Technical Objectives

Primary technical objectives:
Significant improvement in coding efficiency: Average bit rate reduction of
50% given fixed fidelity compared to any other video standard
Error robustness & Network Friendliness (carry it well on MPEG-2 or RTP
Issues examined in H.263 and MPEG-4 are further improved
Low latency capability (better quality for higher latency)
Exact match decoding
Simple syntax specification
Targeting simple and clean solutions
Avoiding any excessive quantity of optional features or profile
configurations
Notes:
Need for H.264: MPEG-2 Has Hit A Wall
6
5
1st
MPEG-2 Encoder
MPEG-2
Standard
Frozen
(H.262)
2nd Generation
Encoder
3rd Generation
Encoder
4
Mbit/s
MPEG-2
4th Generation
Encoder
5th Generation
Encoder
2
1
0
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
Notes:
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
2003
2004
2005
Notes:
H.26L Provides Focus

1st
MPEG-2 Encoder
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
2003
2004
2005
Notes:
MPEG-4 Adopts H.26L

1st
MPEG-2 Encoder
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
2003
2004
2005
Notes:
MPEG-4 Example
Notes:
MPEG-4 Example
This and Previous drawing are PRIMARY examples from MPEG-4

Notes:
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
Notes:
MPEG-4 Audio Tools

Coding tool
Channels
AAC
Total bit
rate
320 kb/s
Grading scale Subjective

quality
impairment
4.6
1995 Backward Compatible

MPEG-2 Layer II
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
MPEG-1 Layer III
128 kb/s
impairment
4.1
AAC
24 kb/s
quality
4.2
Scalable: CELP base and

AAC enhancement
Scalable: Twin VQ base and
AAC enhancement
AAC
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
Notes:
MPEG-4 Audio Tools

Coding tool
Channels
Total bit
rate
Grading scale Subjective

quality
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
AAC Low Delay
64 kb/s
quality
4.4
G.722
64 kb/s
quality
4.2
AAC Low Delay
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
Notes:
Applications for AVC/H.264

Entertainment Video (1 - 8+ Mbps, higher latency)
Broadcast / Satellite / Cable / DVD / VoD / FS-VDSL /
Conversational H.32X Services (usu. <1Mbps, low latency)
H.320 Conversational
3GPP Conversational H.324/M
H.323 Conversational Internet/unmanaged/best effort IP/RTP
3GPP Conversational IP/RTP/SIP
Streaming Services (usu. lower bit rate, higher latency)
3GPP Streaming IP/RTP/RTSP
Streaming IP/RTP/RTSP (without TCP fallback)
Other Services
3GPP Multimedia Messaging Services
Notes:
The Scope of Picture and Video Coding Standardization
Only the Syntax and Decoder are standardized:
Permits optimization beyond the obvious

Permits complexity reduction for implementability
Provides no guarantees of Quality
Source
Destination
Pre-Processing
Encoding
Post-Processing
& Error Recovery
Decoding
Scope of Standard
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:
AVC Encoder
Motion
Imagery
Sources
Encoder System GUI
Video Sensors,
SMPTE Streams,
Networked Video,
Video Servers
DGFX PVA
Frequency
Shaping &
Noise
Reduction
DGFX PVA
Hi Quality
Chroma
Processing
AVC
Encoder
VLSI Chip or
Chips
W/Exact
Match
10 (& 12) Bit

Enabled
Logical System Interconnect (HW or SW)

CODEC
System
Platform
& CPU
MD
Bitstream
Output
NAL: MPEG-2 or Other Xport

AVCs Network Adaptation Layer (NAL)
Supports a Range of Xport Layer Formats &
Protocols (Similar to SMPTE Abstraction)
Notes:
Comparison to MPEG-2, H.263, MPEG-4
Quality
Y-PSNR [dB]
Foreman QCIF 10Hz
39
38
37
36
35
34
33
32
31
30
29
28
27
JVT/H.264/AVC
MPEG-4
MPEG-2
H.263
50
100
150
Bit-rate [kbit/s]
200
250
Notes:
Comparison to MPEG-2, H.263, MPEG-4

CIF 30Hz
Peek Signal
to Noise Ratio
Quality
Y-PSNR [dB]
38
37
36
35
34
33
32
31
30
29
28
27
26
25
JVT/H.264/AVC
MPEG-4
MPEG-2
H.263
0
500
1000
1500
2000
2500
3000
3500
Bit-rate [kbit/s]
Notes:
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
Notes:
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
Notes:
AVC/H.264 Levels
Level 1.0: QCIF @ 15frames/sec
Level 1.1: QCIF @ 30 frames/sec, CIF @7.5 frames/sec
Level 1.2: CIF @ 15 frames/sec
Level 2.0: CIF @ 30 frames/sec

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

Level 5.1: S-HDTV/D-Cinema 2kx1kx120p, 4kx2kx24p, 4kx2kx30p
Notes:
Transport of AVC / H.264

Transport of MPEG-4 AVC using MPEG-2 System: ISO/IEC 13818-1
PDAM (Proposed Draft AMendment) in May 2002
FPDAM (Final Proposed Draft AMendment) in Dec 2002
FDAM in July 2003
Approved AMD
IP delivery
MPEG-2 TS over UDP/IP, or
RTP over IP
Notes:
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
DVB, short for Digital Video Broadcasting, is a suite of internationally accepted,

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

DVB-C is Digital video Broadcasting over Cable
Standards for Cable systems are available at http://www.cablelabs.org
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:
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
DVB-H (Digital Video Broadcasting - Handheld) is a technical specification for

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

The Architecture defines 4 domains
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:
DVB-IPI Home Reference Model
1) A home network can be simultaneously connected to multiple and heterogeneous

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

IP Delivery
Encoding Methods
Chapter Summary
Notes:
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
Notes:
Engineering Reliable IP Services
Notes:
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
Notes:
Course Materials
Course Notes
Copies of all slides and supplemental presentation material
Notes:
Course Contents
Introduction and Overview
Chapter 1
Internet Protocol Suite Delivery of Multimedia Service
Chapter 2
Addressing
Chapter 3
Routing
Chapter 4
Managing Devices With SNMP
Chapter 5
Course Summary
Notes:
Course Contents (Continued)
Appendix A
Networks Glossary
Notes:
Course Schedule
Each day, the course will follow this schedule:
Start class
9:30 a.m.
Morning break
10:30 a.m. (approximately)
Lunch
Resume class
Afternoon break(s)
As needed
Adjourn
5:00 p.m.
Notes:
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
Notes:
Course Instructor
Background and education
Current position
Experience
Notes:
Attendee Introductions
Your name
Organization name
Current position
Experience in: Telecommunications
TCP/IP networking
Expectations
Notes:
Chapter 3
Internet Protocol Suite Delivery of

Multimedia Services
In this chapter we will examine all the protocols that were used in order to connect
and operate the VoIP calls we used in demonstration 1 and captured in
demonstration2. You can work from the LANwatch capture that you made of a real
call or from the handout of a previous capture.
Notes:
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
Notes:
Internet Protocol Suite Delivery of Multimedia Services

TCP/IP Architecture
Network Links
IP
TCP and UDP
Applications
Chapter Summary
Notes:
Can We Put Voice on Our Data Networks?

IP networks are packet networks, which provoke several questions:
Can we transmit voice over packets?
What protocols would we use?
What is the impact on our data network?
Voice requires reliable, timely delivery; i.e., it is a real-time application
Can this be done on best-effort data networks?
What protocols can deal with this requirement?
Voice networks need high reliability and availability
Can data network routing protocols cope with outages quickly enough?
To connect a VoIP device, we need
IP addresses
Physical connectivity
Where and how should we connect devices?
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:
Sources of Network Standards

There are two major standards groups of importance
International Telecommunications Union (ITU)
Internet Engineering Task Force (IETF)
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:
International Telecommunications Union (ITU)

The only telecommunications body with United Nations Charter
Interested in International Interconnection
National standards bodies adapt and extend standards
European Telecommunications Standards Institute (ETSI) evolve from
these
Recognize standards from numbers
A for administrative
E for numbering plans
G for trunk and CODEC standards
H for multimedia standards (VoIP)
Q for Signaling
V for data over analog telephony
X for digital data standards
and others
See http://www.itu.org
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:

Produces standards upon which Internet is based
Called Requests For Comment (RFC)
Most RFCs are proposals for standards
Only small proportion finally accepted
Available free via the Internet
Information available from Internet Assigned Numbers Authority
http://www.iana.org/
Downloadable from http://www.ietf.org/rfc.html
List of current standards in STD 1
http://rfc.net/std1.html
Currently RFC3600
The IETF is an unpaid voluntary body that is heavily dominated in practice by

American companies and Universities. However it tends to develop standards
much faster than the ITU.
Ideas for new standards are produced as RFCs and these may or may not eventually
become standards.
All standards and drafts are freely available over the Internet.
Notes:
Internet Protocol Suite Structure

OSI Model
7. Application
Internet Model
6. Presentation
Application
Application
Transport
Transport
3. Network
Internet
Internet
2. Data Link
Network interface
Network interface
1. Physical
Hardware
Hardware
5. Session
4. Transport
TCP/IP
IP does not care what the lower layers are: LAN or WAN
WAN can be frame relay, ATM, Point-to-Point Protocol (PPP)
OSI = Open Systems Interconnection
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:
OSI Model
ISO 7498 and ITU-T X.200
Application
Presentation
Session
Transport
Network
Data Link
Physical
P rovide s a pplica tion

s e rvice s
P rovide s da ta
re pre s e nta tion
P rovide s che ckpointing,

a ctivity ma na ge me nt
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
Tra ns mits bit s tre a m

ove r phys ica l me dium
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:
OSI Model
Application
Presentation
Session
Transport
Network
Data Link
Moves Bits
Physical

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

da ta inte grity

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:
OSI Model
Application
Presentation
Session
Transport
Network
Detects Errors
Data Link
Moves Bits
Physical

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

da ta inte grity

Layer 2 detects errors. Anything to do with error detection is layer 2. We may

divide the bit stream up into groups of bits called frames and calculate an error
check which is sent at the end of the frame. This is known as a Frame Check
Sequence or Cyclic Redundancy Check.
While layer 2 is responsible for framing and error detection it is not required to
correct the errors it finds. Some layer 2 protocols do but most dont.
I could construct a network of nodes interconnected by layer 1 cables, each link
running a layer 2 detecting errors. However to deliver the data to the correct
destination I need Routing which is the job of layer 3.
Notes:
OSI Model
Application
Presentation
Session
Transport
Routing
Network
Detects Errors
Data Link
Moves Bits
Physical

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

da ta inte grity

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:
OSI Model
Application
Presentation
Session
End to End Error
Recovery
Routing
Transport
Network
Detects Errors
Data Link
Moves Bits
Physical

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

da ta inte grity

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:
OSI Model
Application
Presentation
Checkpoints and
Activities
Session
End to End Error

Recovery
Transport
Routing
Network
Detects Errors
Data Link
Moves Bits
Physical

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

da ta inte grity

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:
OSI Model
Application
Converts bits to Objects
Presentation
Checkpoints and
Activities
Session
End to End Error

Recovery
Transport
Routing
Network
Detects Errors
Data Link
Moves Bits
Physical

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

da ta inte grity

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:
OSI Model
Application and its

Services
Application
Presentation
Checkpoints and
Activities
Session
End to End Error

Recovery
Transport
Routing
Network
Detects Errors
Data Link
Moves Bits
Physical

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

da ta inte grity

Finally layer 7 is where the application and all the other functions run. Indeed you
the user are in layer 7 too.
Notes:
Internet Protocol Suite Structure

OSI Model
7. Application
Internet Model
6. Presentation
Application
Application
Transport
Transport
3. Network
Internet
Internet
2. Data Link
Network interface
Network interface
1. Physical
Hardware
Hardware
5. Session
4. Transport
TCP/IP
IP does not care what the lower layers are: LAN or WAN
WAN can be frame relay, ATM, Point-to-Point Protocol (PPP)
OSI = Open Systems Interconnection
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:

TCP/IP Architecture
Network Links
IP
TCP and UDP
Applications
Chapter Summary
Notes:
Network Interconnection
Host
LAN A
LAN B
Internetworking issues:
Addressing
Routing, path through the network
Packet size and format
Access technology
Shared protocols
Errors, flow, timing
Host
These issues are resolved by an internetworking protocol (Layer 3)

In reality Internetworking involves the interconnection of LANs using WANs

formed from routers.
Notes:
Data Link and Physical Layer in the LAN
Application
Application
Transport
Transport
Internet
Internet
Network interface
LAN or WAN link
Hardware
TCP/IP
Network interface
Hardware
IP can run over any kind of LAN
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:
Data and Computer Networks

LANs permit computers to interconnect locally
Standardized by IEEE 802 committee
Includes wired and wireless versions
Use 48-bit addresses that are not routable
Address Resolution Protocol maps LAN addresses to IP addresses
Limited in physical dimensions
LANs limited to one site can be interconnected

Effectiveness of interconnection depends upon data rate of access
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:
Data and Computer Networks

LAN protocols do not guarantee timing
They are asynchronous
Most Wide Area connections are synchronous
Timing is provided by network
Typically routers interconnect LANs
Public network
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:
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
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:

TCP/IP Architecture
Network Links
IP
TCP and UDP
Applications
Chapter Summary
Notes:
Internet Protocol (IP)

Basic concepts:
IP used by hosts, routers, gateways
Does not need to know how to get to the final destination (endpoint)
Just to the next network (host, next hop)
Does not need to know about all of the networks on the route
Just the locally connected networks
IP packet contains destination address and data
Thats all thats needed to reach destination
Best-effort delivery
No guarantees
The job of a router is to forward a packet to the next best hop en route to its
destination.
Notes:
Internet Protocol Suite

HTTP
SMTP
POP
FTP
Etc.
SNMP
TCP
RIP
Etc.
Transport
UDP
IP
ICMP
Application
Internet
ARP
Data link
Network interface
Physical
Hardware
Internet protocol suite

Includes applications
More than 100 now defined
Operates at Layer 3 and higher
RIP = Routing Information Protocol

SNMP = Simple Network Management Protocol
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:
Encapsulation
E-mail
Me
E-mail
You
TCP E-mail
TCP E-mail
IP TCP E-mail
IP TCP E-mail
Ethernet IP TCP E-mail
Ethernet IP TCP E-mail
Layer 4 interface is with processes on the host

For example, SMTP or POP
Layer 3 interface is with other hosts via address
For example, IP address
Layer 2 depends on the type of physical network used
For example, frame relay, ATM, ISDN, Ethernet
May include additional addressing (SVC, PVC, etc.)
PVC = permanent virtual circuit
SVC = switched virtual circuit
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:
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
TOS = type of service

TTL = time to live
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:
IPv4 Datagram (continued)

Datagram fields important to VoIP
Type of service (TOS)
Used in VoIP QoS
First 3 bits give precedence
Datagram ID provides a unique number for the packet with the TTL
TTL: time to live in seconds (hops)
Routers reduce by 1 or number of seconds held
Flag field
MF: Indicates last fragment (MF=0 is last fragment)
DF: Permission to fragmentDont Fragment (DF bit)
Fragoff: Fragment offset
Measured in units of 8 octets
Prot: Next protocol
6=TCP, 17=UDP
Total overhead is at least 20 bytes for the IP packet header
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:
Where The Internet Protocol Runs
Router
LAN
Router
Wireless Network
Router
Point-To-Point
Network
Router
Router
Switched Network
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:
Where The Internet Protocol Runs

The internet protocol runs in every host and every router
Host: a device that communicate over the internetwork
Router: a device that joins one or more networks onto the internetwork
Does not run in devices that form the networks themselves
Not in devices below OSI layer 3
e. g.
Not in Ethernet switches
Not in Bridges
Not in Modems
Not in Network Termination Units
Not in any device that is Layer 2 or layer 1
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:
Functions of Internet Protocols

IP is not the only internetworking protocol others include
Novell IPX
ISO CLNP
All internetworking protocols provide
Physical network independence for higher-layer processing
Logical address for computers on network
Independence from maximum transmission unit (MTU) size
Fragmentation and reassembly control
Datagram service
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:
Physical Medium Independence

Each network technology may have its own characteristics
Different hardware
Different API for access
Different timing dependency
IP provides a standard logical interface for exchange of data packets
Single Common
Network Interface
IP
Network
Type 1
Network
Type 2
Different Network
Interfaces
Network
Type 3
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:
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
Different network technologies use different address lengths. X.25 a 14 digit

address, the phone service E.164 a 15 digit address, Ethernet a 48 bit address and so
on. All are different addresses and even different sizes. Devices on these networks
will retain their original addresses but will be allocated another logical address by
IP.
Notes:
Independence of MTU size

Each technology has a different maximum transmission unit size
The optimum MTU is determined by the error performance
The more reliable the physical transmission the optimum MTU
High error rates require small packets
More chance of error so less data can be sent before error occurs
Some actual MTUs for technologies widely used
MTU (bytes)
Max frame size
Ethernet
Network
1,500
1,518
IEEE 802.5 (4 Mbit/s)
4,440
4,500
IEEE 802.5 (16 Mbit/s)
17,940
18,000
FDDI
4,352
4,500
X.25
4096
4102
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:
Fragmentation and Reassembly

It is the task of the router to match the MTU sizes between networks
Packets too large for delivery over the output network are fragmented
Destination host reassembles
Packets may be fragmented several times between source and destination
Source
Destination
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:
Internetwork Datagram Service

IP always offers a datagram service
Best Efforts but no guarantee
Source
Destination
Virtual Circuit
Datagram
Virtual Circuit
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:

TCP/IP Architecture
Network Links
IP
TCP and UDP
Applications
Chapter Summary
Notes:
Transmission Control Protocol (TCP)

Provides reliable, in-sequence stream transport
Useful for transfer of large volumes of data such as file transfer
Connection orientedvirtual circuit
When connection is established, data transfer starts
Protocols verify correct reception
Buffered traffic flow
Full-duplex connection
Accounts for more than 90 percent of Internet traffic
Reliability is achieved through retransmission
When packets are lost or errors occur, retransmission provides reliability
Suitable for data traffic and signaling for voice: Ensures correct
information
Not suitable for voice traffic: Voice information must be continuous
By the time data is retransmitted, it is too late!
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:
TCP Segment Header

0
10
16
Source port
24
31
Destination port
Sequence number
Acknowledgment number
HLEN
Reserved
Code bits
Checksum
Window
Urgent pointer
Options (if any)
Padding
Data
Options (normally absent)
Port is a destination for the message

Local host process can communicate with the port
A pair of IP addresses and port numbers for a connection forms a socket
Complete specification for an associationa conversation
Adds at least 20 bytes overhead per packet
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:
User Datagram Protocol (UDP)

Used for unreliable delivery i.e., not acknowledged
Application must handle errors
Loss of packet, duplication, delay
Out-of-sequence, loss of physical connectivity
These functions add processing overhead in applications but
Reduce processing in the transport layer
Much less than TCP
Accounts for less than 5 percent of Internet traffic currently
Used for transaction processing; selected for voice transport
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:
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
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:

TCP/IP Architecture
Network Links
IP
TCP and UDP
Applications
Chapter Summary
Notes:
Applications Use Ports

Hosts are multitasking computers running multiple applications
Communication takes place between the applications running on the hosts
Linkage is not direct; use software code called a port
Allows operating system to direct packets to correct application
Server ports are normally well-known portsless than 1024
HTTP
80
SMTP 25
FTP
21, 20
DNS
53
Telnet
23
NNTP 119
Ports used by VoIP are generally client portsgreater than 1024
End-to-end VoIP call setup uses destination port 1720
UDP ports dynamically assigned and both ends > 1024
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:
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
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:
Real-Time Transport Protocol (RTP)

TCP/IP protocol suite includes protocols for real-time applications
Real-Time Control Protocol (RTCP)
RTP provides
Timestamping, sequence number
For playback timing and synchronization
Setting up real-time applications
Audio and video
RTCP provides
Reporting on achieved results
Delay, packet loss statistics
Defined in RFC 1889 originally
Copied by H.323 systems
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:
Real-Time Applications on Packet Networks

To be intelligible, our speech must be played out with the same timing
relationship between words as the original
Received packets may not all arrive with exactly the same delay
This is called jitter
Real-time Transport Protocol marks the voice samples with a timestamp
That timestamp is used to play out the packet in sequence
With the correct relative time relationship
Youre
right
This
is
an
IP
telephony
course
Sent
Received
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:
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
Synchronization source (SSRC) identifier
Contributing source (CSRC) identifiers
CSRC = contributing source reference code

Notes:
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
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:
Payload Types Defined in RFC 1890

PT
0
1
2
3
5
6
7
8
9
10
11
14
15
25
26
28
31
32
33
34--71
72--76
77--95
96--127
encoding
name
audio/video
(A/V)
PCMU
1016
G721
GSM
DVI4
DVI4
LPC
PCMA
G722
L16
L16
MPA
G728
CelB
JPEG
nv
H261
MPV
MP2T
unassigned
reserved
unassigned
dynamic
A
A
A
A
A
A
A
A
A
A
A
A
A
V
V
V
V
V
AV
?
N/A
?
?
clock rate
(Hz)
channels
(audio)
8000
8000
8000
8000
8000
16000
8000
8000
8000
44100
44100
90000
8000
90000
90000
90000
90000
90000
90000
1
1
1
1
1
1
1
1
1
2
1
1
N/A
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:
Real-Time Transport Control Protocol (RTCP)

Real-Time Transport Control Protocol is used with RTP
Provides
Monitoring and feedback of real-time parameters related to quality
Packets lost, cumulative packets lost
Interarrival jitter calculated as new = old + (delta-old)/16
Calculated as each packet arrives (regardless of sequence)
Transport Level ID for the source of the RTP packets
Optional session control
Minimal capabilities
Start session, bye

RTCP provides an option for encryption to ensure privacy
There is no provision in the standard for any action that may be taken if the
results are unacceptable
RTCP is only a reporting mechanism
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:
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
Most VoIP devices do not carry the identity in the CNAME but NetMeeting does.
Notes:
Example Multimedia Web Applications

Internet Radio
Internet TV : see http://wwitv.com
Streaming over the Internet
Notes:

TCP/IP Architecture
Network Links
IP
TCP and UDP
Applications
Chapter Summary
Notes:
Chapter Summary
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
Notes:
Chapter 4
Layer 2 Addressing
Notes:
Chapter Objectives
Describe how addressing works at layer 2
Examine IEEE 802 addressing
Identify how LANs are interconnected at layer 2
Examine Link level aggregation
Notes:
Layer 2 Addressing
IEEE 802 Addressing
Bridging and Switching
Spanning Tree
Aggregation
Chapter Summary
Notes:
IEEE 802 Standards
802.1 overall
standards
Institute of Electrical and Electronic Engineers produces LAN standards

Available from http://standards.ieee.org/getieee802/
Type 1
Type 2
802.2 Logical Link Control
802.3
Ethernet
802.4
Token Bus
802.5
Token
Ring
10BASE5
1 Mbps
4 Mbps
10BASE2
5 Mbps
16 Mbps
10BASE-T
10 Mbps
802.6
MAN
Others
DQDB
155 Mbps
100BASE-T
1 Gbps LANs
Notes:
General Aspects of LANs

Several common frame format aspects
Destination and source address fields
48-bit addresses
Variable-length payload data size
Maximum size differs
32-bit error-check fields
(6 byte s)
Destination
address
0 = IEEE Admin
1 = Local admin
0 = Individual
1 = Group
. . .
Assigned
to the vendor
(3 bytes)
Payload data
CRC
Assigned
by the vendor
(3 bytes)
Address is sent low order bits first in each byte

E.g., Locally admin, group address
Ethernet Hex Address
1100 0000
0
- - -
Addressing on all 802 standard network technologies is similar. Each deploys a 48

byte address comprising a 3 byte field identifying the Vendor and a 3 byte field
making each address unique. The Vendor code was originally call a Manufacturer
code and has recently changed its name again to an Organizational Unit Identifier.
Bytes are transmitted lowest bit in each byte first. The first two bits transmitted are
reserved and used to identify the addressing scheme used and group addresses
deployed when using multicasting.
Notes:
Speed, Size and Distance Limitations

If we remove the CSMA/CD then the speed and distance can increase
Distance will be limited by the media and layer one characteristics
By buffering in the hub collisions can be removed
The device changes from a hub or repeater to a switch or bridge
However by interconnecting switches very large layer 2 networks result
Also Ethernet is not routable
The address does not indicate where a station sits
Switches must flood broadcasts and unknown destination addresses
Switches must also build up tables of source addresses on each interface
Preamble
(7 bytes)
Start
delimiter
1010...1010 10101011
Min 64
Max 1,518
bytes
(6 bytes)
Frame check
sequence
(4 bytes)
(6 bytes) (2 bytes)
Destination Source
address
address
Type or
length
Data
Pad
FCS
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:
802.3 Variations
The IEEE 802.3 variations are often expressed in the form
10BASE5
10 Mbps
Abbreviation
T
500 M before
Baseband needing a repeater
Or, the letter T after

BASE standing for
twisted pair the
Media Type
Meaning
Half duplex twisted pair, cat 3 or cat 5 (at 10 Mbit/s) 100m
TX
Full Duplex Twisted Pair- two pairs of cat 5 100m
FX
Fiber optic pair up to 400 m
SX
Short wavelength fiber (770-860nm) typically MMF 50 or 62.5/125
LX
Long wavelength fiber (1270-1355nm) typically SMF 10/125
LH
Long Haul fiber (1310 or 1550nm) SMF 9/125
CX
Shielded twisted pair 25 m or less

Notations now identify the speed, the kind of encoding (baseband or broadband)
and the media used.
Notes:
Layer 2 Addressing
IEEE 802 Addressing
Spanning Tree
Aggregation
Chapter Summary
Notes:
Dividing Heavily Loaded Segments

Total LAN traffic on a segment may be high
Heavy traffic!
Bridges allow heavy traffic to be isolated
Lighter traffic!
Improves overall performance but adds delay between segments
However powerful a network becomes there will be limits on its capacity. By

dividing this into two parts where most of the traffic stays local to each half and on
communication between devices on the two halves needs to pass between, greater
overall copacity is created.
The interconnecting device is called a bridge and a group of many bridges in a
single box is called a switch.
Notes:
Transparent Spanning Tree (TST)

This is the 802.1d standard approach
Bridges build a tree structure so there are no active loops
Does not scale well to large sizes
They find the root bridge(or switch) with lowest priority interface
Then minimize the distance from the root bridge
When two paths are found the longest path is turned off
Bridges forward all frame for deliver until they learn otherwise
Host
Host
Host
Host
Host
Host
Stand-by
bridge
Host
Host
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:
Multiple Simultaneous Paths

Using multiple simultaneous paths means that backplane bandwidth is no
longer shared
May be non-blocking every station can transmit at the same time
Can also be full-duplex
Each interface becomes a collision domain with full bandwidth
Switch
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:
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)
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:
Functions Within a Bridge

The switches/bridges maintain a filtering database
Built dynamically on source addresses viewed
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:
Layer 2 Addressing
IEEE 802 Addressing
Spanning Tree
Aggregation
Chapter Summary
Notes:
The Rapid Spanning Tree Protocol

Consider this example: First devices forward Bridge Protocol Data Units
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:
Bridge Protocol Data Units
The Protocol Identifier is 0000 0000 0000 0000.

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

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

RSTP Timer and Transmit Hold Count parameter values
Parameter
Migrate Time
Bridge Hello Time
Bridge Max Age
Bridge Forward Delay
Transmit Hold Count
Recommended or
Default value
3.0
2.0
20.0
15.0
6
Permitted
Range
6.040.0
4.030.0
110
Compatibility
Range
1.02.0
6.040.0
4.030.0
110
Bridge and Port Identifier Priority values

Parameter
Bridge Priority
Port Priority
Recommended
or default value
32 768
128
Range
061 440 in steps of 4096
0240 in steps of 16
Notes:
Port Path Cost values
Link Speed
Recommended
value
Recommended
range
Range
<=100 Kb/s
1 Mb/s
10 Mb/s
100 Mb/s
1 Gb/s
10 Gb/s
100 Gb/s
1 Tb/s
10 Tb/s
200 000 000

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

2 000 000200 000 000
200 00020 000 000
20 0002 000 000
2 000200 000
20020 000
202 000
2200
120
1200 000 000

1200 000 000
1200 000 000
1200 000 000
1200 000 000
1200 000 000
1200 000 000
1200 000 000
1200 000 000
Notes:
Rapid Spanning Tree

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

Bridges that receive more than one copy of the information from the root compare
the root path cost values and select the one with the lowest value as the interface to
use to reach the root. Other interfaces over which copies of the root identity were
received with higher costs are turned off by discarding packets received. Packets
are then forwarded to/from the root port from/to all other ports.
Notes:
Effective Topology
The effective topology is thus reduced
In effect the network becomes a tree.
Notes:
Typical Ring Backbone Topology

In a typical ring backbone one port becomes non-forwarding
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:
Layer 2 Addressing
IEEE 802 Addressing
Spanning Tree
Aggregation
Chapter Summary
Notes:
IEEE 802.3 Link Aggregation

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

Improved reliability without spanning tree reconfiguration
Increased throughput beyond the capacity of a single link
In this aggregated network we have 5 1 Gbit/s interconnections between two

switches. Without aggregation 802.1d would turn off 4 of the 5 links delivering
only 1 Gbiit/s capacity. If one link or indeed even if 4 links failed the service would
continue but 802.1d might take a small number of seconds to switch cables.
With aggregation data is shared between the links and so we can achieve up to say
5 times 1 Gbit/s as well as maitaining service without interruption over individual
link failures.
Notes:
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
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:
Link Aggregation Control PDU (LACPDU)

01-80-C2-00-00-02
Type:88-09
0x01
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:
Priority and System identifier

together identify the entity
Port Priority and Port
together identify the port
prefered in an aggregated group
All ports with same key
are in the same group
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:
Partner at the other end of the link

can be identified if required
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:
Link and Aggregator System Identifiers

Example
In order to allow for convenient transcription and interpretation by human network

personnel, this standard provides a convention for representing compound LAG
IDs. Using this format
a) All fields are written as hexadecimal numbers, 2 digits per octet, in canonical
format.
b) Octets are presented in order, from left to right. Within .elds carrying numerical
signiifcance (e.g.,
priority values), the most significant octet is presented first, and the least signi.cant
octet last.
c) Within .elds that carry MAC addresses, successive octets are separated by dashes
(-), in accordance
with the hexadecimal representation for MAC addresses defined in IEEE Std 8021990.
d) Parameters of the LAG ID are separated by commas.
Notes:
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
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:
Layer 2 Addressing
IEEE 802 Addressing
Spanning Tree
Aggregation
Chapter Summary
Notes:
Chapter Summary
Describe how addressing works at layer 2
Examine IEEE 802 addressing
Identify how LANs are interconnected at layer 2
Examine Link level aggregation
Notes:
Chapter 5
Layer 3 Addressing
Notes:
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
Notes:
Layer 3 Addressing
Routable Addresses
Address Classes (Historic)
Issuing Addresses and Resolving them
Subnetworking
Chapter Summary
Notes:
Routable Address Structure

To deliver a packet, a router must know where to deliver it
IP addresses are divided into two fields
Networkwhere to deliver the packet (usually a LAN)
Hostwhich machine at that location
The division of IP addresses is undertaken by a network mask
192 . 168 . 1
.10
Host
Network
255.255.255
Mask
.0
Mask (netmask or subnet mask) contains binary 1s in the network portion

Used to indicate the division of network and host
With 2^32 possible destinations it might be necessary somewhere within the

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

Net prefix notation is a shorthand way of describing address and mask
192.168.1.10/24 is equivalent to
Address = 192.168.1.10
Mask = 255.255.255.0
Value after the / gives the number of 1s in the mask
Trailing zeros in the address can be removed
122.15.0.0/16 can be written as 122.15/16
0.0.0.0/0 can be written as 0/0
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:
Networks and Subnetworks
192.168.0.1
192.168.0.2
192.168.0.10
Mask = 255.255.255.0
192.168.4.2
192.168.0.254
LAN A
192.168.4.1
192.168.1.254
LAN B
Networks are identified by addresses

Each network must have unique ID
Each host must have unique ID and same prefix
192.168.1.1 192.168.1.2 192.168.1.10
Mask = 255.255.255.0
Networks and subnetworks are joined by routers
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:
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)
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:
Layer 3 Addressing
Routable Addresses
Subnetworking
Chapter Summary
Notes:
Interconnecting to the Internet

Choice between public and private (RFC 1918) IP address
If the device has a private address it cannot connect directly to the Internet
Network Address Translation (NAT) can translate addresses
Allows a limited set of addresses to be shared by a larger community
May improve immunity to attack from hackers
Address structure
Historically, the division of addresses was fixed in structure
Classes A, B, and C
Today we use classless addressing, which allows flexible division
Today we use classless addressingbefore, we used address classes
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:
Addresses Classes (Historic)

H
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
Private networks (RFC 1918)

10.X.X.X
Class A
172.16-30.X.X
Class B
192.168.0-255.X
Class C
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:

Role of IP is to communicate between hosts
Routable protocol
Define both network and host address
Other routable protocols
Novell IPX, Banyan VINES, AppleTalk, OSI IP
Unreliable, best-effort, connectionless delivery
Delivery of packet is not guaranteed
Reliability is the responsibility of the application
Reliability is the responsibility of the upper-layer protocols
May be TCP
May be the application
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:
Addressing
Routable Addresses
Subnetworking
Chapter Summary
Notes:
Mapping IP Addresses to Link Addresses

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

RFC 826 ARP provides a means of mapping IP addresses to link addresses
Machine A broadcasts an ARP request to all the machines on the link
ARP request includes the IP address of the required machine B
All machines on the link compare the requested IP address with their own
Only machine B finds a match and responds
Machine A
IP Address: 192.168.10.1
Machine B
IP Address: 192.168.10.2
Broadcast ARP Request
Broadcast Source A
Dest A
806
ARP Request
Source B
806
ARP Reply
Notes:
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
Type
dynamic
dynamic
dynamic
dynamic
Notes:
Configuring IP Addresses
A device can obtain its IP address in one of a number of ways
By manual configuration
A very reliable human configures it for storage on its backing store
This can make changing IP addresses very difficult
Error prone - if the human makes mistakes!
By using BOOTP - RFC 951 and 1084
Fixed IP address for all time
Provides details of router and other information required
By using DHCP
IP UDP BOOTP request
BOOTP
server
Dest IP address = 255.255.255.255

Source IP address = 0.0.0.0
IP UDP BOOTP reply
Notes:
Dynamic Host Configuration Protocol (DHCP)

DHCP extends BOOTP to add a lease time
Used in most Microsoft environments
A request to the server yields an offer of an address with a lease time
The lease time limits the time the IP address is used
Can be renewed if server agrees
Allows more machines to exist than IP addresses
Only active devices need addresses
Very widely used to allocate addresses within windows networks
Notes:
Can find details with IPCONFIG
Notes:
Layer 3 Addressing
Routable Addresses
Subnetworking
Chapter Summary
Notes:
Dividing Networks - Subnetworks

May be administratively convenient or even necessary to divide networks
Insufficient network addresses for each LAN to have a network
Routing between small groups of workstations on LANs
Easier administration
139.21.1.3
139.21.1.2
139.21.1.1
Rest of the Internet
All Traffic to
139.21.0.0
139.21.2.1
139.21.2.2
139.21.2.3
Notes:
Subnetting Classful Addresses

Before classless addressing network Classes A, B and C were allocated
Needed to divide these so we called the result a subnetwork
Mask used to define the division between subnetwork and host
Called a subnet mask
Today called a Netmask
IP Address
Network
Subnet
Host
1s in mask
0s in mask
Notes:
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
Notes:
How Many Subnets Are Needed?

Routers route between networks or subnetworks
Each interface needs to be on a different network or subnetwork
How many subnetworks do I need here?
LAN A
LAN C
LAN B
Notes:
Point to Point Links

Point to point links count as subnetworks
Routers route between subnets so point to point links must be a subnets
Point to point links have only two addresses
One for each end
Ideal mask is 255.255.255.252 as just 2 valid addresses
Some router vendors allow unnumbered links
No need for IP address but difficult to test link remotely
Most popular routing protocol - RIP - requires all masks are the same
Point to point links use up many addresses
Notes:
Balancing Subnet and Host Needs

Every Host that is connected to a subnet needs a unique IP address
Every point to point link, LAN and other network needs a subnet address
Zero Subnet and all 1s subnet are more difficult to use
Zero subnet address and the network address are the same
Example
139.21.0.0/16 is a network address (class B)
139.21.0.0/24 is a subnet address but its address is the same
Some routers do not allow the use of zero subnet
139.21.2.0
139.21.1.0
Rest of the Internet

All Traffic to
139.21.0.0
Notes:
SMIS Inc Network

SMIS Inc has 6 sites each with a router and a LAN
Notes:
SMIS Inc Network

Each site has the following numbers of computers currently
1
225
2
250
3
100
4
250
5
210
6
216
We have been allocated network address 139.21.0.0/16
You have been appointed to advise on address allocations
Answer the following questions
How many subnets do we need
What subnet masks should be used on each subnet
How should the network addresses be defined for each router interface
How should the addresses be assigned to each host
Notes:
Layer 3 Addressing
Routable Addresses
Subnetworking
Chapter Summary
Notes:
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
Notes:
Chapter 6
Routing
Notes:
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
Notes:
Routing
Distributed Dynamic Routing Principles
RIP
OSPF
BGP4
Chapter Summary
Notes:
Dynamic Routing Principles

C
Consider this network

Each site has one LAN
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:

Routers build tables
Networks they see
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
Each router first constructs a table of destinations networks it knows. In our

example we will use hops to indicate the metric used. Zero means no hops to the
destination - it is local. One hop means that we must pass the data to one more
router for delivery. Initially routers will only know the existence of routers to
which they directly attach. Notice that router A at the bottom is connected directly
to B and C but not directly to D.
Notes:

Exchange tables with
Immediate neighbors
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
1
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:

C
A 2 1
Update Tables
D
B 2 1
C 1 0
D 0 1
A C
A 1 0 1
B 0 1 1
C 1 1 0
A B D
A 1 0 1 2
B
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
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:

Failed link
Remove information
Update links
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
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:

Updated Information
Routes around failure
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
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:

Further Failure
Parts of Network Isolated
Further information
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
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:

C
A 3 4
Tables Updated
D
B 2 3
C 1 0
D 0 1
A
A 1 0
B 0 1
C 3 2
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
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:

Tables Updated again
Hop counts too large
Only 4 hops in network
Nodes unreachable
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
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:

Tables reduced
Two distinct networks
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
Notice now the internetwork has divided into two distinct parts.
Notes:
Routing
RIP
OSPF
BGP4
Chapter Summary
Notes:
Distance Vector Routing

This is known as distance vector routing - routing by rumor
First used Routing Information Protocol (RIP)
Uses metric of Hops
Simple to implement but treats all links as equivalent
Updates routes every 30 seconds
Maximum hop count is 15 - 16 means unreachable
Maximum of 16 hops from destination
Ages routes not refreshed after 6 updates
All networks have the same mask
Does not support Variable Length Subnet Masks (VLSM)
Takes long time to update distant routes
Maximum time is 16 x 30 seconds = 8 minutes
Takes time to count to infinity (16 hops)
RIP version 2 overcomes many of the problems
Not widely supported yet and other options are better
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:
Routing
RIP
OSPF
BGP4
Chapter Summary
Notes:
Link State Routing

Link state routing is routing using a network map
Routers pass information about state of links to neighbors
Neighbors flood the network so every router gets information
Each router builds a map of the whole network
Changes in link states are sent immediately and flooded
Fast update of like state changes - typically in seconds
Only updates sent so much less load after initial update
Most widely used link state routing algorithm is OSPF
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:
Open Shortest Path First (OSPF)

Every router has a complete topological map of the network
Routers correspond to nodes in a graph
Networks are arcs or links between nodes

Routers are neighbors if they share the same link
R1
Net 1
R2
Net 2
R4
Net 5
Net 3
Net 4
R1
Net 5
Net 1
R2
R3
Net 2
Net 4
R4
Net 3
R3
Topological Map
OSPF is the most widely used routing protocol for medium and large organizations.
Most ISPs use this internally.
Notes:
OSPF Routing Updates

Routers periodically send (multicast) status of each one of their links
Link status messages are used to update topological map database
Every router sees the same link-status message
Each calculates shortest path first to all networks
Route path cost can be a function of what ever manager requires
Hops, bandwidth, delay, protocol priority, usage cost, etc.
R1
Net 2
R4
My links to Net 2 and
Net 3 are up!
Net 5
Net 1
Net 3
CRASH
R2
Net 4
My links to Net 3 and

Net 4 are up! Sorry,
my link to Net 5 is
down.
R3
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:
What OSPF Can Deliver

Type of service routing
Possible to have different routing table for each TOS
Load balancing
Traffic can be divided between routes of equal metric
Flexible route path cost
Route path cost can be based on what ever is required
Unnumbered networks
Point to point links can be configured with taking and IP address
Multicast IP
Overhead reduced by using multicast addresses
Fast Convergence
New routes found within seconds after failures
Hierarchical routing possible using OSPF Areas
OSPF can deliver all of these functions in addition to normal routing of traffic.
Notes:
Routing
RIP
OSPF
BGP4
Chapter Summary
Notes:
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
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:
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
This is an example of a registration from an Autonomous System. Within Europe

RIPE acts as a non-profit organization to register addresses and AS identifications.
ISPs attach to switches at general switching points known as Internet Exchanges.
At these points they exchange routes, importing routes from other ISPs (AS) and
exporting their own routes.
Notes:
Example AS
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
import: from AS786 action pref=11; accept AS-JANETPLUS
import: from AS12576 action pref=10; accept AS12576

Some ISPs specialize in interconnecting the Internet exchanges of the world

forming the high bandwidth backbone connections. Other specialize in providing
access services to users.
Notes:
Example AS
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
.

export: to AS12576 158.43.20.170 at 158.43.20.169 announce ANY
In Europe RIP controls the issuing of AS numbers and its datable records peering
relationships.
Notes:
European Internet Exchanges

European exchanges http://www.dix.dk/euro/
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:
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?
There are now 38 Internet Exchanges around Europe that are members of the
European Internet Exchange Association.
Notes:
European Internet Exchange Association
Notes:
European Internet Exchange Association
Notes:
Peering Between Exchanges
Peering details can be found for exchanges at

http://www.euro-ix.net/isp/choosing/search/ixpmatrix.php
The largest exchange in terms of numbers of members is currently in Amsterdam.
The Largest in terms of traffic is the London Internet Exchange LINX. There are
also 3 other exchanges in the UK.
Notes:
Amsterdam Exchange Daily Statistics May 2006

Exchange with the most members is in Amsterdam
Largest number of ISP peering in Europe
2nd largest volume but growing fast
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:
LINX Performance: May 2006

LINX in London has higher throughput and is largest in volume terms
LINX statistics https://www.linx.net
Detailed statisitics of Internet traffic through LINX can be found at

https://www.linx.net/www_public/our_network/traffic_statistics_old/view?searchte
rm=stats
Notes:
LINX Yearly 1 Day Average To May 2006
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:
LINX Growth Over 5 years

There has been a 10 fold increase over the last 4 years
Before this year on year growth was running at 300%
Can you predict the traffic for 2015?
2001
2002
2003
2004
2005
2006
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:
Number of Computers on the Internet

1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
213
235
562
1,024
1,961
5,089
28,174
33,000
159,000
313,000
617,000
1,136,000
2,056,000
3,864,000
6,642,000
16,729,000
26,053,000
36.739,000
56,218,000
93,047,785
125,888,197
162,128,493
171,638,297
285,139,107
317,646,084
The number of computers attached to the Internet increases also.

The key question that is now being asked is when will we run out of IP addresses?
Notes:
Growth in the Internet

The Internet has grown tremendously since 1990
32 bit address space was not allocated well initially
Demand for addresses was slowing because of firewall and proxy use
Rate has started to increase again can you predict when we will run out
of the 4,000,000,000 addresses?
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:
Routing Between ISPs

OSPF provides a good solution for large Autonomous Systems
Can cope with hundreds of networks and routers
Can be scaled using areas
Between ISPs it is not enough to just find the shortest route
Commercial decisions mean that shortest is not always best
ISP may gain revenue from its users
Does not want to carry transit traffic unless there is a commercial reason
Transit ISPs
My ISP
Not this way

Thankyou!
Your ISP
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:
Border Gateway Protocol (BGP)

BGP enables a manager to decide the policy for carrying traffic
Current version is version 4 (BGP4)
Route from end to end is defined so that every ISP (AS) knows total route
If the route passes through an ISP which is not supported it can be rejected
ISPs can enter into commercial agreements to support traffic passage
Enables a manager to provide quality of service to supported customers
Routes may be summarized to reduce routing tables
Scalable to large number of Autonomous Systems
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:
Routing Survival Kit

What you need to know to make routing work: Devices must have unique IP address
Prefix length (subnet mask) must be valid and consistent with address
Default router must be defined on the same subnet
Routing table must be valid: Use netstat -r to check
In a router show ip route
Must have route to destination: use tracert to check it exists
Check routing tables in devices where route is incorrect
Notes:
Trace Route
Notes:
Routing Table
Notes:
Pathping
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:
Routing
RIP
OSPF
BGP4
Chapter Summary
Notes:
Chapter Summary
Studied the operation of distributed dynamic routing
Reviewed the major routing protocols
Examined how distance vector link state and policy based routing
functions
Notes:
Chapter 7
Multicasting and Stream Delivery
Notes:
Chapter Objectives
Capture multicast streams
Identify different multicast address standards
Analyze IGMP and PIM
Differentiate between IGMP versions 1, 2 and 3
Troubleshoot multicasting services
Notes:
Multicast Concepts
Multicast Addressing
IGMP
PIM Sparse Mode Configuration
Analysis of Multicast Exchanges
Troubleshooting Multicast Problems
Chapter Summary
Notes:
Unicast vs Multicast
Unicast
Multicast
Unicast transmission sends multiple copies of data, one copy for

each receiver
Ex: host transmits 3 copies of data and network forwards each to 3
separatereceivers
Ex: host can only send to one receiver at a time
Multicast transmission sends a single copy of data to multiple
receivers
Ex: host transmits 1 copy of data and network replicates at last possible hop for
each receiver, each packet exists only one time on any given net work
Ex: host can send to multiple receivers simultaneously
Notes:
Multicast Advantages
As the number of viewers receiving the service increases, multicast delivery

becomes dramatically more efficient. It is really not feasible to deliver broadcast
television to a nation via Unicast, however via multicast it would be feasible to
deliver dozens or perhaps a hundred channels that way.
Notes:
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
There are however disadvantages with multicast. By its very nature the traffic
cannot be acknowledge so the service is less reliable.
Notes:
Multicast Concepts
IGMP
Chapter Summary
Notes:
IP Multicast Service Model

RFC 1112 (Host Ext. for Multicast Support)
Each multicast group identified by a class-D IP address
Members of the group could be present anywhere in the Internet
Members join and leave the group and indicate this to the routers
Senders and receivers are distinct:
i.e., a sender need not be a member
Routers listen to all multicast addresses and use multicast routing
protocols to manage groups
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:
Multicast Addresses
Multicast Address Range

Assignments Description
Range
Reserved Link Local Addresses
224.0.0.0/24
Globally Scoped Addresses
224.0.1.0 to 238.255.255.255
Source Specific Multicast
232.0.0.0/8
GLOP Addresses
233.0.0.0/8
Limited Scope Addresses
239.0.0.0/8
The Internet Assigned Numbers Authority (IANA) controls the assignment of IP

multicast addresses. IANA has assigned the IPv4 Class D address space to be used
for IP multicast. Therefore, all IP multicast group addresses fall in the range from
224.0.0.0 through 239.255.255.255.
The Class D address range is used only for the group address or destination address
of IP multicast traffic. The source address for multicast datagrams is always the
unicast source address.
Notes:
Reserved Link Local Addresses
Address
Usage
224.0.0.1
All systems on this subnet
224.0.0.2
All routers on this subnet
224.0.0.5
OSPF routers
224.0.0.6
OSPF designated routers
224.0.0.12
Dynamic Host Configuration Protocol (DHCP)

server/relay agent
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:
Globally Scoped Addresses

IANA has assigned multicast addresses globally to a number of protocols
They are in the 224.0.0.0/16 range - several hundred in all!
Routers should NOT forward streams sent to these addresses
Examples:224.0.0.0 Base Address (Reserved) [RFC1112,JBP]
224.0.0.1 All Systems on this Subnet [RFC1112,JBP]
224.0.0.2 All Routers on this Subnet [JBP]
224.0.0.3 Unassigned [JBP]
224.0.0.4 DVMRP Routers [RFC1075,JBP]
224.0.0.5 OSPFIGP OSPFIGP All Routers [RFC2328,JXM1]
224.0.0.6 OSPFIGP OSPFIGP Designated Routers [RFC2328,JXM1]
224.0.0.7 ST Routers [RFC1190,KS14]
224.0.0.8 ST Hosts [RFC1190,KS14]
224.0.0.9 RIP2 Routers [RFC1723,GSM11] 224.0.0.10 IGRP Routers [Farinacci]
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:
Source Specific Multicast (SSM)

Addresses in the range 232/8 are reserved for source specific Multicast
Useful when several sources use the same multicast destination for
different applications
End systems can distinguish application protocols but network efficiency
suffers
By requesting streams based on the full (S, G) identity this is avoided
The receiver application sends a join a particular source by using the
INCLUDE mode in IGMPv3
The multicast router can now send the request directly to the source rather
than send the request to a common RP as in PIM sparse mode
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:
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
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:
Limited Scope Addresses

Addresses in the 239/8 range are called limited scope addresses
or sometimes administratively scoped addresses
These addresses are described in RFC 2365
Used by multicast applications that will not be forwarded outside their
domain
Addresses in the 239.0.0.0/8 range are called limited scope addresses or

administratively scoped addresses. These addresses are described in RFC 2365,
Administratively Scoped IP Multicast, to be constrained to a local group or
organization. Companies, universities, or other organizations can use limited scope
addresses to have local multicast applications that will not be forwarded outside
their domain. Routers typically are configured with filters to prevent multicast
traffic in this address range from flowing outside of an autonomous system (AS) or
any user-defined domain. Within an autonomous system or domain, the limited
scope address range can be further subdivided so that local multicast boundaries
can be defined. This subdivision is called address scoping and allows for address
reuse between these smaller domains.
Notes:
Layer 2 Multicast Addresses

Multicast MAC addresses have the lowest order bit in the first byte set
If they are locally administered then the next lowest is set too
XXXXXX11
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
Broadcast or multicast
Locally administered address
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:
Layer 2 Multicast Addresses

IANA has devised a mechanism for generating multicast MAC addresses
IANA has allocated to it the prefix 01-00-5e
The lower 23 bits of the IP multicast group address are used in the lowest
23 bits
This is not perfect as 32 multicast addresses map to each MAC address
Care should be taken when selecting addresses to keep the lowest 3 bytes
unique
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:
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
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:
Multicast Concepts
IGMP
Chapter Summary
Notes:
Requests for Multicasts Streams
The receivers indicate their interest by sending an Internet Group Management

Protocol (IGMP) host report to the routers in the network. The routers are then
responsible for delivering the data from the source to the receivers. The routers use
Protocol Independent Multicast (PIM) to dynamically create a multicast distribution
tree. The video data stream will then be delivered only to the network segments that
are in the path between the source and the receivers. This process is further
explained in the following sections.
Multicast is based on the concept of a group. A multicast group is an arbitrary
group of receivers that expresses an interest in receiving a particular data stream.
This group has no physical or geographical boundariesthe hosts can be located
anywhere on the Internet or any private internetwork. Hosts that are interested in
receiving data flowing to a particular group must join the group using IGMP .
Notes:
Multicast Concepts
IP multicast is a bandwidth-conserving technology that reduces traffic by

simultaneously delivering a single stream of information to potentially thousands of
corporate recipients and homes.
IP multicast delivers application source traffic to multiple receivers without
burdening the source or the receivers while using a minimum of network
bandwidth. Multicast packets are replicated in the network at the point where paths
diverge by routers enabled with Protocol Independent Multicast (PIM) and other
supporting multicast protocols, resulting in the most efficient delivery of data to
multiple receivers. Many alternatives to IP multicast require the source to send
more than one copy of the data. Some, such as application-level multicast, require
the source to send an individual copy to each receiver. Even low-bandwidth
applications can benefit from using IP multicast when there are thousands of
receivers. High-bandwidth applications, such as MPEG video, may require a large
portion of the available network bandwidth for a single stream. In these
applications, IP multicast is the only way to send to more than one receiver
simultaneously. The figure shows how IP multicast is used to deliver data from one
source to many interested recipients
Notes:
Internet Group Management Protocol (IGMP)

IGMP is used to dynamically register individual hosts in a multicast group
Normally works on a particular LAN
There are 3 versions of IGMP
Version 1 has only 2 message types
Membership query
Membership report
Version 2 has 4 message types
Membership query
Version 1 membership report
Version 2 membership report
Leave group
Version 3 adds a further Version 3 membership report
IGMP is used to dynamically register individual hosts in a multicast group on a

particular LAN. Hosts identify group memberships by sending IGMP messages to
their local multicast router. Under IGMP, routers listen to IGMP messages and
periodically send out queries to discover which groups are active or inactive on a
particular subnet.
In version 1 IGMP is used to dynamically register individual hosts in a multicast
group on a particular LAN. Hosts identify group memberships by sending IGMP
messages to their local multicast router. Under IGMP, routers listen to IGMP
messages and periodically send out queries to discover which groups are active or
inactive on a particular subnet.
IGMPv1 has been superceded by IGMP Version 2 (IGMPv2), which is now the
current standard. IGMPv2 is backward compatible with IGMPv1. RFC 2236,
Internet Group Management Protocol, Version 2, describes the specification for
IGMPv2
The main difference is that there is a leave group message. With this message, the
hosts can actively communicate to the local multicast router that they intend to
leave the group.
Notes:
IGMP Version 3 RFC 3376

IGMPv3 query message enables more reliable group control
0x11 Membership Query
0x22 Version 3 Membership Report
Must also support
these for compatability
with versions 1 and 2
0x12 Version 1 Membership Report [RFC-1112]

0x16 Version 2 Membership Report [RFC-2236]
0x17 Version 2 Leave Group [RFC-2236]
Query Request
Query Report
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:
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
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:
IGMP State Maintained by Multicast Routers

Multicast routers implementing IGMPv3 keep state per group per attached
network
state conceptually consists of a set of records of the form:
(multicast address, group timer, filter-mode, (source records))
Each source record is of the form:
(source address, source timer)
If all sources within a given group are desired, an empty source record list
is kept with filter-mode set to EXCLUDE
Multicast routers send Host Membership Query messages (hereinafter called

Queries) to discover which host groups have members on their attached local
networks. Queries are addressed to the all-hosts group (address 224.0.0.1), and
carry an IP time-to-live of 1.
Hosts respond to a Query by generating Host Membership Reports reporting each
host group to which they belong on the network interface from which the Query
was received.
Notes:
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
In order to avoid an "implosion" of concurrent Reports and to reduce the total

number of Reports transmitted, two techniques are used:
When a host receives a Query, rather than sending Reports immediately, it starts a
report delay timer for each of its group memberships on the network interface of the
incoming Query. Each timer is set to a different, randomly-chosen value between
zero and D seconds. When a timer expires, a Report is generated for the
corresponding host group. Thus, Reports are spread out over a D second interval
instead of all occurring at once.
A Report is sent with an IP destination address equal to the host group address
being reported, and with an IP time-to-live of 1, so that other members of the same
group on the same network can overhear the Report. If a host hears a Report for a
group to which it belongs on that network, the host stops its own timer for that
group and does not generate a Report for that group. Thus, in the normal case, only
one Report will be generated for each group present on the network, by the member
host whose delay timer expires first. Note that the multicast routers receive all IP
multicast datagrams, and therefore need not be addressed explicitly. Further note
that the routers need not know which hosts belong to a group, only that at least one
host belongs to a group on a particular network.
Notes:
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
Multicast routers send Queries periodically to refresh their knowledge of

memberships present on a particular network. If no Reports are received for a
particular group after some number of Queries, the routers assume that that group
has no local members and that they need not forward remotely-originated
multicasts for that group onto the local network. Queries are normally sent
infrequently (no more than once a minute) so as to keep the IGMP overhead on
hosts and networks very low. However, when a multicast router starts up, it may
issue several closely-spaced Queries in order to build up its knowledge of local
memberships quickly.
When a host joins a new group, it should immediately transmit a Report for that
group, rather than waiting for a Query, in case it is the first member of that group
on the network. To cover the possibility of the initial Report being lost or damaged,
it is recommended that it be repeated once or twice after short delays. A simple way
to accomplish this is to act as if a Query had been received for that group only,
setting the group's random report delay timer. Note that, on a network with no
multicast routers present, the only IGMP traffic is the one or more Reports sent
whenever a host joins a new group.
Notes:
Events Causing State Transitions

"join group" occurs when the host decides to join the group on the
interface.
"leave group" occurs when the host decides to leave the group on the
interface.
"query received" occurs when the host receives a valid IGMP Host
Membership Query message.
"report received" occurs when the host receives a valid IGMP Host
Membership Report message.
"timer expired" occurs when the report delay timer for the group on the
interface expires. It may occur only in the Delaying Member state
Hosts respond to a Query by generating Host Membership Reports (hereinafter

called Reports), reporting each host group to which they belong on the network
interface from which the Query was received. In order to avoid an "implosion" of
concurrent Reports and to reduce the total number of Reports transmitted, two
techniques are used:
When a host receives a Query, rather than sending Reports immediately, it
starts a report delay timer for each of its group memberships on the network
interface of the incoming Query. Each timer is set to a different, randomlychosen value between zero and D seconds. When a timer expires, a Report is
generated for the corresponding host group. Thus, Reports are spread out over
a D second interval instead of all occurring at once.
Notes:
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
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:
Queries and reports

Query Message
Must be at least 8 octets long and have a correct IGMP checksum
Have an IP destination address of 224.0.0.1
A single Query applies to all memberships on the interface from which the
Query is received
It is ignored for memberships in the Non-Member or Delaying Member state
Report Message
Must be at least 8 octets long and have a correct IGMP checksum
Contain the same IP host group address in its IP destination field and its
IGMP group address field
A Report applies only to the membership in the group identified by the
Report, on the interface from which the Report is received
It is ignored for memberships in the Non-Member or Idle Member state
Notes:
IGMP State Trsnsitions
Non-Member
Leave Group
(stop timer)
Leave Group
Join Group
(send report
start timer)
DelayingMember
Query received
(start timer)
Idle-Member
Report received
(stop timer)
Timer expired
(send report)
Multicast routers send Queries periodically to refresh their knowledge of

memberships present on a particular network. If no Reports are received for a
particular group after some number of Queries, the routers assume that that group
has no local members and that they need not forward remotely-originated
multicasts for that group onto the local network. Queries are normally sent
infrequently, no more than once a minute, so as to keep the IGMP overhead on
hosts and networks very low. However, when a multicast router starts up, it may
issue several closely-spaced Queries in order to build up its knowledge of local
memberships quickly.
When a host joins a new group, it should immediately transmit a Report for that
group, rather than waiting for a Query, in case it is the first member of that group
on the network. To cover the possibility of the initial Report being lost or damaged,
it is recommended that it be repeated once or twice after short delays. (A simple
way to accomplish this is to act as if a Query had been received for that group only,
setting the group's random report delay timer. The state transition diagram below
this approach.
On a network with no multicast routers present, the only IGMP traffic is the one or
more Reports sent whenever a host joins a new group.
Notes:
Manipulating IGMP
access-group
IGMP group access group
helper-address
IGMP helper address
join-group
IGMP join multicast group
last-member-query-interval
IGMP last member query interval
querier-timeout
IGMP previous querier timeout
query-interval
IGMP host query interval
query-max-response-time
IGMP max query response value
static-group
IGMP static multicast group
unidirectional-link
IGMP unidirectional link multicast routing
version
IGMP version
These are the qualifiers that can be applied to ip igmp commands to manipulate
IGMP on Cisco devices..
Notes:
Limiting the Joining of Groups
To filter multicast groups allowed on an interface, use the following

command in interface configuration mode:
ip igmp access-group access-list-number
Multicast routers send host-query messages periodically

This is used to refresh their knowledge of memberships present
At least one router must be present to produce these queries

Low cost switch vendors often use IGMP spoofing
This will propagate IGMP information in response to queries
To modify this interval, use the following command in interface

configuration mode:
ip igmp query-interval seconds
Multicast routers send IGMP host-query messages to discover which multicast

groups are present on attached networks. These messages are sent to the all-systems
group address of 224.0.0.1 with a TTL of 1.
Multicast routers send host-query messages periodically to refresh their knowledge
of memberships present on their networks. If, after some number of queries, the
Cisco IOS software discovers that no local hosts are members of a multicast group,
the software stops forwarding onto the local network multicast packets from remote
origins for that group and sends a prune message upstream toward the source.
Multicast routers elect a PIM designated router for the LAN (subnet). This is the
router with the highest IP address. The designated router is responsible for sending
IGMP host-query messages to all hosts on the LAN. In sparse mode, the designated
router also sends PIM register and PIM join messages toward the RP router.
Notes:
IGMP Versions 1 and 2
To control which version of IGMP the router uses, use the following
ip igmp version {2 | 1}
To change the query timeout in version 2, use the following command in

interface configuration mode:
ip igmp query-timeout seconds
To change the maximum query response time, use the following

ip igmp query-max-response-time seconds
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:
Capture of IGMP Client Starts First
In this example we have captured a multicast stream and filtered on IGMP. We

started VLC which made two IGMPv3 requests in packet 37 and 38. The multicast
stream ran until at packet 27365 when the router at 10.0.0.254 sent a membership
report to 224.0.1.40 using IGMPv2. From this point on the traffic will downgrade to
IGMPv2. At 27367 the router sends an IGMPv2 query to 224.0.0.1 all systems on
the LAN. At packet 27384 the receiver sends a membership report to
239.255.255.250 and then immediately after to 255.1.2.3. Following this there are
repeated queries to
Notes:
Server and Router Start First
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:
Setting Time Reference
By right clicking on packet 52 we can set a time reference so that we can measure
time starting from this point.
Notes:
Timing Between Events
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:
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
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:
Multicast Concepts
IGMP
Chapter Summary
Notes:
Multicast Distribution Trees

Shortest Path or Source Distribution Tree
Shortest Path Trees aka Source Trees

A Shortest path or source distribution tree is a minimal spanning tree with the
lowest cost from the source to all leaves of the tree.
We forward packets on the Shortest Path Tree according to both the Source
Address that the packets originated from and the Group address G that the packets
are addressed to. For this reason we refer to the forwarding state on the SPT by the
notation (S,G) (pronounced S comma G).
where:
S is the IP address of the source.
G is the multicast group address
Example 1:
The shortest path between Source 1 and Receiver 1 is via Routers A and C, and
shortest path to Receiver 2 is one additional hop via Router E.
Notes:

Shortest Path or Source Distribution Tree
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:

Shared Distribution Tree
Shared Distribution Trees

Shared distribution tree whose root is a shared point in the network down which
multicast data flows to reach the receivers in the network. In PIM-SM, this shared
point is called the Rendezvous Point (RP).
Multicast traffic is forwarded down the Shared Tree according to just the Group
address G that the packets are addressed to, regardless of source address. For this
reason we refer to the forwarding state on the shared tree by the notation (*,G)
(pronounced star comma G)
where:
* means any source
G is the group address
Notes:

Shared Distribution Tree
Shared Distribution Trees

Before traffic can be sent down the Shared Tree it must somehow be sent to the
Root of the Tree.
In classic PIM-SM, this is accomplished by the RP joining the Shortest Path Tree
back to each source so that the traffic can flow to the RP and from there down the
shared tree. In order to trigger the RP to take this action, it must somehow be
notified when a source goes active in the network.
In PIM -SM, this is accomplished by first-hop routers (i.e. the router directly
connected to an active source) sending a special Register message to the RP to
inform it of the active source.
In the example above, the RP has been informed of Sources 1 and 2 being active
and has subsequently joined the SPT to these sources.
Notes:
Characteristics of Distribution Trees

Source or Shortest Path trees
Uses more memory O(S x G) but you get optimal paths from source to all
receivers; minimizes delay
Shared trees
Uses less memory O(G) but you may get sub-optimal paths from source to
all receivers; may introduce extra delay
Source or Shortest Path Tree Characteristics

Provides optimal path (shortest distance and minimized delay) from source to all
receivers, but requires more memory to maintain
Shared Tree Characteristics
Provides sub-optimal path (may not be shortest distance and may introduce extra
delay) from source to all receivers, but requires less memory to maintain
Notes:
Building Distribution Trees

PIM
Uses existing Unicast Routing Table plus Join/Prune/Graft mechanism to
build tree
DVMRP
Uses DVMRP Routing Table plus special Poison-Reverse mechanism to
build tree
MOSPF
Uses extension to OSPFslink state mechanism to build tree.
CBT
Uses existing Unicast Routing Table plus Join/Prune/Graft mechanism to
build tree
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:
RPF Check Failure
Multicast Forwarding: RPF Check Fails

Ex: Router can only accept multicast data from Source 151.10.3.21 on interface S1
... multicast data is silently dropped because it arrived on an interface not specified
in the RPF check (S0)
Notes:
RPF Check Succeeds
Multicast Forwarding: RPF Check Succeeds

Ex: Router can only accept multicast data from Source 151.10.3.21 on interface S1
... multicast data is forwarded out all outgoing on the distribution tree because it
arrive on the incoming interface specified in the RPF check (S1)
Notes:
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.
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:
TTL Thresholds Example
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:
TTL Threshold Boundaries
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:
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:
Administratively-scoped multicast address ranges generally used in more than one

location.
In the example above, the Administratively-Scoped address range, (239.128.0.0/16)
is being used by both the LA campus and the NYC campus. Multicast traffic
originated in these address ranges will remain within each respective campus and
not onto the WAN that exists between the two campuses. This is often sort of
configuration is often used so that each campus can source high-rate multicasts on
the local campus and not worry about it being accidentally leaked into the WAN
and causing congestion on the slower WAN links.
In addition to the 239.128.0.0/16 range, the entire company network has a
Administrative boundary for the 239.129.0.0/16 multicast range. This is so that
multicasts in these ranges do not leak into the Internet.
The Admin. -Scoped address range (239..0.0/8) is similar to the 10.0.0.0 unicast
address range in that it is reserved and is not assigned for use in the Internet.
Notes:
Types of Multicast Protocols

Dense-mode
Uses Push Model
Traffic Flooded throughout network
Pruned back where it is unwanted
Flood & Prune behavior (typically every 3 minutes)
Sparse-mode
Uses Pull Model
Traffic sent only to where it is requested
Explicit Join behavior
Dense-mode multicast protocols

Initially flood/broadcast multicast data to entire network, then prune back paths that
don't have interested receivers
Sparse-mode multicast protocols
Assumes no receivers are interested unless they explicitly ask for it
Notes:
Dense Mode
S2
S1
R1
R2
R3
S3
R4
R5
R6
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:
Sparse Mode
S2
S1
S3
RP1
RP3
RP2
R1
R2
R3
R4
R5
R6
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:
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
DVMRPv1 is obsolete and was never used. DVMRPv2 is an old Internet-Draft

and is the current implementation used through-out the Mbone. DVMRPv3 is the
current Internet-Draft although it has not been completely implemented by most
vendors.
MOSPF is currently at Proposed Standard status. However, most members of the
IETF IDMR working group doubt that MOSPF will scale to any degree and are
therefore uncomfortable with declaring MOSPF as a standard for IP Multicasting.
(Even the author of MOSPF, J. Moy, has been quoted in an RFC that, more work
needs to be done to determine the scalability of MOSPF.)
PIM-DM is in Internet Draft form and work continues to move into an RFC.
CBT is also in Internet Draft form and while it has been through three different and
incompatible revisions, it is not enjoying significant usage nor is it a primary focus
of the IETF IDMR working group.
PIM-SM moved to Proposed Standard in early 2000. Much of the effort in the
IETF towards a working multicast protocol is focused on PIM -SM.
Notes:
Dense-Mode Protocols
DVMRP - Distance Vector Multicast Routing Protocol
MOSPF - Multicast OSPF
PIM DM - Protocol Independent Multicasting (Dense Mode)
Notes:
PIM-SM (RFC 2362)

Supports both source and shared trees
Assumes no hosts want multicast traffic unless they specifically ask for it
Uses a Rendezvous Point (RP)
Senders and Receivers rendezvous at this point to learn of each others
existence.
Senders are registered with RP by their first-hop router.
Receivers are joined to the Shared Tree (rooted at the RP) by their local
Designated Router (DR).
Appropriate for
Wide scale deployment for both densely and sparsely populated groups in
the enterprise
Optimal choice for all production networks regardless of size and
membership density.
Utilizes a rendezvous point (RP) to coordinate forwarding from source to receivers

Regardless of location/number of receivers, senders register with RP and send a
single copy of multicast data through it to registered receivers
Regardless of location/number of sources, group members register to receive data
and always receive it through the RP
Appropriate for Wide scale deployment for both densely and sparsely populated
groups in the Enterprise
Optimal choice for all production networks regardless of size and membership
density.
Notes:
PIM-SM Shared Tree Joins
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:
PIM-SM Sender Registration
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:
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:
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:
PIM-SM SPT Switchover
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:
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:
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:
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:
PIM-SM Frequently Forgotten Fact
The default behavior of PIM-SM is

that routers with directly connected
members will join the Shortest Path Tree
as soon as they detect a new
multicast source.
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:
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
Evaluation: PIM Sparse-mode

Can be used for sparse of dense distribution of multicast receivers (no necessity to
flood)
Advantages
Traffic sent only to registered receivers that have explicity joined the multicast
group
RP can be switched to optimal shortest-path-tree when high-traffic sources are
forwarding to a sparsely distributed receiver group
Inter-operates with DVMRP
Potential issues
Requires RP during initial setup of distribution tree (can switch to shortest-path tree
once RP is established and determined sub-optimal)
Notes:
Conclusion
Virtually all production networks

should be configured to run PIM in
Sparse mode!
Notes:
Multicast Concepts
IGMP
Chapter Summary
Notes:
Multicast Concepts
IGMP
Chapter Summary
Notes:
PIM Version 2 Configuration
Protocol-Independent Multicast (PIM) Version 2 features
Single active RP exists per multicast group with multiple backup RPs
Multiple active RPs for the same group in PIM Version 1
A bootstrap router (BSR) provides a fault-tolerant with automated RP

discovery and distribution mechanism
Thus, routers dynamically learn the group-to-RP mappings
Sparse mode and dense mode are properties of a group, as opposed to

an interface.
Sparse-dense mode is recommended, as opposed to either sparse mode or
dense mode only.
PIM Join and Prune messages have more flexible encodings for multiple
address families
A more flexible Hello packet format replaces the Query packet
Register messages to an RP indicate source: border router or a

designated router
Notes:
Stages in Configuring PIM
ip pim version [1 | 2]
Default is version 2 after ios 11.3(2)T

Turn On Multicasting with ip multicast-routing
Configure and interface using interface type number

Enable PIM on the interface with ip pim sparse-dense-mode
Notes:
BSRs and RPs
Bootstrap routers (BSR) hold list of multicast groups that are reachable
Different BSRs are elected on each side of PIM Domain Border
To define a PIM Domain Border use ip pim border
To prevent Auto-RP messages from entering the PIM domain use Access
Control List
access-list access-list-number {deny | permit} source [source-wildcard]
ip multicast boundary access-list-number
Configure Candidate BSRs

ip pim bsr-candidate type number hash-mask-length [priority]
Configure Candidate RPs

ip pim rp-candidate type number ttl group-list access-list-number
Notes:
Example BSR Configuration

!
ip multicast-routing
!
interface Ethernet0
ip address 171.69.62.35 255.255.255.240
!
interface Ethernet1
ip address 172.21.24.18 255.255.255.248
ip pim sparse-dense-mode
!
interface Ethernet2
ip address 172.21.24.12 255.255.255.248
!
router ospf 1
network 172.21.24.8 0.0.0.7 area 1
network 172.21.24.16 0.0.0.7 area 1
!
ip pim bsr-candidate Ethernet2 30 10
ip pim rp-candidate Ethernet2 group-list 5
access-list 5 permit 239.255.2.0 0.0.0.255
Notes:
Border Router Configuration Example

!
ip multicast-routing
!
!
interface Ethernet0
ip address 171.69.62.35 255.255.255.240
!
interface Ethernet1
ip address 172.21.24.18 255.255.255.248
ip pim border
ip multicast boundary 1
!
interface Ethernet2
ip address 172.21.24.12 255.255.255.248
!
access-list 1 deny 239.0.0.0 0.255.255.255
access-list 1 deny 224.0.1.39 0.255.255.255
access-list 1 deny 224.0.1.40 0.255.255.255
Notes:
Using Auto-RP
Auto-RP is a feature that automates the distribution of group-to-RP

mappings in a PIM network. Benefits:
Easy to use multiple RPs within a network to serve different group ranges.
Allows load splitting among different RPs and arrangement of RPs
according to the location of group participants
Avoids inconsistent, manual RP configurations that can cause connectivity
problems
Multiple RPs can be used to serve different group ranges or serve as hot
backups of each other
To make Auto RP work, a router must be designated as an RP-mapping

agent, which receives the RP-announcement messages from the RPs and
arbitrates conflicts
The RP-mapping agent then sends the consistent group-to-RP mappings

to all other routers
All routers automatically discover which RP to use for the groups they
support.
Notes:
Using Auto-RP
Sparse-mode environments need a default RP; sparse-dense-mode

environments do not.
If you have sparse-dense mode configured everywhere, you do not need

to choose a default RP
Adding Auto-RP to a sparse-mode cloud requires a default RP
Use that RP for the global groups, for example, 224.x.x.x
To designate that a router is the RP, use the following command in global
configuration mode:
ip pim send-rp-announce type number scope ttl group-list access-listnumber
Example
ip pim send-rp-announce ethernet0 scope 16 group-list 1
Notes:
Assign the RP Mapping Agent
The RP mapping agent is the router that sends the authoritative Discovery
packets telling other routers which group-to-RP mapping to use. Such a
role is necessary in the event of conflicts (such as overlapping group-toRP ranges)
Find a router whose connectivity is not likely to be interrupted and assign

it the role of RP-mapping agent
All routers within ttl number of hops from the source router receive the
Auto-RP Discovery messages
To assign the role of RP mapping agent in that router, use the following
command in global configuration mode:
ip pim send-rp-discovery scope ttl
Verify the Group-to-RP Mapping using

show ip pim rp [group-name | group-address] [mapping]
Notes:
Prevent Join Messages to False RPs
The addresses from which Auto-RP announcements are accepted can be

limited
ip pim accept-rp default RP address 1

access-list 1 permit 224.0.1.39
access-list 1 permit 224.0.1.40
To filter incoming RP announcement messages, use the following

command in global configuration mode:
ip pim rp-announce-filter rp-list access-list-number group-list access-listnumber
Notes:
Monitoring the Multicast Routing Table

R99#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Candidate for MSDP Advertisement
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.255.250), 00:23:39/00:02:32, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:23:39/00:02:25
(*, 224.0.1.39), 00:21:35/00:00:00, RP 0.0.0.0, flags: DJCL
Loopback0, Forward/Sparse, 00:21:35/00:02:23
This shows how to display the multicast routing table. Generally this will be quire
long and stretch over many pages.
Notes:
Monitoring the Multicast Routing Table

(*, 224.0.1.40), 00:24:03/00:00:00, RP 0.0.0.0, flags: DJCL
(*, 225.1.2.3), 00:01:36/00:02:59, RP 0.0.0.0, flags: DJC
(192.168.0.31, 225.1.2.3), 00:01:36/00:02:59, flags: CT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Here 192.168.0.31 is the source for the stream 225.1.2.3 which is arriving on
interface Ethernet 0.
Notes:
Monitoring IGMP Groups
R99#show ip igmp groups

IGMP Connected Group Membership
Group Address
Interface Uptime
Expires
Last Reporter
239.255.255.250 Ethernet1 00:13:27 00:02:46 192.168.1.250
239.255.255.250 Ethernet0 00:22:19 00:02:44 192.168.0.18
224.0.1.39
Loopback0 00:20:15 never 10.1.1.1
224.0.1.39
Ethernet1 00:20:15 never 192.168.1.99
224.0.1.39
Ethernet0 00:20:15 never 192.168.0.99
224.0.1.40
Ethernet0 00:22:43 never 192.168.0.99
225.1.2.3
Ethernet1 00:00:07 00:02:53 192.168.1.250
R99#
Show ip igmp groups displays the groups that the router is a member of.
Notes:
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
Notes:
Look at what is going on in R75a

ip22-R75a#sh ip mroute 224.1.1.1
A - Advertised via MSDP
(*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
(1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
This is telling us that the multicast packets are being sourced from a server whose
address is 1.1.1.1 which is sending to a multicast group of 224.1.1.1
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:
Look at what is going on in R72a

(*, 224.1.1.1), 00:05:36/00:02:19, RP 0.0.0.0, flags: DJC
The necessary S,G (1.1.1.1, 224.1.1.1) is not even listed.

Let's look to see if it's showing the upstream router (75a) as a pim neighbor:
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:
Examining the PIM Neighbors

ip22-R72a#sh ip pim neigh
PIM Neighbor Table
Neighbor Address Interface Uptime Expires Ver Mode
2.1.1.1 Ethernet3/1 2d00h 00:01:15 v2
It is showing the RPF

Interface as e3/3 but
ip22-R72a#sh ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
we expect it to be e3/1
RPF interface: Ethernet3/3
RPF neighbor: ? (4.1.1.2)
RPF route/mask: 1.1.1.1/32
RPF type: unicast (static)
RPF recursion count: 1
Doing distance-preferred lookups across tables
R75a
R72a
Receiver
A
Sender
e0/0
e0/1
e3/1
e3/2
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:
Confirm The Problem With Debug and Solve
ip22-R72a#debug ip mpacket
*Jan 14 09:45:32.972: IP: s=1.1.1.1
*Jan 14 09:45:33.020: IP: s=1.1.1.1
*Jan 14 09:45:33.072: IP: s=1.1.1.1
*Jan 14 09:45:33.120: IP: s=1.1.1.1
(Ethernet3/1)
(Ethernet3/1)
(Ethernet3/1)
(Ethernet3/1)
d=224.2.127.254
d=224.2.127.254
d=224.2.127.254
d=224.2.127.254
len
len
len
len
60,
60,
60,
60,
not
not
not
not
RPF
RPF
RPF
RPF
interface
interface
interface
interface
Add a static rout to solve the problem
ip22-R72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1
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:
Confirm The Solution

ip22-R72a#sh ip rpf 1.1.1.1
RPF neighbor: ? (2.1.1.1)
RPF type: static mroute
Notes:
Confirm The Solution

(*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC
(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA
Incoming interface: Ethernet3/1, RPF nbr 2.1.1.1, Mroute
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
The real confirmation of the solution is that host A now gets packets.
Notes:
Time To Live
RouterA
RouterB
Receiver
R
Sender
S
1.1.1.1
e0/0
1.1.1.2
e0/1
2.1.1.1
e1/1
2.1.1.2
e1/2
3.1.1.1
3.1.1.2
Problem: RouterA is not forwarding packets from source(S) to RouterB's

directly connected receiver(R)
sending to:
224.1.1.1
Troubleshooting:
Let's first look at 'sh ip mroute' on ROUTERA to see the multicast routing state:
Notes:
Look at RouterA MROUTE

ROUTERA#sh ip mroute
(*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL
(*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D
The Source 1.1.1.1 is not being recognised
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:
Check the RPF

ROUTERA#sh ip rpf 1.1.1.1
RPF neighbor: ? (0.0.0.0) - directly connected
RPF type: unicast (connected)
The RPF looks right as it is correctly pointing to e0/0
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:
Check the Interfaces and the Traffic

ROUTERA#sh ip pim int
Address Interface Version/Mode Nbr Query DR
Count Intvl
1.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 1.1.1.2
2.1.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 2.1.1.2
ROUTERA#sh ip mroute active
Active IP Multicast Sources - sending >= 4 kbps
The router does not see any traffic as no sources listed. You could check this with:
ROUTERA#debug ip mpacket
Perhaps the Receiver is not sending any igmp reports (joins) for group 224.1.1.1:
Check this with Debug or igmp group.
Notes:
IGMP Group
ROUTERB#sh ip igmp group

IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
224.0.1.40 Ethernet1/1 00:34:34 never 2.1.1.2
224.1.1.1 Ethernet1/2 00:30:02 00:02:45 3.1.1.2
3.1.1.2 has joined the group so it can only be a

TTL issue if traffic is actually being sent
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:
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
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:
The Fixed TTL - RouterA

ROUTERA#sh ip mroute
(*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL
(*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D
(1.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA
Notes:
The Fixed TTL - RouterA

ROUTERB#sh ip mroute
(*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL
(*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC
(1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA
Notes:
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
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:
The router is Forwarding Packets

ip22-75a#sh ip mroute 224.1.1.1
(*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC
(1.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA
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:
Turn On Debug For The Service

ip22-75a#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ip22-75a(config)#access-list 101 permit udp host 1.1.1.1 host 224.1.1.1
ip22-75a(config)#end
Limit traffic to just the service required

ip22-75a#debug ip mpacket 101
IP multicast packets debugging is on for access list 101
ip22-75a#
*Jan 17 09:04:08.714: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied
Traffic is limited by the TTL threshold
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:
Examine the Interface Configuration

interface Ethernet0/1
ip address 2.1.1.1 255.255.255.0
ip multicast ttl-threshold 15
This interface will only forward traffic with a TTL greater than 15
Often people think the threshold prevent traffic with a greater value being sent
The reverse is true.
Reduce the threshold or delete the line to fix the problem.
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:
Multicast Concepts
IGMP
Chapter Summary
Notes:
Chapter 8
Managing Devices with SNMP
Notes:
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
Notes:

Network Management Concepts
Management Information Base (MIB)
SNMP
Chapter Summary
Notes:
Modern Networks
Modern networks are complex and diverse
Router
server
Router
Router
Server
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:
OSI Model
Application and its

Services
Application
Presentation
Checkpoints and
Activities
Session
End to End Error

Recovery
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
Routes and relays
Manages communication
between adjacent nodes
Transmits bit stream

over physical medium
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:
Location of Network Management

Network Management is a Layer 7 function
Devices that do not have a full protocol stack must be enhanced
Application
Presentation
Session
Transport
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Network
Data Link
Data Link
Data Link
Physical
Physical
Physical
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:
Location of Network Management

Network Management is a Layer 7 function
Devices that do not have a full protocol stack must be enhanced
Application
Presentation
Session
Transport
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Network
Data Link
Data Link
Data Link
Physical
Physical
Physical
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:
Evolution of SNMP
SNMP
SNMPv1 MIB-2
Recommended
status
CMOT
HEMS
SGM P
1986
1987
More than 30
vendors
demonstrate
SNMP products
at Interop
1989
RMON
MIB
SNMPv2
SMI
MIB-1
standard
protocols
1990
SNMPv3
Fundamental
flaws found
and SNMPv2
largely
abandoned
1991
1992
1993
1998
Official internet standard is still SNMPv1

Security limitations caused development of v2 and v3
SNMP v3 has upen ended security model but complex to use
Management needed when network fails to function
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:
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
A management application is typically a Windows Icon Menu Pointer Graphical

User Interface (WIMP-GUI) Application. It sits on top of UDP and IP sending and
receiving SNMP exchanges with many agents across the network.
Every device that is to be managed must have an agent to communicate with the
management application in order to implement the management service. The
exchange of data depends upon both manager and agent understanding the details
and meaning of the Management variable in use. In practice these sit within the
agent device, usually as values held in random access memory. The management
application on the other hand must hold details of which variables are understood
by which devices in the network so must hold more details on backing storage.
Notes:
SNMP within Internet Protocol Suite

SNMP runs over UDP
IPS Layer
Application
End-to-end
OSI Layer
SMTP
Simple
Mail
Transfer
Protocol
FTP
TELNET
virtual
terminal
File
Transfer
Protocol
Transmission Control Protocol (TCP)
5, 6, 7
User Datagram Protocol (UDP)
ICMP
Internetwork
SNMP
3
ARP
Physical
network
Etc.
Packet
radio
X.25
IEEE 802 LAN
2,1
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:
Why over UDP?

UDP is unreliable dont we want reliable management?
. . . Yes of course but
When do you need network management most?
. . . and will the network deliver data reliably then?
If we place SNMP above TCP it cannot see the flaws in the network
We need to see the network as it is in order to manage it
TCP would correct errors or crash!
The network would appear perfect or broken beyond repair
If we are not managing the network then we can use TCP
Managing end system components can be done over TCP
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:
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
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:

SNMP
Chapter Summary
Notes:
SNMP MIBs use a managed Namespace

Pauls machine
is working fine!
Paul
George
Ringo
What did Ringo

call that parameter?
Paul
Peter
Mary
Need unambiguous names

The MIB forms a managed namespace. We need this namespace to be infinitely

expandable and allow different parts of its coverage to be controlled by many
different authorities.
While it is not a simple problem to solve, the MIB is no different to the allocation
of names for domains or email addresses. In much the same way we use a tree
structure so that names can be made unambiguous.
Notes:
ISO - CCITT Managed Namespace
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
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:
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
Notes:
Branches Under Internet (1.3.6.1) in RFC 1213

Directory (1)
Reserved for use with the OSI directory (X.500) and White Pages
Not used by SNMP
Management (2)
Objects defined in IAB-approved documents
Currently has only one entry: the SNMP MIB-2
Experimental (3)
Objects used in Internet experiments
Successes migrate to mgmt(2)
Use of this branch is deprecated
Private (4)
Objects defined unilaterally
Currently has only one entry: enterprise(1)
Allows manufacturers to support capabilities not in mgmt(2)
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:
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
Considerable development work is currently being undertaken to develop MIBs that

can be used to manage security features. Currently few of these have reached
completed RFCs but are being placed under node 5.
Node 6 defines SNMPv2 features. However SNMPv2 has been obsoleted by work
on SNMPv3. Parts of this group can still be used to control proxy management and
community naming.
Node 7 is for Mail Management and RFC 1495 defines variables here.
Node 8 is used for media management and details of RFCs that define variable here
can be found at http://www.iana.org/assignments/media-feature-tags .
Notes:
Management Information Base

Data is held in a database called the MIB
Database is split into a number of management groups (areas)
MIB-1 holds data for eight managed areas - RFC 1156
Total of 114 object definitions
MIB-2 definition RFC 1213
Added two new categories
Improved support for multi-protocol devices
About 50 percent larger (171 object definitions)
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:
MIB-2 Variable Groups

Group
system
interfaces
at
ip
icmp
tcp
udp
egp
transmission
snmp
Description
Number of MIB variables
The managed node
7
Network attachments
23
IP address translation
3
Internet Protocol
38
Internet Control Message Protocol
26
Transmission Control Protocol
19
User Datagram Protocol
7
Exterior Gateway Protocol
18
Physical interface
Simple Network Management Protocol
30
Total:
171
Details of these groups are given in Appendix B.

The system group is used to define the names and contacts for the managed device. It also contains
sysUpTime which identifies the time since the device last rebooted in 0.01 sec units.
The interfaces group includes variables that refer to layer 1 and layer 2 functions of device
interfaces.
The at group holds the ARP table in MIB-1but this was moved to the ip group to a table called the
ipNetToMediaTable in MIB-2.
The ip group includes all the details about ip addresses, routing and statistics information.
The icmp group holds input and output counters for icmp messages which carry ping (echo),
redirects, host unreachable and time exceeded messages among others.
The tcp group holds counters for tcp transfers as well as a table giving details of current tcp
connections open.
The udp group holds counters of input and output udp transfers.
The egp group holds details of exterior gateways status; this gives information about the direct
connection to the Internet.
The transmission group does not contain variables in RFC 1213 but is used to hold extensions in
other RFCs that detail technology specific layer 1 information.
Notes:
MIB-1 and MIB-2 Groups

1.3.6.1.2.
system
at
icmp
udp
MIB-2
10
14
17
ospf
transmission
etc.
bridge . . . etc. . .
11
16
interfaces
ip
tcp
egp
snmp
rmon
MIB-1 RFC 1156

MIB-2 RFC-1213
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:
Structure of Management Information (SMI)

Defined by RFC 1155 (Structure of Management Information)
Expanded by RFC 1212 (Concise MIB Definitions) for MIB-2
Further expanded by RFC 1451 (SMI for SNMPv2)
RFC 2578 SMIv2
Defines all properties of the MIB object
Syntax for the object type
Access allowed for the object (read only, read-write, write only, or not
accessible)
Status of the object (mandatory, optional, deprecated, or obsolete)
Textual description, cross-references, and default value are optional
Indexes used for lookup if a table-oriented object
MIB data defined using ASN.1
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:
Abstract Syntax Notation number 1 (ASN.1)

Formal language developed and standardized by CCITT* (X.208) and ISO
(ISO 8824)
Encoding rules in X.209
Main uses:
Used to define application data independent of hardware or software
Used to define the structure of application and protocol data units
Used to define the management information base for SNMP
Used to encode the data and PDUs in SNMP
Complex syntax rather like a programming language
Possible to define MIB and compile into working manager for access
Originally used for definition of OSI protocols
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:
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
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:
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
In addition to the UNIVERSAL classes a number of application defined data types

are used. These data types are specific to IP and SNMP.
An IP address is in practice a 32 bit field but it is always written as 4 decimal
numbers separated by dots. SMI introduces a data type that is always presented in
dotted decimal form with leading spaces removed.
A counter can be used for counting things. It is different to an integer in that its
size is fixed (32 bits) and when it reaches the maximum value held in 32 bits it
wraps back to zero. The advantage of this is that provided a manager looks at a
variable that is held as a counter often enough it can deduce when the wrapping has
occurred and compensate by adding 232 to the value read. Also there is no need to
reset counters. By reading their current value and storing this, the increase in a
counter can be deduced by retrieving a later value and subtracting the stored initial
number.
Notes:
Example Variables
MIB variables
Meaning
type
sysUpTime
system
ifMtu
interfaces
ifAdminStatus
interfaces
ipDefaultTTL
ip
icmpInRedirects
icmp
tcpMaxConn
tcp
udpOutDatagrams
udp
scalar
Group
Time since last reboot

MTU size
up/down
Default TTL value used
ICMP redirects seen
Max. connection allowed
Datagrams sent
scalar
scalar
scalar
scalar
scalar
scalar
ipNetToMediaTable
ipRouteTable
ARP table
IP routing table
table
table
ip
ip
Notes:

SNMP
Chapter Summary
Notes:
SNMP Protocol Structure

Based on UDP over IP
Stateless data transfer
Simple to operate and implement
No dependence on virtual circuits
Makes NMS location independent
Can be anywhere on an internetwork
Major drawbacks
Security less easy to provide than with TCP
Overcome in SNMPv3 or by adding SSL
Network management reliant on transport
Which may be failing
No acknowledgements of data receipt
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:
SNMP the Protocol

SNMP Architecture includes the protocol, SMI and MIBs
SNMP the protocol is the set of rules for reading and changing data
SNMP
manager
UDP
SNMP
messages
(PDUs)
SNMP
managed
system
t rap
set
get_response
get_next
SNMP object
manipulation
t rap
get_response
set
get_next
get
Management
application
Managed
resources
SNMP managed
objects
get
SNMP
manager
SNMP
agent
UDP
SNMP
device
IP
IP
Link Layer
Link Layer
SNMPv1 has a relatively simple structure in that a management application can

send any one of three messages to an agent and receive a get-response in reply.
Also an agent can sent a uni-directional trap to the manager which is
unacknowledged.
Notes:
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
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:
SNMP Actions
SNMP defines four actions that can be performed on data
Get
Used to retrieve management data
Get-next
Used to retrieve lists and tables of management data
Set
Used to manipulate management information
Trap
Used by agent to report extraordinary events
SNMP makes things happen in agent by setting an action variable
Management
system
Get / get - next / set

Agent
Tr ap/ r esponse
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:
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
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:
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
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:
SNMPv2 and SNMPv3 Security

SNMPv2 added optional encryption and MD5 authentication
Keys could be different between each manager/agent pair
Keys could also include clocks from the two devices
In effect the key changed with each clock tick
So secure that under fault conditions it was possible to loose contact
SNMPv3 adds variable security model
Can be configured with users own authentication and encryption if required
Standard models defined too
Mechanism for aligning times and after reboot to overcome problems with
SNMPv2
New branch of the MIB used to manage security snmpUsmMIB
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:
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
If a management device makes a request of the agent using a message containing an

error, the whole transaction is ignored. This can become a source of frustration
with SNMPv1 so in SNMPv3 get-requests for objects that are correct even when
some part of the message was in error will still be actioned. Error reports indicate
the reason for the error and a pointer points to the incorrect syntax in the message
reply
Notes:
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
(a) Get values
Manager
S et R
Agent
eques
PDU
(b) Get-next values
Manager
Agent
DU
Trap P
t PDU
se PD
espon
GetR
Agent
(c) Set values
(d) Send trap
Get-request, getNext-Request and set-request all start from the management

application and each have the same response a get-response. In SNMPv3 this is
retitled a Response.
A trap passes from the agent to the manager and has no response.
Notes:
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
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:
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
The get-response includes within its reply the exact objuct identifier previously
requested together with its value .
Notes:
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
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:
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
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:
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
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:
SNMPv2 and v3 Additional Functions

GetBulkRequest
Efficiently retrieve large blocks of information
InformRequest
Manager can reliably send a trap to another manager
SNMPv2 and SNMPv3 have significantly improved security
Authentication and privacy
Improved error handling and reporting
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:
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
Within a getBulk-request two parameters are given in addition to a list of object

identifiers. The first gives the number of the object identifiers that are to be
retrieved once only. These will normally be scalar variable rather than tables. The
remaining entries are assumed to be table objects and are repeatedly retrieved as if
repeated getNext-requests had been used with the returned object identifiers used
for the next request. The second parameter limits the maximum number of times
the repetitions will be returned. The returns will stop either when the maximum
repetitions is reach or the end of the table is reached which ever comes first.
Notes:
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
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:
Single and Multi-valued Objects

Objects have multiple instances one for each row
Each row has an index made up from different values
Normally different columns in the same table
For simple scalar objects the instance is taken as zero
Scalar object example
Object name
Instance
sysContact
Type
Value
DisplayString
Groucho Marx
Table object example (single index)

Instance 0
ifIndex
Type
Value
Instance 1 Integer
Instance 2 Integer
ifDescr
Type
ifType
Value
Type
DisplayString Ethernet1 Integer

DisplayString Ethernet2 Integer
ifMtu
Value
Type
...
Value
...
Integer 1500
...
Integer 1500
...
ifTable {1.3.6.1.2.1.2)
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:
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
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:
Multi-valued Index Example

tcpConnState
1.3.6.1.2.1.6.13.1.1.144.19.74.3.1453.144.19.74.99.21
tcpConnLocalAddress
1.3.6.1.2.1.6.13.1.2.144.19.74.3.1453.144.19.74.99.21
tcpConnLocalPort
1.3.6.1.2.1.6.13.1.3.144.19.74.3.1453.144.19.74.99.21
Index
tcpConnState
1.3.6.1.2.1.6.13.1.1
Index
Index
Index
tcpConnLocalAddres tcpConnLocalPort tcpConnRemAddres tcpConnRemPor

1.3.6.1.2.1.6.13.1.2
1.3.6.1.2.1.6.13.1.3
1.3.6.1.2.1.6.13.1.4
1.3.6.1.2.1.6.13.1.5
tcpConnEntry
1.3.6.1.2.1.6.13.1
2 (listen)
0.0.0.0
12
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
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:
Overview of MIB Table

ip
i pNe tToMed i aTab l e
22
i pNe tToMed i aEn t r y
i pNe tToMed i a I f I ndex i pNe tToMed i aPhysAddr ess i pNe t ToMed i aNe tAdd ress
i pNe t ToMed i aType
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
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:
Access to This Table

A get-next request can be made to each of the column entries
The first row of the table will be returned together with its identifier and
index values
Get-next can be repeated using the returned object identifiers
The reply will be the next row of the table
Tables must be read row by row with SNMPv1
SNMPv2 or v3 allows a Get-bulk
Each row will yield a repeated reply saving half the transfers
A row of a table can be read in a single transfer by using a getNext-request that

refers to each of the column nodes within the object fields in the snmp message.
The response will then include the fully qualified object identifiers for the next
(first) entries including their index fields followed by their values.
Notes:
SNMP Messages
SNMP messages have the following format:
SNMP-Message ::= SEQUENCE {
version INTEGER {version-1(0)},
community OCTET STRING,
data
ANY}
Authentication
SNMP message
version_1(1)
Current version number
community
data
GetRequest PDU
GetNextRequest PDU
GetResponse PDU
SetRequest PDU
Trap PDU
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:

SNMP
Chapter Summary
Notes:
Chapter Summary
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
Notes:
Chapter 9
Next Generation Network

Technology
Notes:
Chapter Objectives
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
Notes:

Next Generation Architecture
xDSL Technologies
Deploying IEEE 802.1q VLANs
Core Technologies
QoS
Voice Services
New Applications: IPTV
Chapter Summary
Notes:
21CN High Level Architecture

Customer
Environment
Complex
Cost Sensitive
Multi-Function
Multi-Device
Multi-Service
Real Time and
Streamed
MSAN
Simplified
Aggregation and
Concentration
xDSL
Consumer
SME
Enterprise
Metro
Core
Complex, Costly,
Large, Fast
Multi-function
Wire-speed processing
Multi-access Aggregation
Optical Bulk
transport
Ethernet
WiFi
WiMax
Application and Service

Insertion Point
IMS service broker
requests
Big
Fast
Cost-effective
5500
86
20
Locations in UK:
Millions
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:
Very Large Next Generation Carrier Networks

MSANs
Core
Metro Nodes
Switches
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:

xDSL Technologies
Core Technologies
QoS
Voice Services
Chapter Summary
Notes:
2015 Percentage of Households Access Speed

Access by wired line or wireless
Fiber
80%
VDSL
60%
ADSL
40%
20 Mbit/s
1 km
100 Mbit/s
And above
0.3 km
6 Mbit/s
3.7 km limit
20%
2 Mbit/s or less
5 km limit
1995
2000
2005
2010
2015
2020
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:
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
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:
xDSL Comparison
Type
ADSL
Bit rates
1.512 Mbit/s down,
16640 kbit/s up
ADSL2+ 26 Mbit/s down

HDSL
1.52.0 Mbit/s,
symmetric
Distance
Application
9,00018,000 feet (2.7 Internet access,

5.5 km) of
telecommuting,
1-pair UTP
video-on-demand
15,000 feet (4.5 km) of
2- or 3-pair UTP
T1/E1 replacement
SDSL
1.52.0 Mbit/s,
symmetric
10,000 feet (3 km) of 1- T1/E1 replacement

pair UTP
VDSL
1352 Mbit/s down,

1.52.3 Mbit/s up
9005,000 feet (0.31.5 ATM, HDTV

km) of
1-pair UTP
VDSL2
100Mbit/s +
HDTV = high-definition television

See www.adsl.com, www.dslforum.org
and ITU-T Recommendations G.991G.997
At the moment ADSL running over ATM dominates. Currently delivering up to

about 8 Mbit/s, this is expected to evolve using ADSL.2 to perhaps 16 Mbit/s.
Eventually however it is expected that VDSL running over Ethernet will become
more important as already higher speeds seem achievable and Ethernet presentation
at the Metro Node make this more attractive within the architecture.
To reach the upper speed limits of either technology the loop length must be
restricted to much less than 5 km, to perhaps 1km or even less. This will mean
deploying MSANs in street furniture or even underground if loop services are to
remain on copper.
Notes:
ADSL2+ subscriber range
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:
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+.
VDSL2 (Very-High-Bit-Rate Digital Subscriber Line 2, ITU-T G.993.2 Standard) is an access

technology that exploits the existing infrastructure of copper wires that were originally deployed for
POTS services. It can be deployed from central offices, from fibre-fed cabinets located near the
customer premises, or within buildings.
ITU-T G.993.2 VDSL2 is the newest and most advanced standard of DSL broadband wireline
communications. Designed to support the wide deployment of Triple Play services such as voice,
video, data, high definition television (HDTV) and interactive gaming, VDSL2 enables operators
and carriers to gradually, flexibly, and cost efficiently upgrade existing xDSL-infrastructure.
ITU-T G.993.2 (VDSL2) is an enhancement to G.993.1 VDSL that permits the transmission of
asymmetric and symmetric (Full-Duplex) aggregate data rates up to 200 Mbit/s on twisted pairs
using a bandwidth up to 30 MHz.
VDSL2 deteriorates quickly from a theoretical maximum of 250 Mbit/s at 'source' to 100 Mbit/s at
0.5 km and 50 Mbit/s at 1 km, but degrades at a much slower rate from there, and still outperforms
VDSL. Starting from 1,6 km its performance is equal to ADSL2+.
ADSL-like long reach (LR) performance: ADSL-like long reach performance is one of the key
advantages of VDSL2. LR-VDSL2 enabled systems are capable of supporting speeds of around 1-4
Mbit/s (downstream) over distances of 4 to 5 km, gradually increasing the bit rate up to symmetric
100Mbit/s as loop-length shortens. This means that VDSL2-based systems, unlike VDSL1 systems,
are not limited to short loops or MTU/MDUs only, but can also be used for medium range
applications.
Notes:

xDSL Technologies
Core Technologies
QoS
Voice Services
Chapter Summary
Notes:
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
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:
VLAN Trunking Tag

Destination
Address
Source
Address
TPID
Ether-Type/
Length
Priority CFI
Payload
VID
CRC
Normal 802.3
Frame
TAG Inserted for

802.1P/Q
TCI
4-byte Tag Header contains:

2-byte Tag Protocol Identifier (TPID) with a fixed value of 0x8100.
Indicates that frame carries the 802.1Q/802.1p Tag information.
2-byte Tag Control Information (TCI) with the following elements:
3-bit user_priority: 3-bit binary number capable of representing priority levels, 0 through 7.
This field is used primarily by the 802.1p standard.
1-bit Canonical Format Indicator (CFI): With a CFI value of 0, it indicates canonical format;
A value of 1 indicates non-canonical format used in Token Ring and FDDI
12-bit VLAN Identifier (VID): VLAN 0 and 4095 are reserved, other values represent VLANs.
This field is used primarily by the 802.1Q standard.
Standard allows less than the maximum 4094 VLANs to be supported.
For details see IEEE Std 802.1Q, 2003 Edition
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:
Additional Features on Switches:802.1P

IEEE 802.1P Priority for class of service
Allows user configuration of service class
Station assigns a priority value to each frame
Switch assigns to one of a number of queues dependent upon value
Example
user_priority
Traffic Type
Background
Spare
Best Effort
Excellent Effort
Controlled Load
Video
Voice
Network Control
User Priority to Traffic Class mapping

The first three additional bits hold a priority field which give 8 different priority
levels.
Notes:
Enabling Technologies
xDSL Technologies
Core Technologies
QoS
Voice Services
Chapter Summary
Notes:
Delivering QoS in the Core Network

The Internet has evolved into a ubiquitous network
Not designed to give QoS to voice or other real-time users
New applications demand increased core bandwidth
Traditional routing at Layer 3 at high speed is not feasible in software
Need switching in hardware at Layer 2 or Layer 3
Multi-Protocol Label Switching (MPLS) implemented in Label Switching
Routers (LSR)
LSR
LSR
LSR
LSR
LSR
LSR
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:
Multi-Protocol Label Switching

MPLS adds a label as a shim header above the link header and below
Network Layer
Includes a 20-bit label and TTL
It can use identifiers instead in ATM and frame relay
Label Edge Routers (LER) add and remove labels
LSRs use Label Distribution Protocol to agree labels for destination
PPP
Shim MPLS Header
Label
added
LSR
LSR
17
Layer 3
17
Label
removed
LSR
15
15
3
LER
LER
LSR
LSR
LSR
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:
Normal Routing by IP Forwarding Hop-By-Hop
D est
4 7 .1
4 7 .2
4 7 .3
Routing Table
D est
4 7 .1
4 7 .2
4 7 .3
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
Once the Label Switched Path databases are complete traffic is forwarded hop by
hop based upon these tables.
Notes:
MPLS Label Distribution
Intf Label Dest Intf Label

In In
Out Out
3
0.50 47.1 1
0.40
Intf Dest Intf Label

In
Out Out
3
47.1 1
0.50
Intf
In
3
Request: 47.1
.1
t: 47
ues
q
3
e
R
47.3 3
2
Ma
g:
ppin
0
0 .5
1
2
Label Dest Intf

In
Out
0.40 47.1 1
1
47.1
3
2
Mapping: 0.40
47.2
Labels are distributed along IP routes.
Notes:
Label Switched Path (LSP)

In In
Out Out
3
0.50 47.1 1
0.40
Intf Dest Intf Label
In
Out Out
3
47.1 1
0.50
Intf
In
3
IP 47.1.1.1
1 47.1
3
2
1
1
47.3 3
Label Dest Intf

In
Out
0.40 47.1 1
2
47.2
2
IP 47.1.1.1
When the complete database of LSPs is in place the service can be viewed as a
tunnel from Ingress to Egress.
Notes:
Explicitly Routed LSP ER-LSP

We can have multiple paths based on QOS or address length
In In
Out Out
3
0.50 47.1 1
0.40
Intf
In
3
3
Dest
47.1.1
47.1
Intf
Out
2
1
Label
Out
1.33
0.50
Intf
In
3
Label Dest Intf

In
Out
0.40 47.1 1
IP 47.1.1.1
1 47.1
3
2
1
2
47.3 3
47.2
2
IP 47.1.1.1
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:
MPLS Encapsulation - PPP & LAN Data Links

MPLS Shim Headers (1-n)
n
1
Network Layer Header
and Packet (eg. IP)
Layer 2 Header
(eg. PPP, 802.3)
4 Octets
Label Stack
Entry Format
Label
Exp.
TTL
Label: Label Value, 20 bits (0-16 reserved)

Exp.:
Experimental, 3 bits (was Class of Service)
S:
Bottom of Stack, 1 bit (1 = last entry in label stack)
TTL:
Time to Live, 8 bits
MPLS
MPLSon
onPPP
PPPlinks
linksand
andLANs
LANsuses
usesShim
ShimHeader
HeaderInserted
Inserted
Between
Layer
2
and
Layer
3
Headers
Between Layer 2 and Layer 3 Headers
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:
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
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:
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
IP
IP
#Lp
#Lv
In telecommunications services circuit switching has been in use since the

invention of the telephone exchange in 1892. In a circuit, bits pass as a stream with
synchronous timing in use with a network controlled constant rate clock. It is
desirable that in the future we would build networks that carry both packet and
circuit services but share a common core. This has been done for some time using
circuit based cores deployed using ATM, but these tend to be expensive and
inefficient. Current IETF thinking suggest Gigabit Ethernet technology will be the
preferred option using a packet based core.
MPLS can be used to deliver the required QOS and by using multiple labels. One
label can define the edge service required (say phone or video) while another outer
label can be used inside the network to deliver the QOS.
Notes:
Using MPLS in the 21CN Core
Initial Deployment
Protocols: IPv4, OSPF, MPLS, LDP (DU, LL ret)
Virtualisation: IP VPNs (RFC4364 [RFC2547bis]),
PWE3 (RFC3916)
Resilience: Tx and FRR (RFC 4090)
GR (RFCs 3623, 3478, 3473)
QoS: 7 levels (6 user, 1 control)
Connectionless
Unicast
Possible Future Deployment

Many additional VPNs (000s)
Traffic engineering via RSVP-TE (RFC3209)
Capacity and failure response optimisation via
a bandwidth manager connection oriented
flows
Multicast
IPv6
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:
xDSL Technologies
Core Technologies
QoS
Voice Services
Chapter Summary
Notes:
Quality Delivery Options

There are two approaches to delivering voice quality
High-bandwidth provisioning
Easy and cheap with switched LANs where Gbit/s speeds are possible
Not so easy or cheap to apply over WAN services
Use QoS tools to give voice traffic the conditions for good quality
Tools for maintaining voice quality:
QoS signaling
RSVP, IP precedence, DiffServ
Prioritization tools: queuing techniques; e.g., WFQ
Slow-link efficiency tools; e.g., MTU reduction
Call admission control
WRED
FRTS = Frame Relay Traffic Shaping

RSVP = Resource Reservation Protocol
WFQ = weighted fair queuing
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:
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
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:
Sporadicity of Aggregated Streams
The greater the number of streams,
Sporadicity
the more stable the loading will be,

and thus the delay will be lower and stable
Typically work with a 99% confidence level
Big is beautiful!
2
10
100
1000
Number of streams
10000
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:
Controlling QoS With RSVP

Resource Reservation Protocol (RSVP RFC 2205)
Used by hosts to request QoS
Used by routers to provide QoS
Dynamic; responds to changing requirements
RSVP is a transport-level signaling protocol
Reserves resources along the path of the call
Routers must be capable of RSVP operation
Traffic control is required to implement RSVP
Implies a method to control the use of RSVP
Resources must be available
Authorization to use those resources
Need end-to-end capability
Notes:
Intserv QoS Control

Two QoS types
Controlled load (RFC 2211)
Performance should be similar to uncongested
Controlled quality (RFC 2212)
Limits on delay
Guaranteed bandwidth
Based on MTU, data rate, buffers, etc.
Specified in reservation message
From receiver to source of signal
Interpreted by routers along route
May be redefined along route
Confirmed by initial sender (source of signal)
Notes:
RSVP and Intserv

Integrated services (Intserv)
Defines some QoS parameters, and
How to use them with RSVP
Sender (transmit end) in new session registers with RSVP
Describes the traffic to be sent
Describes sender QoS capabilities
Sent in path message to receiver
Path message processed and possibly modified by nodes along route
Describe capability to conform to the traffic defined by the source
Receiver interprets result and forms a reservation request
Based on the request of the source as modified by routers on the route
Sent back to the sender via the same route
There may be many such receivers
Reservations are merged as they are combined in the reverse direction
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:
Use of RSVP Path and Reservation Messages

Path message defines the QoS request of the sender
Nodes along the route retain the path information
Confirm or deny the ability to provide the required resources
Reservation
message
Path message
Receiver verifies the accumulated confirmations

Creates a reservation message; sent back to sender along the same path
Confirms to the nodes that the reservation should be initiated
May be collected, combined with many reservation messages from several
receivers
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:
Problems With RSVP

RSVP reserves resources based on required bandwidth, IP address, and
port (socket)
However, in H.323 call signaling, this is not determined until
After ringing starts, and
After capabilities exchange, and
Logical channels are selected
Call may be answered before RSVP can be confirmed
May not get required resources!
RSVP and queuing priorities cooperation is lacking
For example, WFQ
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:
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
Notes:
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
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:
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
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:
DiffServ and TOS Field
Differentiated services codepoint
RFC 2474 proposes changes to the meaning of the TOS field

First 6 bits are entitled the differentiated services codepoint
Last 2 bits are unused
Eight codepoints allocated for backward compatibility with RFC 791
xxxxx0 codes are for standard actions
YYY000 called class selector codepoints
Devices using these must offer different queues
Must give priority to YYY=110 and 111 used for routing traffic over 000
DiffServ nodes allocate nonclass selector codepoints to different services
Have local meaning and need conversion at boundary of the domain
By allocated a different value of DSCP to each service, particularly over the

customer xDSL loop, it will be possible to give precedence to voice services over
Internet Web-surfing and downloading.
Notes:
Weighted Fair Queuing (WFQ)

Each quality-of-service technique establishes a series of router queues
The router must decide which packet to output next
We could give high-priority traffic absolute priority
But then low-priority traffic may never get through
Delays to TCP data traffic cause retransmission
This makes things even worse
Instead, we normally choose to use weighted fair queuing
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:
Forms of WFQ
There are two forms of WFQ
Flow based
Class based
Notes:
Forms of WFQ: Flow Based

With flow-based WFQ, packets are classified by flow
Packets for the same full association with the same TOS field belong to the
same flow
Each flow corresponds to a separate output queue
WFQ allocates an equal share of the bandwidth to each active queue
Flow-based WFQ is also called Fair Queuing (FQ) because all flows are
equally weighted
Flow 1
Flow 2
Flow 3
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:
Forms of WFQ: Class Based

Class based
Packets assigned to different queues based on their QoS group or the IP
precedence in the TOS field
QoS group is an internal classification of packets used by the router
Configured using a class map
TOS-based WFQ classifies packets based only on the 2 low-order IP
precedence bits
Weights can be allocated to each class
For example, a weight of 50 allocates at least 50 percent of the outgoing
bandwidth during busy times
Class base WFQ gives even greater control.
Notes:
Forms of WFQ: Class Based
Class 1
Class 2
Weight = 50
Weight = 30
Class Default
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:
xDSL Technologies
Core Technologies
QoS
Voice Services
Chapter Summary
Notes:
Standards for VoIP

There are two sources of standards for VoIP technology
International Telecommunication UnionTechnical Standardization Section
(ITU-T)
ITU-T architecture for multimedia conferencing over packet networks
ITU-T H-series standards define transmission of non-telephone signals
H.323 Most of the currently available products use this
Interfaces easily with worlds telephone networks
Signaling is transferred from ISDN
H.248 for controlling Media Gateways
IETF SIP: the Session Initiation Protocol
Much simpler to understand and use for simple voice calls
Should be simpler to implement for developers, but
Interfacing to ISDN is more difficult
Media Gateways and conferencing provided by MEGACO
Same as H.248
Notes:
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)
H.323 is an overview recommendation and forms the basis for a suite of protocols
defined in a family of recommendation.
Notes:
What Counts as Multimedia?

Voice and audio
Video
Conferences
Mixed conversation
BB
Voice is 3.1kHz bandwidth while Audio may be greater even CD quality stereo
with a 20kHz bandwidth.
Notes:
Voice and Audio

Audio signals
Encoded using standard codecs
CODer/DECoder converts to
digital
G.711 at 64 kbit/s as default
Others: G.722, G.728, G.729,
MPEG1 audio, and G.723
Examine these later in the
course
BB
Formatted in digital form

Described in H.225 and RTP
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:
Video
Video signals
H.261 QCIF as minimum
QCIF: Quarter Common Intermediate Format
Other formats possible: H.263
May include audio as well
Video in the context of H.323 standardization normally implies H.261 or H.263.

Better video representation and much more efficient encoding is now available
from MPEG-4 and this can also be carried in the same way.
Notes:
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!
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:
How Is a Normal Phone Call Connected?

Calls start from phones attached
Connected by lines or loops to Central Office (CO) or Local Exchange (LX)
Private branch exchanges (PBX) are owned by user organizations
Small PBXs are called key systems
Transit Exchanges (TX) join LX to distant TX or CO
Loops or lines
PBX
Trunks
Fax
CO
LX
TX
TX
Key system
LX
Notes:
Encoding the Content of Calls

Voices and multimedia contents of calls carry real time information
In traditional voice networks timing is maintained
Packet networks do not guarantee timing
Media channels are transported with RTP
Real-time Transport Protocol (RTP) includes sequence and timestamps
Defined in RFC 1889
Silence can be removed, reducing the bits needed for a call
Receiver can reorder out-of-sequence packets
Smoothes out delay variations called jitter
Achieved by delaying samples to the speed of the slowest
Feedback is provided to the sender using RTCP
Receiver sends back quality information on jitter and packet loss
Also carries identity information
Notes:
Removing Silence With RTP
Sequence = 3
Timestamp=144
Sequence = 1
Timestamp=100
Sequence = 4
Timestamp=154
Sequence = 2
Timestamp=110
160
140
120
100
Silence threshold
Time
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:

TCP/IP protocol suite includes protocols for real-time applications
Real-Time Control Protocol (RTCP)
RTP provides
Timestamping, sequence number
For playback timing and synchronization
Setting up real-time applications
Audio and video
RTCP provides
Reporting on achieved results
Delay, packet loss statistics
Receiver report on jitter delay
Defined in RFC 1889
Notes:
Real-Time Applications on Packet Networks

To be intelligible, our speech must be played out with the same timing
relationship between words as the original
Received packets may not all arrive with exactly the same delay
This is called jitter
Real-time Transport Protocol marks the voice samples with a timestamp
That timestamp is used to play out the packet in sequence
With the correct relative time relationship
Youre
right
This
is
an
IP
telephony
course
Sent
Received
Notes:
Session Initialization Protocol (SIP)

Application Layer protocol (RFC 2543)
Create, modify, terminate sessions
Two or more participants
Multimedia protocolsimilar to H.323
Not just voice
Default well-known-port is 5060
Supports five main functions
User location
Terminal capabilities
User availability
Call setup
Call handling
I have taken this SIP discussion from RFC2543bis Nov 24 2000

We will look at it in overview and see how the protocol is put together. So far I
have not been able to find any SIP products that work well or even close to as well
as the H.323 classroom demonstrations. This section is theory, smoke and
mirrors!!!!!
Notes:
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
SIP default well knownport is 5060. This is used to pass signaling messages
between servers.
Notes:
Simple SIP Call Setup

SIP signaling based on requests and responses, called transactions in SIP
Text based (rather than encoded binary messages used in H.323)
Based on HTTP/1.1 (RFC 2068)
Step 1 is to open a signaling channel with an Invite message
Sent to the SIP address URL (which may include a port number)
Can use UDP or TCP to well-known port 5060 at user IP address
Invite message contains enough information to immediately establish a
media channel to the caller
Includes addressing and codec capabilities
INVITE: address and codec
Media channel
200 OK
address & codec
Media channel
ACK
ACK = acknowledgment
This is a simple point to point call with signals passing from client port to 5060 on
the destination.
Notes:
SIP Entities
SIP Registrar
Location Server
SIP Proxy
(outbound)
SIP Registrar
SIP Proxy
SIP Redirect Server

SIP User Agent
pc.work.com
home.net
Bestneutral.com
SIP User Agent

bed.home.net
Notes:
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
Bobs SIP phone

atlanta.com
Proxy
INVITE
100 Trying
INVITE
100 Trying
180 Ringing
180 Ringing
200 OK
biloxi.com
Proxy
200 OK
INVITE
180 Ringing
200 OK
ACK
Media Session
BYE
200 OK
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:
Megaco Protocol (RFC 3015)

Megaco Protocol Version 1.0 in RFC 3015
Replaces 0.8 in RFC2885
Previously known as Media Gateway Control Protocol (MGCP)
Purpose of Megaco:
Control of distributed gateways between IP networks and GSTN
Implements the signaling layers of H.323
Specifically for voice
Purpose is similar to gatekeeper controlling access to a gateway
Now common protocol with H.248
Provides for both a media gateway and a signaling gateway
Interface to the PSTN signaling network
Common Channel Signaling System #7
Master/slave protocol allowing intelligence to be held within service
MGCP = Media Gateway Control Protocol
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:
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
Notes:
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)
Notes:
New H.248 Division

H.248 (Main
body and
Annexes A to E)
H.248.1
Gateway control protocol Version 2
H.248, Annex F
H.248.2
Facsimile, text conversation and call discrimination

packages
H.248, Annex G
H.248.3
User interface elements and action packages
H.248, Annex H
H.248.4
Transport over SCTP
H.248, Annex I
H.248.5
Transport over ATM
H.248, Annex J
H.248.6
Dynamic tone definition package
H.248, Annex K
H.248.7
Generic announcement package
H.248, Annex L
H.248.8
Error codes and service change reason description
H.248, Annex M.1
H.248.9
Advanced media server packages
H.248, Annex
M.2
H.248.10
Media gateway resource congestion

handling package
H.248, Annex M.3
H.248.11
Media gateway overload control package
H.248, Annex M.4
H.248.12
H.248 packages for H.323 and H.324 interworking
H.248, Annex M.5
H.248.13
Quality alert ceasing package
H.248, Annex M.6
H.248.14
Inactivity timer package
H.248, Annex N
H.248.15
SDP H.248 package
Notes:
Next Generation Network: Soft Switch Model

SS7
Network
Signaling
Gateway
SS7
SIGTRAN/TALI/Q.2111
Q-BICC/SIP-T
SS7
SS7
Gateway
Controller
Gateway
Controller
Wireless
Access
MEGACO/H.248
Trunking
Gateway
Enterprise
MEGACO/H.248
Media
Gateway
IP/ATM
PSTN
Access
NEW
DOMAIN
RTP/RTCP
ASP
Next generation switches will be soft and will depend upon a family of protocols.
Notes:
xDSL Technologies
Core Technologies
QoS
Voice Services
Chapter Summary
Notes:
Typical IPTV Architecture

IPTV Head End
Decoders and
Transcoders
Video End Head (VEH)

Video Hub Office (VHO)
VoD
Server
Video Serving Office (VSO)
Management
and
Control
system
Streamers
Core
Internet
Access
This is a representation of a typical IPTV architecture. The Video On Demand

server is a computer with programs stored on hard disk that can be downloaded by
subscribers and played. Some implementations allow these to be played during the
download in real time wile others download into local storage contained in the
customer set-top box or PC.
Live TV will be streamed out of a streamer and carried over multicasting protocols
across the core network to the access and then on to the receivers.
Notes:
IPTV Applications and there Needs

What is IPTV?
Web TV
Video viewed from the Internet live or stored on a server
Access made through a web browser interface
Needs web access and core capacity at speed compatible with service
Video played on Demand over IP network on a PC or viewer
Each user is typically a stream of packets sent by the server
User interface generally allows pause/rewind/forward like video recorder
Can be used for premium movie services
Needs web access and core capacity at speed compatible with service
Multicast broadcast TV played over the Internet or private IP network
Many viewers watching the same single stream at the same time
May or may not be able to store and replay locally
Core capacity for all channels being viewed
Access capacity for number of channels viewed in parallel
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:
Encoding and Trans-coding

An important part of the Headend function is encoding TV signals
Feeds may arrive in one satellite modulation format and be re-coded to
another for more efficient onward transmission
NTSC feeds may be converted to PAL
Encoding of analogue to MPEG-2 or even MPEG-4 may be required
The selection of the vendor for headend equipment is often based upon
the quality of such codecs and trans-coding
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:
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
European companies currently lead the world in TV control systems. TANDBERG

has a complete range of management system for both small and large MPEG-2
broadcast head-ends for configuration, system monitoring and redundancy. Ideally
suited to controlling and monitoring satellite, cable and terrestrial super head-ends,
especially where n+m multiplexing is required to save costs. Powerful remultiplexing capabilities make it perfect for digital turnaround applications. Cost
effective device only control is available for the simpler regional head-end.
These have recently been installed in the largest cable systems in the world and
continue to dominate the control of state of the art headend control.
The latest generation systems introduced in 2005 have the capability to work using
all IP services. While the channel and studio side has been IP enabled on many
systems for a year or so, now even distribution can be based on IP. The first All IP
system deploying MP4 encoding for HDTV was installed in Europe during 2004.
This is likely to spread throughout the whole industry over the next few years.
Notes:
Program Distribution
Switches switch Ethernet Frames and/or IP packets in hardware
By using hardware they are faster than routing in software
Routers route IP packets based upon IP addresses
Able to direct traffic towards the exact destination
Primary Streamer
Backup Streamer
Layer 2
Switches
Multicast
Routers
IP Distribution
Network
Control station uses SNMP to switch streamers

if necessary
Streamers stream from same IP address
Routers use VRRP/HSRP to guarantee router
reachability
Were a network is to be used for distributing commercial television services

including advertising relibility of service is critical. TV industry standards require
services that can automatically recover from any failure within 10 seconds or less.
Where paid-for advertising is in use penalties may result from an interruption of
service of only 3 seconds. Early designs of set-top services map TV channels on to
multicast groups at Layer 3 with fixed source addresses. This requires that alternate
sources are available within the distribution network which will take on the same IP
source address in the event of a primary failure. Network service detectors can be
used to verify that channels are received correctly down-stream and the service
management system deployed to use SNMP for switching network components
when failures occur.
Notes:
Resilience
When designing TV distribution reliability is key
Industry standard requires switch-over on any failure within 10 seconds
Penalties can result if advertisements are interrupted by even 3 seconds
Services may use downstream detectors to verify channel reception
Primary Streamer
Backup Streamer
Layer 2
Switches
Multicast
Routers
IP Distribution
Network
Control station uses SNMP to switch streamers

if necessary
Streamers stream from same IP address
Routers use VRRP/HSRP to guarantee router
reachability
Were a network is to be used for distributing commercial television services

including advertising relibility of service is critical. TV industry standards require
services that can automatically recover from any failure within 10 seconds or less.
Where paid-for advertising is in use penalties may result from an interruption of
service of only 3 seconds. Early designs of set-top services map TV channels on to
multicast groups at Layer 3 with fixed source addresses. This requires that alternate
sources are available within the distribution network which will take on the same IP
source address in the event of a primary failure. Network service detectors can be
used to verify that channels are received correctly down-stream and the service
management system deployed to use SNMP for switching network components
when failures occur.
Notes:
Satellite Access
IPTV Head End
Commercial channels
distributed by satellite
Decoders and
Transcoders
Decoders deliver
service that may be
transcoded to match
distribution standards
VoD
Server
Management
and
Control
system
Streamers
Operators may use

telecommunications
carriers service on
agency basis
Core
Time-slip TV produced
by storage on server
farm near downlink
Internet
Access
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:
Core Network
IPTV Head End
Core network is high

bandwidth
Decoders and
Transcoders
Must deliver high

reliability over long
range
VoD
Server
Management
and
Control
system
Streamers
Multiple QoS
May interface to the
Internet
Must use BGP
routing at the
interface to the
Internet
Often MPLS for
speed inside
Core
Internet
Access
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:
Video On Demand
Take-up of video on demand services is key to design of network
The greater the take-up the shorter the distance needed to the user
Possible Designs
Low Take-up System
High Take-up System
Core
Access
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:
Internet Access Services

Interconnection to Internet designed for required bandwidth and reliability
Typically dual homes connection
QoS services might be available for external services
Must be available for internal voice and video
Core
Internet
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:
Triple Play Network

Voice support must be provisioned with required capacity needs
Call controller call rates must be sized and supported
Resilience of call server might be an issue and must be considered
QoS over the access will probably be required
Perhaps with DiffServ and/or VLAN for voice
Interconnection to external SS7 gateway services must be considered
Gateway to International ISDN services may be required
GW
Core
ISDN
Internet
Call Servers
Residential
Gateway
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:
xDSL Technologies
Core Technologies
QoS
Voice Services
Chapter Summary
Notes:
Chapter Summary
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
Notes:
Chapter 10
The Customer Home Network
Notes:
Chapter Objectives
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
Notes:
Next Generation and Future Technology

Structure of home media interface
Next Generation Set-top Box
Home Interface to Triple Play Networks
Protected Broadcast Architecture
Encryption and Authentication Systems
Watermarking
Digital Rights Management
Chapter Summary
Notes:
Multimedia Home Platform Context
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:
Multimedia Home Platform
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:
Basic MHP Architecture
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:
Interfaces
Interfaces Between
Between an
an MHP
MHP Application
Application and
and the
the MHP
MHP System
System
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:
Plug-ins
A "plug-in" is a set of functionality that can be added to a generic platform in order

to provide interpretation of application and content formats not specified by this
specification to be included in MHP terminals.
NOTE: Those organisations concerned with interoperation between the standard
MHP platform and other platforms need to specify the plug-in properly for such
platforms.
The choice of which plug-ins to use must be in the hands of the end-user in order
that he can have a choice of sources of service. This option can be exercised in a
number of ways, including the purchase of equipment with "built-in" plug-in
functionality, the positive selection of a download, or the automatic selection of a
download where there is no memory resource limitation.
The plug-in may stay resident where the design of the platform implementation
allows. The MHP including the plug-in
must behave, once the plug-in is loaded and operational, in the same way as a
platform supporting the format of the
delegated applications without the use of a plug-in.
Notes:
Block Diagram of ETSI Standard Interface Box
Notes:
Broadcast Channel Protocol Stack
Except in the case of MPEG-2 sections when an MHP application attempts to

access conditional access scrambled data through one of these broadcast channel
protocols, the MHP terminal shall attempt to
initiate descrambling of this data without the application needing to explicitly ask
for it. Attempts to access conditional access scrambled data at the level of MPEG-2
sections shall not happen without the application explicitly asking for this.
Notes:
Interaction Channel Protocols Stack
Th Interaction channel provides programme selection and control of services

provided. The set of DVB defined interaction channel protocols that are accessible
by MHP applications in some
or all profiles are based on world wide web Internet protocols.
The UNO-RPC consists of the Internet Inter-ORB Protocol (IIOP) as specified in
CORBA/IIOP.
Applications are likely to be deployed using Java virtual machines in order to
maintain hardware independence
Notes:

Watermarking
Chapter Summary
Notes:
Next Generation Set Top Box
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:
Next Generation Set-Top Box

Convergence of computing, communications and consumer electronics.
Software codecs for Windows Media* Video 9
MPEG-1, MPEG-2 and MPEG-4 compression formats
Ultra Low Voltage Processor 800 MHz delivers scalable processing
Ethernet controller providing integrated network connectivity
10BASE-T and 100BASE-TX physical layer capabilities
The next generation media centres will have high quality outputs
Surround sound using Dolby 5.1 audio
HDTV digital outputs
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:
Software in Set-Top Box

Core middleware software building blocks
Advanced compression
encoding for digital video
enabling service providers to
distribute video-on-demand
Middleware for Network
Media Processing
software
Flash memory over-network
download
Distribution over IP
Provides common transport
across all distributions
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:
Internet Television Portals
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:
Web TV From North America
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:
Web TV From Europe
Notes:
Web TV From Europe
Notes:
High Definition Television (HDTV)

Definition: The high-resolution subset of our DTV system.
The US FCC has no official definition for HDTV.
The ATSC defines HDTV as a 16:9 image with twice the horizontal and
vertical resolution of our existing system, accompanied by 5.1 channels of
Dolby Digital audio
The CEA defines HDTV as an image with 720 progressive or 1080
interlaced active (top to bottom) scan lines. 1280:720p and 1920:1080i are
typically accepted as high-definition scan rates
Another definition is to say television that delivers:-
A picture 4 feet wide when viewed from a distance of 12 feet that delivers
resolution at the eye similar to that obtained in a movie theatre
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:

Watermarking
Chapter Summary
Notes:
TV Down the Phone Line

Today we deliver digital TV using MPEG-2 over channels of about 5 Mbit/s
With MPEG-4 we can deliver HDTV with 5.1 Dolby sound and 5 caption
channels in the same bandwidth
We can now deliver this over a phone line carrying 10 Mbit/s
BT is to spend 10,000,000,000 over 5 years enabling this to every UK
home
Services are already feasible in parts of Sweden
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:
Internet Video Magazines and Webcasts
Integrating video with Web services makes it feasible to produce hybrid services
that combine features of many technologies.
Notes:
Triple Play Networks

Triple play networks deliver Video, Voice and Data services over the same
network
By adding mobility this may also be called Quadruple Play
Such networks could be wired or wireless
Most currently are wired based upon UTP
Future services could be offered over fiber at even higher speeds
The attraction to the customer is low cost high quality varied services
Hundreds of channels of TV from anywhere in the world
Better TV definition and quality: Cinema quality in the living room
Information rich Internet access:
Near free interpersonal communications: Voice, text and possible video
Opportunities for new applications and businesses from anywhere
Interactive gaming around the world
Enabling new business ideas for little initial investment
Delivering what the Internet promised in the 1990s
Notes:
Convergence Protocol Stacks

To deliver Triple Play or even Quadruple Play we need common flexible
protocol stacks
The protocols must be open and proven to be interoperable
Data will run over IP and so the foundation of all new services is IP
MPEG
HTTP
RTP
TCP
UDP
IP
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:
MPEG Compression Protocols

MPEG-3 abandoned but audio encoding
MPEG-4 ISO/IEC JTC1/SC29/WG11 N4668
MPEG-7 ISO/IEC JTC1/SC29/WG11N6828
Adds descriptions language for multimedia
MPEG-21 ISO/IEC JTC1/SC29/WG11/N5231
Adds digital rights management
Moving Picture Experts Group (MPEG) a working group of ISO/IEC in charge of

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

Watermarking
Chapter Summary
Notes:
Conditional Access Systems
A conditional access system comprises a combination of scrambling and encryption

to prevent unauthorised reception. Encryption is the process of protecting the secret
keys that are transmitted with a scrambled signal to enable the descrambler to work.
The scrambler key, called the control word must, of course, be sent to the receiver
in encrypted form as an entitlement control message (ECM). The CA subsystem in
the receiver will decrypt the control word only when authorised to do so; that
authority is sent to the receiver in the form of an entitlement management message
(EMM). This layered approach is fundamental to all proprietry CA systems in use
today.
Notes:
Digital Encryption Standard: Simulcrypt
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:
Conditional Access Identifications

CA identifiers
0x0001
0x0100
0x0200
0x0300
0x0400
0x0500
0x0600
0x0700
0x0800
0x0900
0x0A00
0x0B00
0x0C00
0x0D00
0x0E00
0x0F00
0x1000
0x1100
0x1200
0x1300
0x1400
0x1500
0x1600
0x1700
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
0x00FF
0x01FF
0x02FF
0x03FF
0x04FF
0x05FF
0x06FF
0x07FF
0x08FF
0x09FF
0x0AFF
0x0BFF
0x0CFF
0x0DFF
0x0EFF
0x0FFF
0x10FF
0x11FF
0x12FF
0x13FF
0x14FF
0x15FF
0x16FF
0x17FF
Standardized systems
Canal Plus
CCETT
Deutsche Telecom
Eurodec
France Telecom
Irdeto
Jerrold/GI
Matra Communication
News Datacom
Nokia
Norwegian Telekom
NTL
Philips
Scientific Atlanta
Sony
Tandberg Television
Thomson
TV/Com
HPT - Croatian Post and Telecommunications
HRT - Croatian Radio and Television
IBM
Nera
BetaTechnik
Notes:
Copy Protection Schemes

The Copy Control Information (CCI) communications the conditions under
which a consumer is authorized to make a copy.
CCI: CGMS + APS + Other
Copy Generation Management Information (CGMS-A or D)

0,0 Copy-free
0,1 Undefined (to be used for No-more-copies)
1,0 Copy-once
1,1 Never-copy
Analog Protection System (APS) Trigger Bits

0,0 Off
0,1 PSP on; inverted split color burst off
1,0 PSP on; 2-line inverted split color burst on
1,1 PSP on; 4-line inverted split color burst on
Other
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:
Content Protection Technologies

Content protection technologies offer methods prevent unauthorized
access (for playback or recording)
May include text, graphics, pictures, audio and video
Two important technologies

Encryption
Watermarking
Encryption-based technologies transform copyrighted digital content into

unintelligible or unviewable format.
Watermark-based technologies embed data directly into copyrighted

digital content.
Hybrid technologies: Combine features from encryption and

watermarking technologies.
As technology progresses so too do the commercial threats from the theft of

intellectual property. Content protection must deliver the ability to restrict access
and to trace breaches in access protection.
Notes:
Types of Piracy
Commercial piracy: a commercial entity steals content, makes a master,
and begins making and selling illegitimate copies
Commercial entities with a manufacturing facility will always be able to get
to a clear bit stream, or simply duplicate a prerecorded content
Garage piracy: an individual with smaller resources makes a few

hundred illegitimate copies, and sells or barters them
A garage pirate, skilled in engineering, will be able to take apart his
TV/VCR/STB, and probe a PC board for a clear bit stream
Ant piracy: an individual wants to make a few copies for his friends,
relatives, or even for his own use.
An ant pirate will have very limited resources
Piracy of programming becomes a problem when the intellectual property is of high

value (or at least high price). It is probably true that any protection system built
could be circumvented eventually with the expenditure of enough resources. The
countermeasures must defeat the major threats long enough to allow commercial
exploitation to deliver profitable distribution.
Intellectual property values reduce with time very quickly so protection for days or
weeks may be enough for some services. However major films can retain value for
many years if protection can be maintained.
Notes:
Information Security Objectives

Confidentiality: protecting information from unauthorized disclosure
Primary tool: Encryption
Data integrity: providing assurance that information has not been altered
in an unauthorized way
Primary tool: Hashing
Authentication:
Message authentication: providing assurance of the identity of the sender
(gives no guarantees of timeliness or uniqueness).
Primary tool: Digital signatures
Entity authentication: providing assures of both the identity of
the sender and his active participation in the protocol.
Primary tool: Challenge-response protocols
Non-repudiation: preventing a party from denying a previous action.

Primary tool: Trusted third party service
Notes:

Watermarking
Chapter Summary
Notes:
Encryption: Types of Cipher

Symmetric key cipher: enciphering and deciphering keys are the same or
can be easily determined from each other.
Stream cipher: breaks the message M into successive characters or bits

m1, m2,..., and enciphers each mi with the ith element ki of a key stream
K=k1k2...
Examples: RC4 and SEAL. Stream ciphers can either be symmetric-key or
public-key.
Block cipher: breaks the message M into successive blocks M1, M2,...,
and enciphers each Mi with the same key K.
Examples: DES, FEAL, IDEA, and RC5. Block ciphers can either be
symmetric-key or public-key.
Asymmetric (public) key cipher: enciphering and deciphering keys differ

in such a way that at least one key is computationally infeasible to
determine from the other.
Examples: RSA, ElGamal, and Merkle-Hellman
Notes:
Symmetric Encryption
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:
Asymmetric Encryption
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:
Comparison of Encryption Characteristics

Characteristic
Symmetric
Asymmetric
Speed
Faster
Slower
Secret information
Shared Key
Private Key
Key length
Shorter
Longer
Key Period
Shorter
Longer
Major Problem
Key Distribution
Public Key Authentication
Main Use
Protection of Content
Protection of Keys
Notes:
Digital Signatures
Digital signature: data string which associates a message with some
originating entity
Digital signature scheme: signature generation algorithm & associated

verification algorithm.
Two general classes of digital signature schemes:

digital signature schemes with appendix
digital signature schemes with message recovery
Digital signature scheme with appendix: DS scheme which requires the

message as input to the verification algorithm
Examples: DSA, ElGamal, and Schnorr.
Digital signature scheme with message recovery: DS scheme which does

not require a priori knowledge of the message forthe verification algorithm.
Examples: RSA, Rabin, Nyberg-Rueppel.
The Digital Video Broadcasting Project (DVB) is an industry-led consortium of

over 270 broadcasters, manufacturers, network operators, software developers,
regulatory bodies and others in over 35 countries committed to designing global
standards for the global delivery of digital television and data services. Services
using DVB standards are available on every continent with more than 110 million
DVB receivers deployed.
The networking of communications and access to content anytime, anywhere are
becoming the guiding principles by which the converging broadcast,
telecommunications and IT industries are preparing for the future. It is in this
context that the DVB Project has considered how it can use its strengths to build a
further set of specifications and guidelines to support the transition to this
connected world. This short PowerPoint presentation introduces DVB 3.0, the work
programme that will take the DVB Project into the next phase of its existence. See
http://www.dvb.org/
Notes:
Public Key Infrastructure
Public-Key Infrastructure (PKI)

Combination of software/hardware products, encryption technologies, and services
that enables enterprises to protect their communications on the Internet or other
types of networks.
Integrates digital certificates, public-key cryptography, and certificate authorities into
a total, enterprise-wide network security architecture.
A typical PKI encompasses:

Issuance of digital certificates to individual users and servers
End-user enrollment software; integration with corporate certificate directories
Tools for managing, renewing, and revoking certificates
A typical PKI encompasses:

Issuance of digital certificates to individual users and servers
End-user enrollment software; integration with corporatecertificate directories
Tools for managing, renewing, and revoking certificates
Certificate authorities are the digital worlds equivalent of passport offices
Notes:
Public Key Certificates

Issued by a Trusted Third Party (TTP)
data part : issuer, owner, public key, validity period, etc.
signature part: digital signature over the data part.
X.509 (ITU-T Recommendation & ISO/IEC Standard)

Version
Serial number
Signature algorithm identifier
Issuer name
Validity period
Subject name
Subjects public key information
Issuer unique identifier (optional)
Subject unique identifier (optional)
Signature
Digital signatures can be produced by encrypting identity information using the

private key of a crypto system so that any user can confirm the identity using the
corresponding public key to decrypt. These can be turned into digital certificates of
identity by further signing these using the keys held by a certification authority.
These could be used to identify a customer, or at least the set top box of a customer,
that is entitled to a service.
Notes:

Watermarking
Chapter Summary
Notes:
Data Hiding: Watermarkeing

Data Hiding: process of embedding data(watermark) into multimedia such
as image, video, and audio
Invisibility: degree of distortion introduced by the watermark
Robustness: resistance against attacks and normal A/V processes.
noise, filtering, resampling, scaling, rotation, cropping
lossy compression
A-D-A & D-A-D conversions
Capacity: amount of data that can be represented by the embedded
watermark
Typical use of watermarks

Identification of the origin of content distributed copies of the content
Identification of the origin of tracing illegally distributed copies of the content
Disabling unauthorized access to the content
Notes:
Watermarking Scheme
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:
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
Notes:
Watermark Scaling Factor

The scaling factor
controls the intensity
of the watermark
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:
Discrete Wavelength Transform Watermarking
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:
Example of Watermarking
Notes:
Attacks
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:
Extracted Watermarks
Good watermarking techniques are now capable of defeating such attacks as these
examples show.
Notes:
Extracted Watermarks
Notes:
Pure SVD Extractions
Notes:
Conditional Access (CA) Systems

A conditional access (CA) system allows access to services based on
certain conditions:
Payment
Identification
Authorization
Registration
Service providers
Satellite broadcasters: DirecTV, Dish Network
Terrestrial broadcasters: ABC, CBS, NBC
Cable operators: Time-Warner, AT&T, Comcast
Services
Subscription
Pay-Per-View
Video-on-Demand
CA vendors: NDS, Canal+, Nagravision
Conditional access systems are the key to successful paid commercial distribution
systems.
Notes:
CA System Architecture
Notes:

A Digital Rights Management (DRM) system protects, distributes, modifies
and enforces the rights associated with digital content.
Primary responsibilities of a DRM system
Secure delivery of content
Prevention of unauthorized access
Enforcement of usage rules
Monitoring of the use of content
Superdistribution: a relatively new concept for redistributing content

across the Internet
Allows the customers to forward encrypted content to other
customers
The content forwarded to a potential buyer cannot be accessed
unless the new rights are obtained
May help widen the market penetration
DRM system vendors: Intertrust, Microsoft, IBM
Notes:

Watermarking
Chapter Summary
Notes:
Digital Rights Management (DRM) System Architecture
Notes:
Interoperability of DRM Systems

Today there are many standards that ensure the interoperability of
consumer electronics devices. A consumer may buy a Sony TV set and
connect it to a RCA DVD player
Interoperability is also essential for content protection systems like

Content Scramble System (CSS) for DVD player .
Unfortunately, a client device supporting the DRM system X can only

download content protected by the same system
Currently, there is no interoperability among the DRM systems for a

number of important reasons:
Every DRM system has secret keys/algorithms. DRM vendors are
concerned about sharing secret keys/algorithms
Metadata is data about data that describes the content, quality, condition,
and other characteristics of data. Although Rights expression languages
(RELs) are emerging as essential components of DRM systems, they are
not standardized yet
Notes:
The Complete Package

Conditional Access (CA)
Satellite, cable & terrestrial content
Content is protected in delivery
Consumer has access to content based on a condition
Privately defined system
Digital Rights Management (DRM)

Primarily Internet content
Content is protected in delivery and storage
Consumer purchases usage rights
Privately defined system
Copy Protection (CP)

Prevention of illegal copying
Interface protection & storage protection
CA + DRM + CP = Content protection
Notes:

Watermarking
Chapter Summary
Notes:
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
Notes:
Chapter 11
Industry Trends
Notes:
Chapter Objectives
Describe the short term future industry changes
Appreciate the long term trend in the technologies
Notes:
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
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:
IPTV and VOD

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

Access speed increases about four times every four years
Access Speed in
Kbit/s
100000.0
10000.0
10000
1000.0
1000
512
100.0
14.4
10.0
1.2
1.0
28.8
56
2.4
0.3
0.1
1980
1985
1990
1995
2000
2005
2010
2015
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:
Home IPTV Profile

At the moment access speeds limit IPTV services
We need 5 Mbit/s for each HDTV channel viewed in parallel
2 TV households are the norm
Access needs to double average useage rate
20 Mbit/s is target for dual HDTV service
Notes:
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
Notes:
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?
Notes:
User Created Media: Shoutcast.com
SHOUTcast is Nullsoft's Free Winamp-based distributed streaming audio system.

Thousands of broadcasters around the world are waiting for you to tune in and
listen. Take a peek through the SHOUTcast directory (immediately listed below) to
start browsing the most popular stations. Be sure to select your connection speed
and then what kind of music you're looking for over on the right hand side for
optimal listening pleasure. All you need is a player (we recommend Winamp) and
you're set to go!
Wanna be a broadcaster? It's Free! Check the online docs to get started!
Notes:
Yospace.com
Case Study: MCP Community Gallery Powers 3 UK's See Me TV

Mobile media company 3 was first to utilise the MCP Community Gallery technology to power their
successful "reality TV" consumer service, See Me TV.
The service was launched in mid-October 2005, and as the UK's first ever mobile community video
download gallery, it has been a phenomenal success.
3 UK's customers can submit video clips by MMS to shortcode 32323. The clips are moderated and
accepted clips are placed into an appropriate category within the handset based gallery. The original
sender is informed of the clip's acceptance by text message, which also invites them into See Me TV
if they are a first-time contributor.
Any of 3 UK's 3.2 million customers can use their video mobile to browse, search and download
clips from the gallery. The clips range in price from 10p to 50p. Customers who have submitted clips
into the gallery can manage their clips from the service and view how many downloads they've had.
Contributors are paid a small share of revenue generated from their submitted content, which is paid
in cash on a monthly basis. The repayments are handled by Yospace's integration with PayPal.
See Me TV is hosted and managed by Yospace with integration into 3's messaging, portal and billing
systems.
Notes:
Chapter Summary
Describe the short term future industry changes
Appreciate the long term trend in the technologies
Notes:
Course Summary
Notes:
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
Compare how DiffServ, DSCP, RSVP, WFQ, MPLS and 802.1P/Q can provide quality
of service
Select the most appropriate quality of service option
Notes:

IPTV Course

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

IPTV Course

Caricato da

Copyright:

Formati disponibili

IPTV Broadcasting, Protocols

Television Architecture and Evolution

Broadband Distribution Systems

IP Delivery of Multimedia Services

Management of Devices With SNMP

Next Generation Network Technology

Customer Home Network

Summary and Evaluation

10:15 a.m. (approximately)

Television Architectures and

Television Architectures and Evolution

What is Television Today?

The Colour Pallet

Forming Television Picture Colour Test Pattern

PAL D1 test Pattern

On CRT displays it is difficult to maintain straight lines and focused colour

Digital Image Standards Compared

Improving the resolution and interlacing, displaying alternate lines in consecutive

RGB Color Detail %

Resolution means picture sharpness and is measured in lines of horizontal resolution.

4.433618 4.433618 4.433618 3.582056 3.575611

Television Architectures and Evolution

What is Television Today?

Television Architectures and Evolution

What is Television Today?

Television Broadcasting Industry

Marketing and Delivery

Architecture of Cable TV Distribution

Cable Distribution System

In a modern cable network other non-TV services might be added. In particular

Expanded Television Services

Television Architectures and Evolution

What is Television Today?

Broadcast Distribution Systems

Broadcast Distribution Systems

Cable TV Delivery Systems

Components of a Cable TV System

Set-top box for

Fiber and coax

Traditional Cable TV Head End Components

Enhanced Cable TV Network Services

Enhanced Head End

Multiple Cable Operators

Interconnected Head Ends

SDH Connected Head Ends

Head End Signal Reception

Encoding and Trans-coding

European companies currently lead the world in TV control systems. TANDBERG

Traditional Coaxial Cable Distribution Components

Designing a Distribution System

Migration to Digital Fiber Systems

Digital Fiber Optic

Fiber Optic Transmission

Step Index Multimode Fiber

Graded Index Multimode Fiber

Single Mode Fiber

GRADED-INDEX MULTIMODE FIBER contains a core in which the refractive

Indoor/Outdoor Tight Buffer

Indoor/Outdoor Breakout Cable

Indoor/Outdoor Tight Buffer

Standard Single Mode Fiber Profile

Standard Single-mode fiber

Single Channel Transmission at 1330 nm

The three principal windows of operation, propagation through a cable, are