IPTV Course Broadcasting Protocols and Switching

IPTV Broadcasting, Protocols
and Switching
Notes:
Silicon-IPTV-Broadcast -1
Course Objectives
When you have completed this course you will be able to

• Understand the equipment and software used to deliver IPTV and VoD services
• Describe the architecture of a these modern TV services
• Compare Cable, over-air terrestrial, satellite and Internet delivery systems
• Appreciate the trend in the technologies
• Understand addressing schemes for IP network prefix configurations
• Examine resilience for MAC/IP mappings for reliable redundancy switching
• Select the best routing and switching strategy for server and delivery networks
• Analyze protocols used to carry multimedia and troubleshoot services problems
• Appreciate how multicast routing protocols function
• Specify requirements for firewall transit of video services
• Compare how DiffServ, DSCP, RSVP, WFQ, MPLS and 802.1P/Q can provide quality
of service
• Select the most appropriate quality of service option
© Copyright: All rights reserved. Not to be reproduced without prior written consent. Silicon-IPTV-Broadcast -2
Notes:
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
• 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
Computer:
VGA 640 480 307,200 100/100/100
SVGA 800 600 480,000 100/100/100
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 "rung-
space-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
PAL
SYSTEM PAL I PAL D PAL N PAL M
B,G,H
Line/Field 625/50 625/50 625/50 625/50 525/60
Horizontal 15.625 15.625 15.625 15.625 15.750
Frequency kHz kHz kHz kHz kHz
Vertical
50 Hz 50 Hz 50 Hz 50 Hz 60 Hz
Frequency
Colour Sub
4.433618 4.433618 4.433618 3.582056 3.575611
Carrier
MHz MHz MHz MHz MHz
Frequency
Video Bandwidth 5.0 MHz 5.5 MHz 6.0 MHz 4.2 MHz 4.2 MHz
Sound Carrier 5.5 MHz 6.0 MHz 6.5 MHz 4.5 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. Total Active Vert. Horz. Opt. Asp. freq.

or lines lines res. res. view ratio MHz
inter. dist.
HDTV p 1050 960 675 600 2.5 16/9 8
USA,
analog
HDTV p 1250 1000 700 700 2.4 16/9 9
Europe,
analog
HDTV NHK i 1125 1080 540 600 3.3 16/9 20
NTSC i 525 484 242 330 7 4/3 4.2

conv.
NTSC prog. p 525 484 340 330 5 4/3 4.2
PAL i 625 575 290 425 6 4/3 5.5

conv.
PAL prog p 625 575 400 425 4.3 4/3 5.5
SECAM i 625 575 290 465 6 4/3 6

conv.
SECAM p 625 575 400 465 4.3 4/3 6
prog
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 three-
channel, 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 freeze-
dried 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 Channels
Marketing and Delivery
Production
Entertainment
Over-the-air
Film Government and Politics
Religion Cable
News Satellite
TV Production Education
Community Internet and IP
Content
Distribution 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 nation’s first CATV system.
John Walson has been recognized by the U.S. Congress and the National Cable
Television Association as the founder of the cable television industry. John Walson
was also the first cable operator to use microwave to import distant television
stations, the first to use coaxial cable for improved picture quality, and the first to
distribute pay television programming (HBO)
Notes:
Architecture of Cable TV Distribution
Programme Channels
Production
Entertainment
Film Government and Politics
News Religion
TV Production Education
Community
Content
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 "off-
air" 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
VideoExpress™video 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 re-
multiplexing 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
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, high-
end 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 index—a measure of
its ability to bend light. Refinements in optical fibers, along with the development of new lasers and
diodes, may one day allow commercial fiber-optic networks to carry trillions of bits of data per
second.
Total internal refection confines light within optical fibers (similar to looking down a mirror made in
the shape of a long paper towel tube). Because the cladding has a lower refractive index, light rays
reflect back into the core if they encounter the cladding at a shallow angle (red lines). A ray that
exceeds a certain "critical" angle escapes from the fiber (yellow line).
STEP-INDEX MULTIMODE FIBER has a large core, up to 100 microns in diameter. As a result,
some of the light rays that make up the digital pulse may travel a direct route, whereas others zigzag
as they bounce off the cladding. These alternative pathways cause the different groupings of light
rays, referred to as modes, to arrive separately at a receiving point. The pulse, an aggregate of
different modes, begins to spread out, losing its well-defined shape. The need to leave spacing
between pulses to prevent overlapping limits bandwidth that is, the amount of information that can
be sent. Consequently, this type of fiber is best suited for transmission over short distances, in an
endoscope, for instance.
Notes:
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 -40ºC to +85ºC).
Indoor/Outdoor Breakout Cable
FIS indoor/outdoor rated breakout style cables are easy to install and simple to terminate without the
need for fanout kits. These rugged and durable cables are OFNR rated so they can be used indoors,
while also having a -40c to +85c operating temperature range and the benefits of fungus, water and
UV protection making them perfect for outdoor applications. They come standard with 2.5mm sub
units and they are available in plenum rated versions.
Aerial Cable/Self-Supporting
Aerial cable provides ease of installation and reduces time and cost. Figure 8 cable can easily be
separated between the fiber and the messenger. Temperature range ( -55ºC to +85ºC)
Armored Cable
Armored cable can be used for rodent protection in direct burial if required. This cable is non-gel
filled and can also be used in aerial applications. The armor can be removed leaving the inner cable
suitable for any indoor/outdoor use. (Temperature rating -40ºC to +85ºC)
Notes:
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
0.6 Standard Single-mode fiber
Attenuation Dispersion +20
Attenuatiom (dB/km)
Dispersion (ps/nmxkm)
0.5 +10
0.4 0
0.3 -10
DWDM
0.2 -20
1300 1400 1500 1600

Wavelength (nm)
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 multi-
megabit 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
0.6 Standard Single-mode fiber
Attenuation Dispersion +20
Attenuatiom (dB/km)
0.5 +10
0.4 0
DWDM
0.3 -10
0.2 -20
1300 1400 1500 1600

Wavelength (nm)
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
800
400
G bit/s per fiber
200
Actual Single Mode Fiber
Performance
Bit Rate < 10 Gbit/s
100 Unamplified
Optimal Operating
Region
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)
0.6 Attenuation Dispersion +20

SSMF
Attenuatiom (dB/km)
0.5 +10
0.4 0
0.3 -10
0.2 LWPF -20
1300 1400 1500 1600

Wavelength (nm)
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
Standard Single-mode fiber

0.6 Dispersion
Attenuation +20
Attenuatiom (dB/km)
0.5 +10
0.4 0
0.3 -10
Long Haul
Fiber
0.2 -20
1300 1400 1500 1600

Wavelength (nm)
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α Lβ Cα Cβ Sα Sβ
THz nm THz nm THz nm THz nm THz nm THz nm

186.00 1611.79 186.05 1611.35 191.00 1569.59 191.05 1569.18 196.00 1529.55 196.05 1529.16
186.10 1610.92 186.15 1610.49 191.10 1568.77 191.15 1568.36 196.10 1528.77 196.15 1528.38
186.20 1610.06 186.25 1609.62 191.20 1567.95 191.25 1567.54 196.20 1527.99 196.25 1527.60
186.30 1609.19 186.35 1608.76 191.30 1567.13 191.35 1566.70 196.30 1527.22 196.35 1526.83
186.40 1608.33 186.45 1607.90 191.40 1566.31 191.45 1565.90 196.40 1526.44 196.45 1526.05
186.50 1607.47 186.55 1607.04 191.50 1565.50 191.55 1565.09 196.50 1525.66 196.55 1525.27
186.60 1606.60 186.65 1606.17 191.60 1564.68 191.65 1564.27 196.60 1524.89 196.65 1524.50
186.70 1605.74 186.75 1605.31 191.70 1563.86 191.75 1563.45 196.70 1524.11 196.75 1523.72
186.80 1604.88 186.85 1604.46 191.80 1563.05 191.85 1562.64 196.80 1523.34 196.85 1522.95
190.50 1573.71 190.55 1573.30 195.50 1533.47 195.55 1533.07 200.50 1495.22 200.55 1494.85
190.60 1572.89 190.65 1572.48 195.30 1532.68 195.65 1532.29 200.60 1494.48 200.65 1494.11
190.70 1572.06 190.75 1571.65 195.70 1531.90 195.75 1531.51 200.70 1493.73 200.75 1493.36
190.80 1571.24 190.85 1570.83 195.80 1531.12 195.85 1530.72 200.80 1492.99 200.85 1492.62
190.90 1570.42 190.95 1570.01 195.90 1530.33 195.95 1529.94 200.90 1492.25 200.95 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 SDH (ITU)
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
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 155
140
subscriber
34
34
2
140
155
34
34
2
34
2
34
Break
140
155
34
BBX
2
155
140 WBX
34 34
2 622-Mbit/s synchronous
2 add/drop multiplexer (ADM)
155-Mbit/s synchronous
Receiving
add/drop multiplexer (ADM)
subscriber
2.5-Gbit/s synchronous FOTS
155 Mbit/s
622 Mbit/s 622-Mbit/s synchronous FOTS
622
622
622
2488 Mbit/s 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
ADM ADM
T1 (terminal mode) (terminal mode) T1
T3 T3
Dial Single Mode Fiber
• Bus
— Add Drop Multiplexers can add in and drop off SPEs as required
ADM ADM
T1 (terminal mode) (terminal mode) T1
T3 ADM T3
T1
T3
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
Working Alarm !
backup
No data
Data
Break
Data
Normal Operation Fiber Break Causes Alarm
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 (frequency-
modulation) 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
1 BBC One Includes regional variations 1
2 BBC Two Includes regional variations; digital variations from analogue in Wales and Northern Ireland 1
ITV1 In England, Wales, Southern Scotland, the Isle of Man and the Channel Islands2
3 STV In Central and Northern Scotland2 2
UTV In Northern Ireland2
Channel 4 Except Wales 2
4
S4C Digidol Wales only A3
5 Five A3
6 ITV2 2
7 BBC Three Broadcasts 1900-0600 1
Channel 4 Wales only 2
8
TeleG Scotland only; broadcasts 1800-1900 A
9 BBC Four Broadcasts 1900-0600 B
10 ITV3 2
11 Sky Three C
12 UKTV History Broadcasts 0500-0100 C
13 More4 2
14 E4 2
15 ABC1 Not available in Wales; broadcasts 0600-1800 A
16 QVC Reduced hours in Wales (not broadcast 0900-1700 Tuesday-Thursday) A
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 Top Up TV; broadcasts 1600-0100 A
18 The Hits D
19 UKTV Bright Ideas Broadcasts 0600-1800 D
20 Ftn Broadcasts 1800-0600 D
21 TMF D
22 Ideal World D
23 bid tv Reduced hours in Wales (only broadcasts 0600-1900) A
24 price-drop tv A
25 TCM Top Up TV; broadcasts 1900-0055 A
26 UKTV Style Top Up TV; broadcasts 1300-1600 A
27 Discovery Channel Top Up TV; broadcasts 1800-2300 A
28 ITV4 Broadcasts 1800-0600 2
29 Film4 D
30 E4+1 C
31 ITV Play D
32 Film4+1 2
33 British Eurosport Top Up TV; broadcasts 1300-1800 A
34 Setanta Sports 1 Pay-per-view service (from Top Up TV); broadcasts dependent on SPL match times 2
35 Five US A
36 Five Life Broadcasts 0500-2300 A
37 SmileTV Broadcasts 0100-0500 C

Notes:
38 Top Up TV Anytime 1 Subscription service; not yet launched A
42 Discovery Real Time Top Up TV; broadcasts 0600-1200 A
43 Top Up TV Promo Not yet launched A
70 CBBC Channel Broadcasts 0600-1900 1
71 CBeebies Broadcasts 0600-1900 B
72 Cartoon Network Top Up TV; broadcasts 0900-1100 A
75 CITV Channel Broadcasts 0600-1800; not broadcast while Setanta Sports 1 is on air 2
80 BBC News 24 1
81 BBC Parliament B
82 Sky News C
83 Sky Sports News C

86 S4C2 Wales only; broadcasts 0900-1700 Tuesday-Thursday A3
87 Community Channel Broadcasts 0600-0900 B
88 Teachers' TV Broadcasts 1100-1300 A
97 Television X Top Up TV (additional subscription); broadcasts 2300-0500 A
98 Red Hot TV Pay-per-view service; placeholder (no longer broadcasting) A
501 BBC HD Trial BBC High Definition Test Channel; London only CH31
503 ITV HD Trial ITV High Definition Test Channel; London only CH27
504 Channel 4 HD Trial C4 High Definition Test Channel; London only CH27
505 Five HD Trial Five High Definition Test Channel; London only CH27

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: 5–8 km
• MMDS – Multichannel MDS
— Multiple simplex or duplex channels to a local hub
— Generally employed in 2.4, 5 GHz bands
— CATV distribution over MMDS
— Typical range: 55 km
• Wimax: IEEE 802.16 is addressing physical/MAC layer, and frequency
coexistence standards
In the USA and Canada wireless local loop technologies have been used for some
time.
Notes:
Example MMDS System
Tree top
Omni transmit
House top
antenna Receive Antenna
(may be omni or
LNB directional)
Satellite
Receivers Decoded
Receiver
HPA
Decoder
Modulation & Frequency

Encryption Translation
HPA = High Power Amplifier

LNB = Low Noise Block Convector
Notes:
Typical Wireless Loop Installation
e
av
ow
icr RST
M
System Cell
controller RST
site
RST
Fiber
Fax machine
Local Concentrator System Cell
exchange controller site
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
• IEEE founded the 802 committee to standardize LANs in 1980
802.10 Security
802.2 Logical Link Control

802.1 Management
Data
802.1d Bridging
Link
Layer
802.3 802.4 802.5 802.6 802.16 802.20
802.11
WiMAX
CSMA/CD Token Token DQDB Wireless Wireless
Wireless
Bus Bus Ring MAN LAN Broadband Physical
Access
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 Combination
Free to air Digital 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
– TISPAN’s specific needs to accommodate Wireline access to IMS are
covered by a collaboration between TISPAN and 3GPP: TISPAN-specific
IMS extensions are prepared in TISPAN and proposed for inclusion to
3GPP IMS Rel-7. Joint meetings between TISPAN and 3GPP.
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
IMS HSS
Fixed-access impacts
on 3GPP’s IMS
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 3.5 - 4.5 Mbps
– High Definition 12 -19.3 Mbps
— IPTV with MPEG4 compression
– Standard Definition 1.5 - 2.0Mbps
– High Definition 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 freeze-
dried 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, JPEG, blotchy spots in single-color

areas
optimal encoding
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 JPEG compression

file size: 1861 bytes file size: 1895 bytes
compression ratio - 105.6 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 Daubechies wavelet basis functions, time-

tiles, and coverage of the time- frequency tiles, and coverage of the time-
frequency plane. frequency 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 DSM-
CC (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
SNR Spatial
Simple Main High
scalable scalable
High level X X
High-1440
level X X X
Main level X X X X X X
Low level 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 MPEG-

1 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 DSM-
CC network. DSM-CC defines a logical entity called the Session and Resource
Manager (SRM) which provides a (logically) centralized management of the DSM-
CC 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

4.5 kHz mono 16 kbps 48:1
wave
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.
CC Sessions and Resources.
Notes:
Part 9 of MPEG2
• Part 9 defines the Transport Stream for MPEG2
CC 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 188-
bytes 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 P-
picture plus motion compensation
• B-Pictures - Bidirectional pictures - these can use a previous or future I-
picture 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 3-
15 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
Value of non-
Length of Variable-length
zero
run of zeros Code-word
coefficient
0 12 0000 0000 1101 00
0 6 0010 0001 0
1 4 0000 0011 000
0 3 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
Levels 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
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 60, 40, 15 80, 60, 20 100, 40, 60
Enhancement 720 X 576/30 720 X 576/30 720 X 576/30
Main Lower 352 X 288/30 720 X 576/30

Bitrate 15, 10 20, 15, 4 25, 10, 15
Enhancement 352 X 288/30 352 X 288/30
Low Lower 352 X 288/30

Bitrate 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)
Pro-MPEG takes consecutive

Normal MPEG-2 Transport streams pack
packets and adds FEC
several video frames in an Ethernet Transfer
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 object’s or scene description’s time base, and it enables
synchronization among them. The syntax of this layer is configurable in a large number of ways, allowing use in a broad
spectrum of systems.
The synchronized delivery of streaming information from source to destination, exploiting different QoS as available from the
network, is specified in terms of the synchronization layer and a delivery layer containing a two-layer multiplexer.
The first multiplexing layer is managed according to the DMIF specification, part 6 of the MPEG?4 standard. (DMIF stands
for Delivery Multimedia Integration Framework) This multiplex may be embodied by the MPEG-defined FlexMux tool,
which allows grouping of Elementary Streams (ESs) with a low multiplexing overhead. Multiplexing at this layer may be
used, for example, to group ES with similar QoS requirements, reduce the number of network connections or the end to end
delay.
The “TransMux” (Transport Multiplexing) layer models the layer that offers transport services matching the requested QoS.
Only the interface to this layer is specified by MPEG-4 while the concrete mapping of the data packets and control signaling
must be done in collaboration with the bodies that have jurisdiction over the respective transport protocol. Any suitable
existing transport protocol stack such as (RTP)/UDP/IP, (AAL5)/ATM, or MPEG-2’s Transport Stream over a suitable link
layer may become a specific TransMux instance. The choice is left to the end user/service provider, and allows MPEG-4 to be
used in a wide variety of operation environments.
Notes:
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, non-
speech parts are detected in unvoiced signals, and a smaller number of bits is used for these non-
speech parts to reduce the average bit rate. ER HVXC provides communications-quality to near-toll-
quality 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 IP-
based 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. JVT’s main task is to develop the draft H.26L
“model” into a full International Standard. In fact, the outcome will be two
identical) standards: ISO MPEG4 Part 10 of MPEG4 and ITU-T H.264. The
“official” title of the new standard is Advanced Video Coding (AVC); however, it
is widely known by its old working title, H.26L and by its ITU document number,
H.264.
Notes:
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
1st
MPEG-2 Encoder
6 MPEG-2
Standard
Frozen 2nd Generation
(H.262) Encoder
5
3rd Generation
Encoder
4
MPEG-2
4th Generation
Mbit/s
Encoder
3
5th Generation
Encoder
0
1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005
Notes:
MPEG-4 in Comparison
1st
MPEG-2 Encoder
6
2nd Generation
Encoder
5
3rd Generation
Encoder
4 MPEG-2
MPEG-4
Mbit/s
4th Generation H.263

Encoder
3
5th Generation
Encoder
0
1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005
Notes:
H.26L Provides Focus
1st
MPEG-2 Encoder
6
2nd Generation
Encoder
5
3rd Generation
Encoder MPEG-2
4 MPEG-4
H.26L
4th Generation
Mbit/s
H.263
Encoder
3 5th Generation
Encoder
0
1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005
Notes:
MPEG-4 “Adopts” H.26L
1st
MPEG-2 Encoder
6
2nd Generation
Encoder
5
3rd Generation
Encoder MPEG-2
4 MPEG-4
H.26L
4th Generation
Mbit/s
Encoder H.263
3 th
5 Generation
Encoder
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 Total bit Grading scale Subjective

rate quality
AAC 5 320 kb/s impairment 4.6
1995 Backward Compatible 5 640 kb/s impairment 4.6
MPEG-2 Layer II
MPEG-1 Layer II 2 192 kb/s impairment 4.3
MPEG-1 Layer III 2 128 kb/s impairment 4.1
AAC 1 24 kb/s quality 4.2
Scalable: CELP base and 1 6 kb/s base, quality 3.7
AAC enhancement 18 kb/s enh.
Scalable: Twin VQ base and 1 6 kb/s base, quality 3.6
AAC enhancement 18 kb/s enh.
AAC 1 18 kb/s quality 3.2
G.723 1 6.3 kb/s quality 2.8
Notes:
MPEG-4 Audio Tools
Coding tool Channels Total bit Grading scale Subjective

rate quality
Wideband CELP 1 18.2 kb/s quality 2.3
BSAC 2 96 kb/s quality 4.4
AAC ・Low Delay 1 64 kb/s quality 4.4
G.722 1 64 kb/s quality 4.2
AAC ・Low Delay 1 32 kb/s quality 3.4
Narrowband CELP 1 6 kb/s quality 2.5
Twin VQ 1 6 kb/s quality 1.8
HILN 1 16 kb/s quality 2.8
HILN 1 6 kb/s quality 1.8
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
Pre-Processing Encoding
Destination
Post-Processing Decoding
& Error Recovery
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 Encoder System GUI
Sources
Video Sensors, DGFX PVA
DGFX PVA AVC
SMPTE Streams, Frequency VLSI Chip or
Hi Quality Encoder
Networked Video, Shaping &
Video Servers Noise
Chroma
W/Exact
Chips
Processing
Reduction Match
10 (& 12) Bit

Logical System Interconnect (HW or SW) Enabled
CODEC V
System
Platform
Bitstream
NAL: MPEG-2 or Other Xport Output
& CPU MD
AVC’s 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
Foreman QCIF 10Hz

39
38
37
36
35 JVT/H.264/AVC
34 MPEG-4
Quality 33 MPEG-2
Y-PSNR [dB] 32 H.263
31
30
29
28
27
0 50 100 150 200 250

Bit-rate [kbit/s]
Notes:
Comparison to MPEG-2, H.263, MPEG-4
CIF 30Hz
38
37
36
35
Peek Signal
to Noise Ratio 34
33
Quality 32
Y-PSNR [dB] 31
30
29 JVT/H.264/AVC
28 MPEG-4
27
MPEG-2
26
H.263
25
0 500 1000 1500 2000 2500 3000 3500

Bit-rate [kbit/s]
Notes:
CODEC Comparison
(Normalized speed In Mbps)
Sequence Attributes MPEG-2 AVC-1 AVC-2
1-College Fast motion, 26.7 7.3 4.6

Football high detail
2-Panasonic Skin tones, 10.1 4.2 2.2
Girls water
3-Preakness Random 70.0 30.8 23.3
motion
4-Philips Motion, high 2.9 0.9
Liquids detail
5-Oscars ’02 Slow motion, 9.5 2.5 1.2
high detail
6-Test Signals High detail, 1.4 0.8 0.1
measurable
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 base-
band digital sequence of complex symbols. There are 5 allowed modulation modes: 16-QAM, 32-
QAM, 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 DVB-
H demodulator and a DVB-H terminal. The DVB-H demodulator includes a DVB-
T 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

• Experience
Notes:
Attendee Introductions
• Your name
• Organization name
• 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. (Shannon’s Law, Erlang
Tables) Lans and Wans are optimized for throughput (RSVP, Tag Switching).
Voice to Data ratios on telcos are tipping in favor of Data. Doesn’t it make sense to
put voice on the data network rather than the other way around? Isn’t this just
another way of saying that all networks are migrating (or will migrate) to data as
the voice/data ratio becomes distorted in favor of data?
Notes:
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:
Internet Engineering Task Force (IETF)
• Produces standards upon which Internet is based

• Called Requests For Comment (RFC)
— Most RFCs are proposals for standards
— Only small proportion finally accepted
• Available free via the Internet
— Information available from Internet Assigned Numbers Authority
– http://www.iana.org/
— Downloadable from http://www.ietf.org/rfc.html
— List of current standards in STD 1
— http://rfc.net/std1.html
— Currently RFC3600
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
5. Session Application Application
4. Transport Transport Transport TCP/IP
3. Network
Internet Internet
2. Data Link Network interface Network interface
1. Physical Hardware Hardware
• 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
• P rovide s a pplica tion

7 s e rvice s
Application
• P rovide s da ta
6 re pre s e nta tion
Presentation
• P rovide s che ckpointing,
5 a ctivity ma na ge me nt
Session
• P rovide s e nd-to-e nd
4 da ta inte grity
Transport
3 • Route s a nd re la ys
Network
2 • Ma na ge s communica tion
Data Link be twe e n a dja ce nt node s
1 • Tra ns mits bit s tre a m

Physical 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

7 s e rvice s
Application
Presentation
Session
4 da ta inte grity
Transport
Network
Data Link be twe e n a dja ce nt node s

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

7 s e rvice s
Application
Presentation
Session
4 da ta inte grity
Transport
Network
Detects Errors Data Link be twe e n a dja ce nt node s

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

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

running a layer 2 detecting errors. However to deliver the data to the correct
destination I need Routing which is the job of layer 3.
Notes:
OSI Model

7 s e rvice s
Application
Presentation
Session
4 da ta inte grity
Transport
Routing Network

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

7 s e rvice s
Application
Presentation
Session
End to End Error 4 da ta inte grity
Recovery
Transport
Routing Network

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

7 s e rvice s
Application
Presentation
Checkpoints and 5 a ctivity ma na ge me nt
Activities Session
Recovery
Transport
Routing Network

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

7 s e rvice s
Application
Converts bits to Objects Presentation
Activities Session
Recovery
Transport
Routing Network

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

Application and its 7
Application s e rvice s
Services
Activities Session
Recovery
Transport
Routing Network

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
5. Session Application Application
4. Transport Transport Transport TCP/IP
3. Network
Internet Internet
2. Data Link Network interface Network interface
1. Physical Hardware Hardware
• 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 Host
— Routing, path through the network
— Packet size and format
— Access technology
— Shared protocols
– Errors, flow, timing
• 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 TCP/IP
Internet Internet
LAN or WAN link
Network interface Network interface
Hardware 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.5–2.0 Mbit/s, 4.5 km
symmetric of 2- or 3-pair UTP
— SDSL (single-line DSL)
SDSL 1.5–2.0 Mbit/s, 3 km of
— ADSL (asymmetric DSL) symmetric 1-pair UTP
– High bit rate downstream ADSL 1.5–9 Mbit/s down, 2.5–5 km of 1-pair
16–640 kbit/s up UTP
– Low upstream
VDSL 13–52 Mbit/s down, 0.3–1.5 km of
— VDSL (very high-data-rate DSL) 1.5–2.3 Mbit/s up 1-pair UTP
Public network
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
— That’s all that’s 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 RIP Etc. Application
TCP UDP Transport
IP ICMP 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 E-mail
Me 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
0 4 bytes 31
Ver IHL TOS Length

M D
Datagram ID 0 F F Fragoff
TTL Prot 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 fragment—Don’t Fragment (DF bit)
— Fragoff: Fragment offset
– Measured in units of 8 octets
— Prot: Next protocol
– 6=TCP, 17=UDP
• Total overhead is at least 20 bytes for the IP packet header
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 ISO-
IP 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 Different Network
Interfaces
Network Network Network

Type 1 Type 2 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 32-bit IP address Internetwork
mapping 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
Network MTU (bytes) Max frame size

Ethernet 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 oriented—virtual circuit
— When connection is established, data transfer starts
– Protocols verify correct reception
– Buffered traffic flow
– Full-duplex connection
• Accounts for more than 90 percent of Internet traffic
• “Reliability” is achieved through retransmission
— When packets are lost or errors occur, retransmission provides “reliability”
– Suitable for data traffic and signaling for voice: Ensures correct
information
– Not suitable for voice traffic: Voice information must be continuous
– By the time data is retransmitted, it is too late!
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 4 10 16 24 31
Source port Destination port
Sequence number
Acknowledgment number
HLEN Reserved Code bits Window
Checksum Urgent pointer
Options (if any) Padding
Data
Options (normally absent)
• Port is a destination for the message

• Local host process can communicate with the port
• A pair of IP addresses and port numbers for a connection forms a socket
— Complete specification for an association—a conversation
• Adds at least 20 bytes overhead per packet
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 ports—less than 1024
— HTTP 80 SMTP 25
— FTP 21, 20 DNS 53
— Telnet 23 NNTP 119
• Ports used by VoIP are generally client ports—greater than 1024
— End-to-end VoIP call setup uses destination port 1720
– UDP ports dynamically assigned and both ends > 1024
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 Transport Protocol (RTP)
— Real-Time Control Protocol (RTCP)
• RTP provides
— Timestamping, sequence number
– For playback timing and synchronization
— Setting up real-time applications
– Audio and video
• RTCP provides
— Reporting on achieved results
— Delay, packet loss statistics
• Defined in RFC 1889 originally
— Copied by H.323 systems
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
You’re 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 Protocol—Adds minimum of 12 bytes

— V: Version—RFC 1889 currently 2
— P: Padding— =1 if packet contains padding
— X: Extension bit—if 1, then there is an extension header
— CC: CSRC count—the number of CSRC identifiers following
— M: Marker—profile may use this bit to define frame boundaries
— PT: Payload type—defines the type of encoding
• Sequence number increments by 1 for each RTP data packet
V=2 P X CC M PT Sequence number
Timestamp
Synchronization source (SSRC) identifier
Contributing source (CSRC) identifiers
CSRC = contributing source reference code

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
– 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
encoding audio/video clock rate channels

PT name (A/V) (Hz) (audio)
0 PCMU A 8000 1
1 1016 A 8000 1
2 G721 A 8000 1
3 GSM A 8000 1
5 DVI4 A 8000 1
6 DVI4 A 16000 1
7 LPC A 8000 1
8 PCMA A 8000 1
9 G722 A 8000 1
10 L16 A 44100 2
11 L16 A 44100 1
14 MPA A 90000
15 G728 A 8000 1
25 CelB V 90000
26 JPEG V 90000
28 nv V 90000
31 H261 V 90000
32 MPV V 90000
33 MP2T AV 90000
34--71 unassigned ?
72--76 reserved N/A N/A
77--95 unassigned ?
96--127 dynamic ?
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
• Institute of Electrical and Electronic Engineers produces LAN standards

— Available from http://standards.ieee.org/getieee802/
Type 1
802.2 Logical Link Control
Type 2
802.1 overall
standards
802.5
802.3 802.4 802.6 Others
Token •••
Ethernet Token Bus MAN
Ring
10BASE5 1 Mbps 4 Mbps DQDB

155 Mbps
10BASE2 5 Mbps 16 Mbps
10BASE-T 10 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 . . . Payload data CRC
address
0 = IEEE Admin Assigned Assigned

1 = Local admin to the vendor by the vendor
(3 bytes) (3 bytes)
0 = Individual
1 = Group
Address is sent low order bits first in each byte

E.g., Locally admin, group address 1100 0000 - - -
Ethernet Hex Address 0 3
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
Min 64
Max 1,518
bytes Frame check
Preamble Start sequence
(7 bytes) delimiter (6 bytes) (6 bytes) (2 bytes) (4 bytes)
Destination Source Type or “Data” Pad FCS
1010...1010 10101011
address address length
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 – Or, the letter “T” after

10 Mbps 500 M before “BASE” standing for
Baseband needing a repeater “twisted pair” the
Media Type
Abbreviation Meaning
T 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
Host
Host Stand-by
bridge
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 Recommended or Permitted Compatibility

Default value Range Range
Migrate Time 3.0 — —
Bridge Hello Time 2.0 — 1.0–2.0
Bridge Max Age 20.0 6.0–40.0 6.0–40.0
Bridge Forward Delay 15.0 4.0–30.0 4.0–30.0
Transmit Hold Count 6 1–10 1–10
• Bridge and Port Identifier Priority values

Parameter Recommended Range
or default value
Bridge Priority 32 768 0–61 440 in steps of 4096
Port Priority 128 0–240 in steps of 16
Notes:
Port Path Cost values
Link Speed Recommended Recommended Range

value range
<=100 Kb/s 200 000 000 20 000 000–200 000 000 1–200 000 000
1 Mb/s 20 000 000 2 000 000–200 000 000 1–200 000 000
10 Mb/s 2 000 000 200 000–20 000 000 1–200 000 000
100 Mb/s 200 000 20 000–2 000 000 1–200 000 000
1 Gb/s 20 000 2 000–200 000 1–200 000 000
10 Gb/s 2 000 200–20 000 1–200 000 000
100 Gb/s 200 20–2 000 1–200 000 000
1 Tb/s 20 2–200 1–200 000 000
10 Tb/s 2 1–20 1–200 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
Path to root Discarding Interface
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 Actor’s System ID, encoded as a MAC address.
j) Actor_Key. The operational Key value assigned to the port by the Actor, encoded as an unsigned integer.
k) Actor_Port_Priority. The priority assigned to this port by the Actor (the System sending the PDU;
assigned by management or administration policy), encoded as an unsigned integer.
l) Actor_Port. The port number assigned to the port by the Actor (the System sending the PDU), encoded as an unsigned
integer.
m) Actor_State. The Actor’s state variables for the port, encoded as individual bits within a single octet.
Notes:
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 Actor’s Receive machine is using
Defaulted operational Partner information, administratively con.gured for the Partner. If FALSE (encoded as a 0), the
operational Partner information in use has
been received in a LACPDU;
8) Expired is encoded in bit 7. If TRUE (encoded as a 1), this .ag indicates that the Actor’s Receive machine is in the
EXPIRED state; if ALSE (encoded as a 0), this .ag indicates that the Actor’s Receive machine is not in the EXPIRED state.
Notes:
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 Partner’s System ID, encoded as a MAC address.
s) Partner_Key. The operational Key value assigned to the port associated with this link by the Partner, encoded as an unsigned
integer.
t) Partner_Port_Priority. The priority assigned to this port by the Partner (by management or administration policy), encoded
as an unsigned integer.
u) Partner_Port. The port number associated with this link assigned to the port by the Partner, encoded as an unsigned integer.
v) Partner_State. The Actor’s view of the Partner’s state variables, depicted in Figure 43–8 and encoded as individual bits
within a single octet, as de.ned for Actor_State.
w) Reserved. These 3 octets are reserved for use in future extensions to the protocol. They shall be ignored on receipt and shall
be transmitted as zeroes to claim compliance with Version 1 of this protocol.
x) TLV_type = Collector Information. This .eld indicates the nature of the information carried in this TLV-tuple. Collector
information is identi.ed by the integer value 0x03.
CSMA/CD IEEE Std 802.3-2002®, Section Three
y) Collector_Information_Length. This .eld indicates the length (in octets) of this TLV-tuple. Collector information uses a
length value of 16 (0x10).
z) CollectorMaxDelay. This .eld contains the value of CollectorMaxDelay (43.2.3.1.1) of the station transmitting the
LACPDU, encoded as an unsigned integer number of tens of microseconds. The range of values for this parameter is 0 to 65
535 tens of microseconds (0.65535 seconds).
Notes:
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 802-
1990.
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 4
1 4
1 4
A 2 5B
2 5
2 5
2 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
— Network—where to deliver the packet (usually a LAN)
— Host—which machine at that location
• The division of IP addresses is undertaken by a network mask
192 . 168 . 1 .10

Network Host
Mask 255.255.255 .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.0.254 192.168.4.2
LAN A
192.168.4.1 LAN B
192.168.1.254
• 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
• Networks and subnetworks are joined by routers Mask = 255.255.255.0
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
– Static—by 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 addressing—before, 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)
N H H H
A 0xxxxxxxx
1–126
N N H H
B 10xxxxxxx
128–191
N N N H
C 110xxxxxx
192–223
• Special addresses • Private networks (RFC 1918)

— Local host: 127.0.0.1 — 10.X.X.X Class A
— Broadcast: — 172.16-30.X.X Class B
– Local 255.255.255.255 — 192.168.0-255.X Class C
– Directed; e.g., 192.168.1.255
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:
Internet Protocol (IP)
• Role of IP is to communicate between hosts

— Routable protocol
– Define both network and host address
– Other routable protocols
– Novell IPX, Banyan VINES, AppleTalk, OSI IP
• Unreliable, best-effort, connectionless delivery
— Delivery of packet is not guaranteed
— Reliability is the responsibility of the application
• Reliability is the responsibility of the upper-layer protocols
— May be TCP
— May be the application
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 B’s link address?
• Address Resolution Protocol (ARP) provides the answer
Machine A Machine B
IP Address: 192.168.10.1 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 Machine B
IP Address: 192.168.10.1 IP Address: 192.168.10.2
Broadcast ARP Request
Broadcast Source A 806 ARP Request
Dest A 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 Type
192.168.7.1 00-a0-cc-7b-18-66 dynamic
192.168.7.11 00-20-18-71-f0-ea dynamic
192.168.7.32 00-40-05-d0-85-6d dynamic
192.168.7.191 00-03-47-0c-ae-40 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 /30 2 valid hosts
— 255.255.255.248 /29 6 valid hosts
— 255.255.255.240 /28 14 valid hosts
— 255.255.255.224 /27 30 valid hosts
— 255.255.255.192 /26 62 valid hosts
— 255.255.255.128 /25 126 valid hosts
— 255.255.255.0 /24 254 valid hosts
— 255.255.254.0 /23 510 valid hosts
— 255.255.252.0 /22 1022 valid hosts
— 255.255.248.0 /21 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
Rest of the Internet 139.21.1.0

All Traffic to
139.21.0.0
?
Notes:
SMIS Inc Network
• SMIS Inc has 6 sites each with a router and a LAN
1 2 3
4 5 6
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
D
• Each site has one LAN
B C
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 A 1
B 0 B 1
B C
C 1 C 0
D 1
A 0
B 1
A
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:
C
• Exchange tables with
A 1
— Immediate neighbors D
B 1
C 1 0
D 0 1
A C A B D
A 1 0 1 A 1 0 1
B 0 1 1 B 1 1 0
B C
C 1 1 0 C 0 1 1 1
D 1 D 1 0
B C
A 0 1 1
B 1 0 1
A
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
• Update Tables
A 2 1
D
B 2 1
C 1 0
D 0 1
A C A B D
A 1 0 1 A 1 0 1 2
B 0 1 1 B 1 1 0 2
B C
C 1 1 0 C 0 1 1 1
D 2 2 1 D 1 2 2 0
B C
A 0 1 1
B 1 0 1
A
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:
C
• Failed link
A 2 1
— Remove information D
B 2 1
— Update links C 1 0
D 0 1
A C A B D
A 1 0 1 A 1 0 1 2
B 0 1 1 B 1 1 0 2
B C
C 1 1 0 C 0 1 1 1
D 2 2 1 D 1 2 2 0
B C
A 0 1 1
B 1 0 1
A
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:
C
• Updated Information
A 3 2
— Routes around failure D
B 2 1
C 1 0
D 0 1
A C B D
A 1 0 1 A 2 1 3
B 0 1 1 B 1 0 2
B C
C 1 2 0 C 0 1 1
D 2 3 1 D 1 2 0
B
A 0 1
B 1 0
A
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:
C
• Further Failure
A 3 2
— Parts of Network Isolated D
B 2 1
— Further information C 1 0
D 0 1
A C B D
A 1 0 1 A 2 1 3
B 0 1 1 B 1 0 2
B C
C 1 2 0 C 0 1 1
D 2 3 1 D 1 2 0
B
A 0 1
B 1 0
A
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
• Tables Updated
A 3 4
D
B 2 3
C 1 0
D 0 1
A D
A 1 0 A 4 3
B 0 1 B 3 2
B C
C 3 2 C 0 1
D 4 3 D 1 0
B
A 0 1
B 1 0
A
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:
C
• Tables Updated again
A 5 4
— Hop counts too large D
B 4 3
— Only 4 hops in network C 1 0
— Nodes unreachable D 0 1
A D
A 1 0 A 6 5
B 0 1 B 5 4
B C
C 5 4 C 0 1
D 6 5 D 1 0
B
A 0 1
B 1 0
A
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 D C
C 1 0
D 0 1
A
A 1 0
B 0 1 D
B C
C 0 1
D 1 0
B
A 0 1
B 1 0
A
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 R4
Net 2 Net 2
R1 R4
Net 1 Net 5 Net 3 Net 5

Net 1 Net 3
Net 4
R2 Net 4 R2 R3
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.
Net 2
R1 R4
My links to Net 2 and
Net 3 are up!
Net 5
Net 1 Net 3
CRASH My links to Net 3 and
Net 4 are up! Sorry,
my link to Net 5 is
Net 4 down.
R2 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 host’s routing table?
– Is there a default router?
— Host-specific routes are checked first
• Second level of routing hierarchy: routers within an AS
— Routers communicate within AS with generic Interior Gateway Protocols
— Normally this is OSPF or in small networks RIP/EIGRP
• Third level of routing hierarchy: AS to AS
— Routers communicate between ASs with generic Exterior Gateway
Protocols
— In reality this is BGP4 today
Routing takes place at several levels. At the PC we route data to and from the
interface of the PC and out to the nearest router. Once we reach the first ISP the
ISP’s routers will follow routes that are advertised by other ISPs that it has a
business arrangement with.
For commercial reasons, routers within the internet will not follow necessarily the
“shortest” route in all cases. In some cases economics may result in a longer and
slower router being used.
Notes:
Example AS
• Details of Autonomous System numbers is held at www.ripe.net

• Example
• aut-num: AS12576
• as-name: ORANGE-PCS
• descr: Orange PCS Limited
• import: from AS702 action pref=100; accept ANY
• import: from AS2856 action pref=100; accept ANY
• export: to AS702 announce AS12576
• export: to AS2856 announce AS12576
• admin-c: ORA1-RIPE
• tech-c: ORA1-RIPE
• mnt-by: AS12576-MNT
• changed: hostmaster@ripe.net 19990730
• changed: jamieb@uk.uu.net 20020905
• changed: philip.bridge@orange.co.uk 20020905
• changed: philip.bridge@orange.co.uk 20040624
• source: 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 213
1982 235
1983 562
1984 1,024
1985 1,961
1986 5,089
1987 28,174
1988 33,000
1989 159,000
1990 313,000
1991 617,000
1992 1,136,000
1993 2,056,000
1994 3,864,000
1995 6,642,000
1996 16,729,000
1997 26,053,000
1998 36.739,000
1999 56,218,000
2000 93,047,785
2001 125,888,197
2002 162,128,493
2003 171,638,297
2004 285,139,107
2005 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
Not this way

My ISP 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
• In this chapter we have

• Studied the operation of distributed dynamic routing
• Reviewed the major routing protocols
• Examined how distance vector link state and policy based routing
functions
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

Range
Assignments Description
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
Dynamic Host Configuration Protocol (DHCP)
224.0.0.12
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 addresses—their own unicast,
broadcast, and a range of multicast addresses.The IEEE LAN specifications made
provisions for the transmission of broadcast and multicast packets. In the 802.3
standard, bit 0 of the first octet is used to indicate a broadcast or multicast frame.
The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in
hexadecimal format. Half of this block is allocated for multicast addresses. The
range from 0100.5e00.0000 through 0100.5e7f.ffff is the available range of
Ethernet MAC addresses for IP multicast.This allocation allows for 23 bits in the
Ethernet address to correspond to the IP multicast group address. The mapping
places the lower 23 bits of the IP multicast group address into these available 23
bits in the Ethernet address
Notes:
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
environment—Cisco Group Management Protocol (CGMP), IGMP Snooping, and
Router-Port Group Management Protocol (RGMP). CGMP and IGMP Snooping are
used on subnets that include end users or receiver clients. RGMP is used on routed
segments that contain only routers, such as in a collapsed backbone.
Notes:
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 boundaries—the hosts can be located
anywhere on the Internet or any private internetwork. Hosts that are interested in
receiving data flowing to a particular group must join the group using IGMP .
Notes:
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
• 0x12 Version 1 Membership Report [RFC-1112]
these for compatability
• 0x16 Version 2 Membership Report [RFC-2236] with versions 1 and 2
• 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 mode—the receiver announces membership to a host group
– It provides a list of source addresses known as the INCLUDE list
— EXCLUDE mode—the receiver announces membership to a multicast
group
– It provides a list of source addresses known as the EXCLUDE list
– These are addresses from which it does not want to receive traffic
– To receive traffic from all sources an empty EXCLUDE list is used
– This is the behavior of IGMPv2
IGMPv3 supports applications that explicitly signal sources from which they want
to receive traffic. With IGMPv3, receivers signal membership to a multicast host
group in the following two modes:
INCLUDE mode—In this mode, the receiver announces membership to a host
group and provides a list of source addresses (the INCLUDE list) from which it
wants to receive traffic.
EXCLUDE mode—In this mode, the receiver announces membership to a multicast
group and provides a list of source addresses (the EXCLUDE list) from which it
does not want to receive traffic. The host will receive traffic only from sources
whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all
sources, which is the behavior of IGMPv2, a host uses EXCLUDE mode
membership with an empty EXCLUDE list.
The current specification for IGMPv3 can be found in the Internet Engineering
Task Force (IETF) draft titled Internet Group Management Protocol, Version 3 on
the IETF website.
Notes:
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, 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.
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)
Query received
Delaying- (start timer) Idle-Member
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 OSPF’slink 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 it’s TTL is checked against the TTL Threshold. If the
packet’s TTL is < the specified threshold, it is not forwarded out the
interface.
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
S1 S2 S3
R1 R2 R3 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 directory’s announcement annually of profits, a
televised broadcast of the first person to step on the moon – or next time Mars. If
streams are not being viewed dense mode can waste a great deal of capacity and
slow down normal operation.
Notes:
Sparse Mode
S1 S2 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 source’s 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 first-
hop 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 PIM-
SM 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-list-
number
• 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-to-
RP 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-list-
number
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
Sender A
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

ip22-R72a#sh ip rpf 1.1.1.1 Interface as e3/3 but
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
Sender A
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 (Ethernet3/1) d=224.2.127.254 len 60, not RPF 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 information for ? (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
Sender Receiver
S R
e0/0 e0/1 e1/1 e1/2
1.1.1.1 1.1.1.2 2.1.1.1 2.1.1.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 information for ? (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
Sender A
e0/0 e0/1
1.1.1.1 1.1.1.2 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 multi-
technology 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
• Provides application
Application and its 7
Application services
Services
• Provides data
6 representation
• Provides checkpointing,
Checkpoints and 5 activity management
Activities Session
• Provides end-to-end
End to End Error 4 data integrity
Recovery
Transport
3 • Routes and relays
Routing Network
2 • Manages communication
Detects Errors Data Link between adjacent nodes
1 • Transmits bit stream

Moves Bits Physical 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
M M M
Application Application Application
Presentation Presentation Presentation
Session Session Session
Transport Transport Transport
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
M M M
Application Application Application
Presentation Presentation Presentation
Session Session Session
Transport Transport Transport
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
RMON
SNMP SNMPv1 MIB-2 MIB SNMPv2 SNMPv3
Recommended SMI
status MIB-1
“standard Fundamental
More than 30 protocols”
CMOT vendors
flaws found
and SNMPv2
demonstrate largely
SNMP products abandoned
at Interop
HEMS SGM P
1986 1987 1989 1990 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. High-
level 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
Management SNMP
Agent
application
Data
UDP/IP 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 OSI Layer

SMTP FTP
Simple TELNET
Application virtual File
Mail SNMP
terminal Transfer
Transfer
Protocol
Protocol 5, 6, 7
End-to-end Transmission Control Protocol (TCP) User Datagram Protocol (UDP) 4
Internetwork ICMP Internet Protocol (IP)

3
ARP
Physical Packet
Etc. radio X.25 IEEE 802 LAN 2,1
network
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 user-
base 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 — don’t we want reliable management?

• . . . Yes of course but
• When do you need network management most?
• . . . and will the network deliver data reliably then?
• If we place SNMP above TCP it cannot see the flaws in the network
— We need to see the network as it is in order to manage it
— TCP would correct errors or crash!
— The network would appear perfect or broken beyond repair
• If we are not managing the network then we can use TCP
— Managing end system components can be done over TCP
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 “Meta-
management” 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
Management
Network- information
management base (MIB)
application
Network-
management
database 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
Paul’s machine
is working fine!
George Paul
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 ccitt 1 iso 2 joint-ccitt-iso
standards 0 1 2 3 org (identified organizations)
1.3.6.1 internet
0 1 2 3 4 5 6 dod
1.3.6.1.1 directory
1.3.6.1.2 mgmt
1 internet
1.3.6.1.3 experimental
1.3.6.1.4 private 1 2 mgmt 3 4 5 8
1.3.6.1.5 security private
1 mib-2
1.3.6.1.6 SNMPv2
1.3.6.1.7 mail Added after RFC 1213
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
1 Internet
1 2 3 4
Directory Management Experimental Private
18 20
PPP RS-232
MIB 1
11 SNMP
10 Transmission 1 Enterprises
1 8 EGP
System 7
2 UDP
6 2 36 9 161 11911
Interfaces 3 5 TCP
IBM DEC Cisco Motorola Motorola
AT 4 ICMP
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 Description Number of MIB variables

— system The managed node 7
— interfaces Network attachments 23
— at IP address translation 3
— ip Internet Protocol 38
— icmp Internet Control Message Protocol 26
— tcp Transmission Control Protocol 19
— udp User Datagram Protocol 7
— egp Exterior Gateway Protocol 18
— transmission Physical interface -
— snmp 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.
1 MIB-2
1 3 5 7 10 14 17 etc.
system at icmp udp transmission ospf bridge . . . etc. . .
2 4 6 8 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 Group Meaning type

sysUpTime system Time since last reboot scalar
ifMtu interfaces MTU size scalar
ifAdminStatus interfaces up/down scalar
ipDefaultTTL ip Default TTL value used scalar
icmpInRedirects icmp ICMP redirects seen scalar
tcpMaxConn tcp Max. connection allowed scalar
udpOutDatagrams udp Datagrams sent
scalar
ipNetToMediaTable ip ARP table table

ipRouteTable ip IP routing table table
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
Managed
SNMP resources SNMP
manager managed
Management SNMP object SNMP managed
objects system
application manipulation
get_response
get_response
get_next
get_next
t rap
t rap
set
set
get
get
SNMP SNMP SNMP

manager messages agent
(PDUs)
UDP UDP
IP IP SNMP
device
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 fetch–store protocol

— get command to fetch a value
— set command to store a value
— Operations accomplished as side effects of these commands
• There are no commands such as reboot
• It is often called a remote debugging paradigm
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
Get / get - next / set

Management
Agent
system
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 Agent Manager Agent

• Get
G et R GetNe
— Get-request eques xtReq
uest P
t PDU DU
— Get-response
U PDU
• Get-next se PD se
espon espon
— Get-next-request GetR GetR
— Get-response
• Set (a) Get values (b) Get-next values

— Set-request
— Get-response
Manager Agent Manager Agent
• Trap S et R
eques DU
— Trap t PDU Trap P
U
se PD
espon
GetR
(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 get-
response 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 Value
— 0 coldStart
— 1 warmStart
— 2 linkDown
— 3 linkUp
— 4 authenticationFailure
— 5 egpNeighborLoss
— 6 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 Type Value
sysContact 0 DisplayString Groucho Marx
Table object example (single index)
Instance 0 ifIndex ifDescr ifType ifMtu ...

Type Value Type Value Type Value Type Value ...
Instance 1 Integer 1 DisplayString Ethernet1 Integer 6 Integer 1500 ...
Instance 2 Integer 2 DisplayString Ethernet2 Integer 6 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 Object identifier Instance identifier
— tcpRtoAlgorithm 1.3.6.1.2.1.6.1 1.3.6.1.2.1.6.1.0

— tcpRtoMin 1.3.6.1.2.1.6.2 1.3.6.1.2.1.6.2.0
— tcpRtoMax 1.3.6.1.2.1.6.3 1.3.6.1.2.1.6.3.0
— tcpMaxConn 1.3.6.1.2.1.6.4 1.3.6.1.2.1.6.4.0
— tcpActiveOpens 1.3.6.1.2.1.6.5 1.3.6.1.2.1.6.5.0
— tcpPassiveOpens 1.3.6.1.2.1.6.6 1.3.6.1.2.1.6.6.0
— tcpAttemptFails 1.3.6.1.2.1.6.7 1.3.6.1.2.1.6.7.0
— tcpEstabResets 1.3.6.1.2.1.6.8 1.3.6.1.2.1.6.8.0
— tcpCurrEstab 1.3.6.1.2.1.6.9 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 Index Index Index
tcpConnState tcpConnLocalAddres tcpConnLocalPort tcpConnRemAddres tcpConnRemPor
1.3.6.1.2.1.6.13.1.1 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
2 (listen) 0.0.0.0 12 0 0
1.3.6.1.2.1.6.13.1
tcpConnEntry
5 (established) 144.19.74.3 1453 144.19.74.99 21 (FTP)
1.3.6.1.2.1.6.13.1
tcpConnEntry
5 (established) 144.19.74.3 1768 144.19.74.99 20 (FTP-DATA)
1.3.6.1.2.1.6.13.1
tcpConnEntry
10 (timewait) 144.19.98.6 43 144.19.74.99 7
1.3.6.1.2.1.6.13.1
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 4
i pNe tToMed i aTab l e 22
i pNe tToMed i aEn t r y 1
1 2 3 4
i pNe tToMed i a I f I ndex i pNe tToMed i aPhysAddr ess i pNe t ToMed i aNe tAdd ress i pNe t ToMed i aType
3 00 0 0 c0 c5 ed 9 1 144 . 19 . 7 4 . 5 3
3 00 0 0 c0 10 c e 7 0 144 . 19 . 7 4 . 6 3
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) community data
GetRequest PDU
Current version number 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
In this chapter we have

• Examined the way in which Network Management stations communicate
with managed devices
• Identified the structure of SNMP for management
• Detailed the component parts of SNMP management
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 Network Technology
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 MSAN Metro Core

Environment
Complex
Cost Sensitive Complex, Costly,
Large, Fast Optical Bulk
Multi-Function
Simplified transport
Multi-Device Multi-function
Aggregation and
Multi-Service Wire-speed processing
Concentration
Real Time and Multi-access Aggregation
Streamed
xDSL Big
Application and Service
Consumer Ethernet Insertion Point Fast
SME WiFi IMS service broker Cost-effective
Enterprise WiMax requests
Locations in UK:
Millions ∼ 5500 ∼ 86 ∼ 20
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
100 Mbit/s
And above
40% 0.3 km
20 Mbit/s
1 km
6 Mbit/s
20% 3.7 km limit
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 Bit rates Distance Application

ADSL 1.5–12 Mbit/s down, 9,000–18,000 feet (2.7– Internet access,
16–640 kbit/s up 5.5 km) of telecommuting,
1-pair UTP video-on-demand
ADSL2+ 26 Mbit/s down
HDSL 1.5–2.0 Mbit/s, 15,000 feet (4.5 km) of T1/E1 replacement
symmetric 2- or 3-pair UTP
SDSL 1.5–2.0 Mbit/s, 10,000 feet (3 km) of 1- T1/E1 replacement

symmetric pair UTP
VDSL 13–52 Mbit/s down, 900–5,000 feet (0.3–1.5 ATM, HDTV

1.5–2.3 Mbit/s up km) of
1-pair UTP
VDSL2 100Mbit/s +
HDTV = high-definition television
See www.adsl.com, www.dslforum.org
and ITU-T Recommendations G.991–G.997
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
Network-
management
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 Source Ether-Type/ Normal 802.3

Payload CRC
Address Address Length Frame
TAG Inserted for

TPID Priority CFI VID
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
1 Background
2 Spare
0 Best Effort
3 Excellent Effort
4 Controlled Load
5 Video
6 Voice
7 Network Control
User Priority to Traffic Class mapping
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 Layer 3
Label LSR LSR LSR Label

added removed
5 17 17 15 15 3
5 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 O ut
4 7 .1 1
D est O ut 4 7 .2 2
4 7 .1 1 4 7 .3 3
4 7 .2 2
4 7 .3 3
Routing Table 1 47.1
IP 47.1.1.1
1 2 IP 47.1.1.1
D est O ut
3
4 7 .1 1 2
4 7 .2 2
4 7 .3 3 IP 47.1.1.1
1
47.3 3 47.2
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 Intf Label Dest Intf

In In Out Out In In Out
3 0.50 47.1 1 0.40 3 0.40 47.1 1
1 47.1
Request: 47.1
3
Intf Dest Intf Label
.1
In Out Out t: 47 2
eques 3
3 47.1 1 0.50 R 1
1 Mapping: 0.40
2
0
47.3 3 g: 0 .5
47.2
ppin
2 Ma
Labels are distributed along IP routes.
Notes:
Label Switched Path (LSP)

3 0.50 47.1 1 0.40 3 0.40 47.1 1
IP 47.1.1.1
1 47.1
Intf Dest Intf Label 3 3
In Out Out
3 47.1 1 0.50 2
1
1
2
47.3 3 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

3 0.50 47.1 1 0.40 3 0.40 47.1 1
Intf Dest Intf Label
In Out Out IP 47.1.1.1
1 47.1
3 47.1.1 2 1.33 3 3
3 47.1 1 0.50
2
1 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
Layer 2 Header Network Layer Header
(eg. PPP, 802.3) and Packet (eg. IP)
4 Octets
Label Stack
Label Exp. S TTL
Entry Format
Label: Label Value, 20 bits (0-16 reserved)
Exp.: Experimental, 3 bits (was Class of Service)
S: Bottom of Stack, 1 bit (1 = last entry in label stack)
TTL: Time to Live, 8 bits
MPLS
MPLSon
onPPP
PPPlinks
linksand
andLANs
LANsuses
uses‘Shim’
‘Shim’Header
HeaderInserted
Inserted
Between Layer 2 and Layer 3 Headers
Between Layer 2 and Layer 3 Headers
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 Pseudo-
Wire Emulation
— Uses protocol called PWE3
IP #Lp #L2
IP #Lp IP #Lp #L1 IP #Lp #L3 IP #Lp
IP #Lv IP #Lv #L1 IP #Lv #L3 IP #Lv

IP #Lv #L2
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 Possible Future Deployment

• Protocols: IPv4, OSPF, MPLS, LDP (DU, LL ret) • Many additional VPNs (000s)
• Virtualisation: IP VPNs (RFC4364 [RFC2547bis]), • Traffic engineering via RSVP-TE (RFC3209)
PWE3 (RFC3916) • Capacity and failure response optimisation via
• Resilience: Tx and FRR (RFC 4090) a bandwidth manager – connection oriented
• GR (RFCs 3623, 3478, 3473) flows
• QoS: 7 levels (6 user, 1 control) • Multicast
• Connectionless • IPv6
• Unicast
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,

4 the more stable the loading will be,
and thus the delay will be lower and stable
3 • Typically work with a 99% confidence level

Sporadicity
Big is beautiful!
2
10 100 1000 10000

Number of streams
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.
Here’s Cisco’s definition of RSVP:
The Resource Reservation Protocol (RSVP) is a network-control protocol that
enables Internet applications to obtain special qualities of service (QoSs) for their
data flows. RSVP is not a routing protocol; instead, it works in conjunction with
routing protocols and installs the equivalent of dynamic access lists along the routes
that routing protocols calculate. RSVP occupies the place of a transport protocol in
the OSI model seven-layer protocol stack.
Notes:
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 791 Precedence

000 Normal
001 Priority
010 Immediate
011 Flash
100 Flash Overide
101 Critical
110 Internet Management
111 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
Weight = 50
Class 2 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 Union–Technical Standardization Section
(ITU-T)
— Internet Engineering Task Force (IETF)
• ITU-T architecture for multimedia conferencing over packet networks
— ITU-T H-series standards define transmission of non-telephone signals
— H.323 Most of the currently available products use this
— Interfaces easily with world’s telephone networks
— Signaling is transferred from ISDN
— H.248 for controlling Media Gateways
• IETF SIP: the Session Initiation Protocol
— Much simpler to understand and use for simple voice calls
— Should be simpler to implement for developers, but…
– Interfacing to ISDN is more difficult
— Media Gateways and conferencing provided by MEGACO
– Same as H.248
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
C
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 BB
— 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
• 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 Robin My name Hello: I I am in
John here . . is Jane am Jan 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 Key system
TX 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 = 1 Sequence = 3
Timestamp=100 Timestamp=144
Sequence = 2 Sequence = 4
Timestamp=110 Timestamp=154
Silence threshold
140
160
100
120
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:
Real-Time Transport Protocol (RTP)
• TCP/IP protocol suite includes protocols for real-time applications

— Real-Time Transport Protocol (RTP)
— Real-Time Control Protocol (RTCP)
• RTP provides
— Timestamping, sequence number
– For playback timing and synchronization
— Setting up real-time applications
– Audio and video
• RTCP provides
— Reporting on achieved results
— Delay, packet loss statistics
— Receiver report on jitter delay
• Defined in RFC 1889
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
You’re 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 protocol—similar to H.323
— Not just voice
— Default “well-known-port” is 5060
• Supports five main functions
— User location
— Terminal capabilities
— User availability
— Call setup
— Call handling
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 known”port 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 Registrar
SIP Proxy
(outbound) SIP Proxy
SIP Redirect Server

SIP User Agent home.net SIP User Agent
pc.work.com Bestneutral.com 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
Alice’s SIP phone Bob’s SIP phone
atlanta.com biloxi.com
Proxy Proxy
INVITE
INVITE
100 Trying INVITE
100 Trying
180 Ringing
180 Ringing
180 Ringing 200 OK
200 OK
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 H.248.1 Gateway control protocol Version 2

body and
Annexes A to E)
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 H.248.10 Media gateway resource congestion
M.2 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 SS7
Gateway SIGTRAN/TALI/Q.2111
Q-BICC/SIP-T
SS7
SS7
Gateway Gateway
Controller Controller
Wireless
Access MEGACO/H.248 MEGACO/H.248
Media NEW
Trunking IP/ATM DOMAIN
Gateway Gateway
Enterprise
PSTN RTP/RTCP
Access
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
VoD
Video End Head (VEH) Decoders and Server
Transcoders
Video Hub Office (VHO)
Video Serving Office (VSO)
Management
and
Streamers Control
system
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 re-
multiplexing 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
Multicast
Layer 2
Routers
Primary Streamer Switches
IP Distribution
Network
Backup Streamer
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
Multicast
Layer 2
Routers
Primary Streamer Switches
IP Distribution
Network
Backup Streamer
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 VoD
Decoders and Server
Transcoders
• Decoders deliver
service that may be Management
transcoded to match Streamers
and
distribution standards Control
system
• Operators may use
telecommunications Core Internet
carriers service on
agency basis
• Time-slip TV produced Access
by storage on server
farm near downlink
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 VoD
Decoders and Server
Transcoders
• Must deliver high
reliability over long Management
range Streamers
and
Control
• Multiple QoS system
• May interface to the Core Internet

Internet
— Must use BGP
routing at the
interface to the Access
Internet
— Often MPLS for
speed inside
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 Internet
ISDN
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
— Digital Rights Management
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 rear-
projection 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 to 0x00FF Standardized systems
0x0100 to 0x01FF Canal Plus
0x0200 to 0x02FF CCETT
0x0300 to 0x03FF Deutsche Telecom
0x0400 to 0x04FF Eurodec
0x0500 to 0x05FF France Telecom
0x0600 to 0x06FF Irdeto
0x0700 to 0x07FF Jerrold/GI
0x0800 to 0x08FF Matra Communication
0x0900 to 0x09FF News Datacom
0x0A00 to 0x0AFF Nokia
0x0B00 to 0x0BFF Norwegian Telekom
0x0C00 to 0x0CFF NTL
0x0D00 to 0x0DFF Philips
0x0E00 to 0x0EFF Scientific Atlanta
0x0F00 to 0x0FFF Sony
0x1000 to 0x10FF Tandberg Television
0x1100 to 0x11FF Thomson
0x1200 to 0x12FF TV/Com
0x1300 to 0x13FF HPT - Croatian Post and Telecommunications
0x1400 to 0x14FF HRT - Croatian Radio and Television
0x1500 to 0x15FF IBM
0x1600 to 0x16FF Nera
0x1700 to 0x17FF 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 world’s 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
— Subject’s 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
60 36 million
World Cup
40 12 million
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
56
28.8
10.0 14.4
2.4
1.0 1.2
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
5 Mbit/s 10 sec
2 Mbit/s 5 sec
250 kbit/s 3 sec
64 kbit/s 1 sec
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 Broadcasting Protocols and Switching

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

IPTV Course Broadcasting Protocols and Switching

Transféré par

Droits d'auteur :

Formats disponibles

IPTV Broadcasting, Protocols

When you have completed this course you will be able to

• Chapter 1 Television Architecture and Evolution

Each day, the course will follow this schedule:

Start class 9 a.m.

Morning break 10:15 a.m. (approximately)

Resume class 1 p.m.

Afternoon break(s) As needed

Adjourn 4:30 p.m.

• Background and education

Television Architectures and

In this chapter we will

What is Television Today?

Analogue and Digital Compared

Delivery Systems: What are they

• What we see as essentially white light is a band of energy

• A colour TV camera filters the light into three primary bands

• Primary colours can be mixed in proportion to form white

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

Improving the resolution and interlacing, displaying alternate lines in consecutive

Horizontal Vertical Pexils RGB Color Detail %

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

Name Prog. Total Active Vert. Horz. Opt. Asp. freq.

NTSC i 525 484 242 330 7 4/3 4.2

PAL i 625 575 290 425 6 4/3 5.5

SECAM i 625 575 290 465 6 4/3 6

What is Television Today?

Analogue and Digital Compared

Delivery Systems: What are they

• For picture quality to be maintained we must sample often enough

• Compression is possible once we are in the digital domain

What is Television Today?

Analogue and Digital Compared

Delivery Systems: What are they

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

• Expanded services are those that go beyond the distribution of TV

• Telephony is - or was - a high value service

• Internet access can be provided via cable modems

• All TV distribution systems must provide information on programmes

• Interactive gaming takes 3 major forms

What is Television Today?

Analogue and Digital Compared

Delivery Systems: What are they

In this chapter, we have

Broadcast Distribution Systems

Cable TV Delivery Systems

Set-top box for

• Digital Satellite Receiver

• An important part of the Headend function is encoding TV signals

• Acts as a switch between video feeds and output to cable

• Headend equipment must be controlled

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

• The goal of design is to deliver good signal levels to each consumer

Device Loss (-dBmV)

2-Way Splitter/Combiner 4.0

3-Way Splitter/Combiner 6.5

4-Way Splitter/Combiner 8.0

8-Way Splitter/Combiner 12.0

100 ft RG6 4.0

• Higher frequencies suffer more loss over coaxial calbes

• Optical systems also depend upon loss levels

Step Index Multimode Fiber