Welcome to Week Nine! VoIP and IPTV + Introduction to Multicast
description
Transcript of Welcome to Week Nine! VoIP and IPTV + Introduction to Multicast
P00556-7-1
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Welcome to Week Nine!VoIP and IPTV + Introduction to Multicast
Topics:
VoIP and IPTV
Introduction to Multicast
References and Tutorial Topics
P00556-7-2
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Welcome to Week 4:Multimedia Frameworks and VoIP
Background
RTP and RTCP
Standards
Signalling
P00556-7-3
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Multimedia Transport over Data Networks
UNIVERSE (1980 – 1983) – and many other R&D projects IETF
– Early voice experiments carried out in 1970s
– Effort accelerated during 1990s» Leading to work on IntServ and DiffServ
ITU-T– Introduction of digital telephone networks led to development of multimedia-
aware signalling» Signalling System Number 7 (Q.700 Series) within the network» ISDN Q.931 for user-network signalling» ATM (Q.2931) had a fully-fledged multiservice signalling scheme
– A number of multimedia frameworks followed» Discussed later
QoS schemes need to be integrated with the multimedia streams– Requires a multi-faceted approach
» End-to-end and hop-by-hop components
P00556-7-4
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Protocol Considerations
VoIP protocol structures are designed to be lightweight Existing Transport protocols pose problems
– TCP introduces
» possibility of retransmissions
» variable-rate throughput owing to congestion control mechanisms
– UDP provides application demultiplexing and checksum
» necessary, but insufficient
VoIP frameworks– Use existing (public network) standard voice and video coding schemes
– Define two new transport protocol: RTP and ScTP
– Add call control alternatives: H.323 (public networks) or SIP (IP networks)
– Operate best in conjunction with QoS-aware network differentiation
» IntServ or DiffServ
RTP = Real-time Transport ProtocolScTP = Stream control Transport Protocol
P00556-7-5
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Multimedia Transport over IP
IP
UDP
Multimedia applications
RTP RTCP
Audio and video codecs
Note: shows data transfer protocols only; signalling protocols and control infrastructure are discussed later
P00556-7-6
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Voice over IP
Background
RTP and RTCP
Standards
Signalling
P00556-7-7
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
RTP: The Real Time Transport Protocol
Supports isochronous transmissions over IP networks– For example multicast audio and/or video
– Incorporates provision for audio and video mixers and translators
– RTP is for isochronous transmission while TCP and UDP are asynchronous transmission
Operates with unicast or multicast streams Uses minimalist approach to protocol design: Little supports
– Adds timestamps and sequence numbers to outgoing voice/video stream
– Timestamps provide receiver synchronization support and help with jitter compensation
– Sequence numbers help to indicate packet loss or out-of sequence delivery
– Leaves UDP to add checksum for packet verification
Supports mixers and translators– Mixers can merge several streams onto single stream
– Translaters (or ‘transcoders’) translate between different transmission schemes
P00556-7-8
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
RTP Packets
Voice or video samples are encapsulated in RTP packets– Generally speaking, one UDP datagram carries one RTP packet
Timestamp
SSRC (synchronizing source identifier)
CSRCs (contributing source identifiers)
Sequence numberFlags Payload type
payload
optional header extension
P00556-7-9
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
RTP Header Flags
V: version = 2
P: set to 1 to indicate payload padding (length is in last byte)
X : set to 1 if extension headers present (rare)
CC: = CSRC count (number of contributors)
M: marker bit (marks, e.g., new talkspurt or end of video frame)
Timestamp
Sequence numberPayload typeV XP CC M
bit 0 2 3 4 8 169
P00556-7-10
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Common RTP Payload Types
0 PCM μ-law (PSTN audio) 26 JPEG video
3 GSM audio 31 H.261 video
8 PCM A-law (PSTN audio) 33 MPEG-2 video
9 G.722 audio 34 H.263 video
15 G.728 audio 35-95 Unassigned or reserved
18 G.729 audio 96-127 Dynamic payload types
Timestamp
Sequence numberPayload typeV XP CC M
bit 0 2 3 4 8 169
P00556-7-11
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
RTCP
Adds periodic control frames into session traffic– Can support multiple sessions having multiple data streams
Provides several services to RTP session participants– Stream reception reports
– Session source descriptor
– Optional participant information
– Participant leaving session
– Other, application-specific, functions
Includes self-imposed rate-based flow control for scalability– Ensures RTCP messages do not exceed 5% of overall session (RTP) traffic
Several RTCP messages can be packed into a single UDP datagram
P00556-7-12
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
RTCP Messages
Sender report contains transmission and reception information from active senders
– Associates RTP timestamps, packet and byte counts with an NTP timestamp
– Includes reception report blocks (one for each SSRC known to sender)
Receiver reports– Transmission and reception information from listeners who are not also
active senders
» Similar to sender reports, but exclude timing information
Source description packet– Includes participant CNAME
– May optionally include one or more of:
» Sender name, email, telephone number, location
BYE contains details of sender(s) leaving session
P00556-7-13
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Voice over IP
Background
RTP and RTCP
Standards
Signalling
P00556-7-14
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
ITU-T Voice and Video Codec Standards
ITU-T standards focus on voice and video capture for transport over public networks
Voice codec standards include– PCM-based: G.711 (64kbps), G.722 (64kbps wideband voice),
G.726 (32kbps ADPCM)
– Predictive modelling: G.728 (16kbps), G.729 (8 kbps) and G.729A (8 kbps)» Computationally complex and lower quality than PCM-based schemes» May introduce additional coding delay
Video codec standards include– Intra-frame compression only: H.261 (64-1920kbps for video over ISDN),
H.262 (video over ATM)
– Intra- and inter-frame compression: H.263 (video over PSTN)
Video standard also devised by Moving Picture Experts Group (MPEG) MPEG-4 and H.264 (2003) are the same
– Result of ITU-T/MPEG collaboration
P00556-7-15
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
ITU-T Audio and Video Frameworks
ITU-T have addressed audio and video standards for many years– Initially concentrating on capture, compression and transmission over
circuit networks
– Latterly, including packet networks
» H.323 called these ‘Networks with no QoS guarantees’
Have developed a series of frameworks for integrated solutions– H.320: Videoconferencing over ISDN (v1 – 1996)
– H.321: Videoconferencing over Broadband ISDN (ATM/SDH) (1998)
– H.322: Videoconferencing over LANs with QoS (1996)
» E.g. isochronous Ethernet – IEEE 802.9
– H.324: Videoconferencing over PSTN (v1 – 1995)
– H.323: Videoconferencing over packet networks (v1 – 1996)
» v2 – 1998; v3 – 1999
» v4 – 2000; v5 - 2003
ITU-T = International Telecommunications Union :Telecommunications (Standardization Sector)
P00556-7-16
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Standards for Voice
Codec standard
Compression algorithm
Digital bitrate(kbps)
Sample size(ms)
MOS Use
G.711 PCM 64 0.125 4.1 PSTN
G.726 ADPCM32, 24,
160.125 3.85 ISDN
G.728 LD-CELP 16 0.625 3.61 ISDN
G.729 CS-ACELP 8 10 3.92 VoFR and VoIP
G.729A CS-ACELP 8 10 3.7Algorithm less
complex than G.729
G.723.1 ACELP 5.3 30 3.65 Speech modems
ADPCM = adaptive differential pulse code modulationCS-ACELP = conjugate-structure algebraic-code-excited linear predictionLD-CELP = low-delay code-excited linear predictionVoFR = voice over frame relay
P00556-7-17
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Other Audio Standards
Format Sampling rate Digital bitrate Use
MP2 32–48 kHz 32–284 kbpsDigital audio broadcasting
MP3 32–48 kHz 32–320 kbpsPC, personal and
Internet
WMA 8 Up to 48 kHz Variable Near-CD quality
WMA 9 Variable Variable Lossless, high-quality
MPEG-4AAC
8–96 kHzVariable,
depending on algorithm
MP3 replacementUses different
algorithms dependingon required quality
and bitrate
AAC = advanced audio codingMPEG = Moving Picture Experts GroupMPn = MPEG-1 Layer nWMA = Windows Media Audio
P00556-7-18
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Standards for Video
Codec standard
Date published
Digital bitrate(Mbps)
Use
H.261 1990 0.46–1.92 Videoconferencing over ISDN
H.262/MPEG-2 1997 4–9 DVD, satellite and cable TV
H.263 1997 1–9 Small-screen PSTN,
videoconferencing, VoIP;extensible to larger resolutions
H.264/MPEG-42003–2005
1.5–2.5 High-quality video at relatively low bitrates; e.g., HD video storage,
IPTV
P00556-7-19
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Voice over IP
Background
RTP and RTCP
Standards
Signalling
P00556-7-20
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Topics:
VoIP and IPTV
Introduction to Multicast
References and Tutorial Topics
P00556-7-21
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Introduction to Multicast
Overview
Why Multicast?
Trees, addressing and membership
Dense and sparse mode; reverse path forwarding; more trees
Tutorial Topics
P00556-7-22
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Reminder of some application examples I
one-to-many:
– web or Internet TV
» subscriber joins in real time at point
‘live programme’ has reached
– (streaming) video on demand
» subscriber typically wishes to see
from beginning
many-to-many:
– conferencing (usually all-to-all within a
group)
– group teaching (all listen, maybe only
subset speak)
P00556-7-23
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Reminder of some application examples II
many-to-one: Concast
– statistics logging
– sensor ‘fusion’ (plant or utility infrastucture monitoring, wildlife tracking)
– coursework submission
– not studied very much, except as a particular case of many-to-many
P00556-7-24
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Terminology reminder I
Often classified in terms of numbers of senders and receivers (m:n) Distinguish application and network views of communication
– telephony is (mostly!) two-way alternate
» underlying communications channel may be full-duplex, half-duplex, or a pair of simplex channels in opposing directions
P00556-7-25
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Terminology reminder II
one-to-one: unicast (1:1)– one-to-one: usually of application
– unicast almost always refers to layers below application
one-to-many: (sometimes many-cast, also multicast & broadcast) (1:n)– one-to-many: application or lower layers
– multicast: mainly lower layers, implies subset of all possible recipients
– many-cast: often application
– broadcast: application or lower layers; implies all possible recipients
many-to-one: (sometimes concast) (m:1)– many-to-one: application
– concast: deprecated
m-to-n: (sometimes multipeer) (m:n), or all-to-all if m = n
P00556-7-26
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Senders and Receivers I
Group communication– each member may be a sender, a receiver, or both
If no member is a receiver, communication is pointless!– important to operation of multicast routing protocols
Most communication is thought of in terms of multiple one-to-many– m-to-n is often thought of as m instances of 1-to-n
– rather like constructing full-duplex channels out of simplex channels
– Note that this implies nothing about any relationship between senders and receivers
P00556-7-27
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Senders and Receivers II
For a member that is both receiver and sender, does it receive its own transmissions?
– audio channel in conference: usually not, confusing
– video channel in conference: sometimes could be useful
– email to a list: often an option on the list; defaults vary!
– CSMA/CD: CD would not work without it!
» but host usually chooses not to listen to own frame at a higher level
– So, typically not
P00556-7-28
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Issues for multicast I
Identifying group members– Neither unicast nor broadcast are adequate
– Achieved with special addressing scheme for active participants
Tracking current group membership– Uses a dynamic membership protocol
– Not required for fixed groups
Efficient distribution mechanism– To avoid multiple copies of same information traversing same part of network
– Network must be multicast-aware
– Capable of packet replication and controlled flooding
Multicast routing scheme to maintain fault-tolerant distribution topology– Discussed later in course
P00556-7-29
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Issues for multicast II
Scaling
– how to deal with large numbers of users (100s, 1,000s, …)?
– affects network and end stations
– reliable unicast protocols need acknowledgements from receiver to sender
» reliable multicast cannot operate in the same way
Timing
– a much more complex set of issues in group communication since there are more than two views of time
– group aspects are primarily end host application concerns,not network
We will confine our attention to network support for multicast
Audio-video conference as exemplar: major application driver
P00556-7-30
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Introduction to Multicast
Overview
Why Multicast?
Trees, addressing and membership
Dense and sparse mode; reverse path forwarding; more trees
Tutorial Topics
P00556-7-31
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Network Multicast I
An immediate scaling problem:– multipoint conference: all senders need to reach all receivers with each stream
» audio, video, shared application (e.g., whiteboard, powerpoint, excel)
Problems with using replicated unicast:– senders will (with large number of receivers) be overloaded– links near senders will also be overloaded– delay will increase: sender sends many copies sequentially– large conferences, TV distribution, etc, will be impossible– [see diagram]
P00556-7-32
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Using replicated unicast
S
Rx Rx
Rx
Rx
Rx
Rx
Rx
Rx
Rx
R
R
R
R
9
3
2
2
1
1
P00556-7-33
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Network Multicast II
An immediate scaling problem:– multipoint conference: all senders need to reach all receivers with each stream
– audio, video, shared applications (eg, whiteboard, powerpoint, excel)
Problems with using replicated unicast (recap.):– senders will (with large number of receivers) be overloaded– links near senders will also be overloaded– delay will increase: sender sends many copies sequentially– large conferences, TV distribution, etc., will be impossible
Solution:– eliminate multiple copies of same packet on any link and from sender– ensure ‘best’ routes are used: much harder– [see diagram]
P00556-7-34
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Using multicast
S
Rx Rx
Rx
Rx
Rx
Rx
Rx
Rx
Rx
R
R
R
R
E.g., sender-based tree, overlaid on physical network:1 copy of each packet per link
P00556-7-35
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Network Multicast III
An immediate scaling problem:– multipoint conference: all senders need to reach all receivers with each stream
» audio, video, shared application (e.g., whiteboard, powerpoint, excel)
Problems with using replicated unicast (recap.):– senders will (with large number of receivers) be overloaded– links near senders will also be overloaded– delay will increase: sender sends many copies sequentially– large conferences, TV distribution, etc., will be impossible
Solution:– eliminate multiple copies of same packet on a link;– ensure ‘best’ routes are used: much harder
NB sender-based tree not necessarily optimal: » receiver-based possible;» core-based tree (CBT) has advantages, idea incorporated into PIM-SM
Overload at or near receiver?– only few (one) sender(s) active: may be able to receive all– select or combine near receiver
P00556-7-36
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Introduction to Multicast
Overview
Why Multicast?
Trees, addressing and membership
Dense and sparse mode; reverse path forwarding; more trees
Tutorial Topics
P00556-7-37
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Types of Multicast Tree
sender-based (as previous diagram)– SBT is were the tree is routed at the sender
– is most economical way of doing isolated multicast in a network
– is not static like in the case of spanning tree protocol its changes as the number as host changes so the router has to argile enough for instance I got no people here I don’t need to send any packet here, I got many ppl here I need to send more packet here
receiver-based tree also possible– natural for fusion-based applications
– not studied here
» but we will mention destination-based flows in the context of MPLS core-based
– compromise
– may be appropriate as default
– engineer sender-based as traffic begins to flow
P00556-7-38
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Routing and Membership
Growing, pruning, removing multicast trees is job of multicast routing– algorithms and protocols
– remember, IP routing is amongst subnets (whether unicast or multicast)
– So if a person come or leave the network there is a membership group to coordinate the trees for the multicast distribution of packets
– -there are two major membership protocols
– The major was IGMP v1
Starts from membership and addressing– Internet Group Management Protocol: IGMP
» two versions; IGMPv1 largely obsolete
P00556-7-39
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Multicast Addressing
Fixed multicast groups use “well-known” (reserved) addresses– Specified in IETF Assigned Numbers list
– Gives reserved L2 and L3 addresses
– For example
» The All Spanning Tree Bridges MAC address
» The All OSPF Routers IP address Dynamic multicast groups can select from a range of reserved addresses
– Most of the original Class D address group
» IP address range 224.0.0.0–239.255.255.255 (IP Prefix 224/4)
– Special ranges include
» 224.0.0/24: reserved for link local multicast Router will not forward off subnet
» 224.2/16 reserved for multimedia conference calls
» 239.252/14 reserved for site-local multicast IETF also gives mapping of L3 to L2 equivalent addresses
– Programmed dynamically into network interface cards
P00556-7-40
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Some Multicast Addresses
224.0.0.1All systems
on this subnet
224.0.0.2All routers on this subnet
224.0.0.6All (OSPF) Designated
Routers
224.0.0.9All RIP2 routers
224.0.0.10
All EIGRP routers
224.0.0.11
All mobile agents
224.0.0.13
All PIM routers
Some reservedmulticast addresses
All OSPF routers224.0.0.5 (IP)
All Spanning Tree bridges01-80-C2-00-00-00 (MAC)
All conference participants224.2.1.225 (IP)
P00556-7-41
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
IGMP: Internet Group Membership Protocol
Timer-driven query/response protocol between routers and hosts
– Hosts join group using multicast address for that group
– Router polls All Systems group (224.0.0.1) periodically
» To reaffirm membership
Two versions of IGMP
– IGMPv1 specified in RFC 1112
» Largely historical
» Leaves group by not respondingto Membership Report
» Allows association to time out
– IGMPv2 specified in RFC 2236
NB. In IPv6, IGMP is part of ICMPv6
Leave Group
Join/ReaffirmMembership
P00556-7-42
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
IGMP (Version 2)
Each subnet has at least one multicast router– Where there is more than one router, one
becomes the Querier for that subnet
– Multicast routers defer to Queriers with a lower IP address
» Prevents excessive query traffic
The Querier for a subnet– Tracks active group addresses
» Periodically sends Query messages Either general query to AllSystems group
– 224.0.0.1
Or a Group-specific Query
– Stops sending when no hosts respond
» Or all hosts have left group
» And informs multicast routing protocol
Still some members of 224.2.1.225out there?
P00556-7-43
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
IGMP (Version 2 – cont.)
Multicast host on subnet– Joins group by multicasting a Membership
Report for that group address
– Remains in group by respondingto Query messages
» Includes addresses of all groupsfor which host wishes to retainmembership
» Delays response for random periodto reduce number of responses forsame group
– Leaves group by sending Leave message toAllRouters group
» 224.0.0.2
Still some members of 224.2.1.225out there?
MRep224.2.3.1
Yes
Leave Group224.2.3.1
P00556-7-44
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Introduction to Multicast
Overview
Why Multicast?
Trees, addressing and membership
Dense and sparse mode; reverse path forwarding; more trees
Tutorial Topics
P00556-7-45
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
DM / SM Protocols
There are two ways of distributing multicast: Dense Mode:
– DM is sending the multicast packet to everyone in the group. Periodically sending to everybody it important when you got a lot of people in a company LAN but it wont woke in the IP internet u got periodic saturation
– Typified by ‘flood and prune’ behaviour
– Appropriate only if:
– restricted scope: not whole world
– most hosts in scope want to receive
– Sparse Mode:
– you send when someone sign on– Typified by ‘send on request’ behaviour
– group membership (though actually, it’s likely needed anyway).– End-system gets nothing unless it explicitly asks for it
– Appropriate when:
– only some of hosts want to receive
– scope is potentially worldwide
P00556-7-46
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Topics:
VoIP and IPTV
Introduction to Multicast
References and Tutorial Topics
P00556-7-47
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
References for VoIP
Author Chapters and main topics Notes
Peterson &Davie
9.3 Multimedia ApplicationsRTP, RTCP, SIP and SDP, but not much on H.323
Halsall 5.3 IPC StandardsOverviews of the H.32x frameworks and their constituent standards
There is some VoIP in one of the texts from last semester:
Forouzan
(4th edition)29.5 Real-Time Interactive Audio/Video As P&D
Note: Use manufacturers’ web pages with care!
P00556-7-48
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Refs. for multicast, RSVP & IntServ
Wittman & Zitterbart: Multicast Communication– parts of Chapter2; parts of Chapter 3: 3.1–3.3; parts of Chapter 4 (up
to 4.1.2); Mbone & application: parts of Chapter 7.
Peterson & Davie: Computer Networks (3rd ed.)– Section 4.4,esp. 4.4.3.
– Chapter 6, 6.1, 6.2, 6.5.2
Stallings: High-Speed Networks (2nd ed.)– Section 16.2 (multicast); Chapter 17: Sections 17.1, 17.2.
– Chapter 18: 18.1 RSVP.
Zheng Wang: Internet QoS– Chapter 1: 1.1; Chapter 2, 2.1, 2.3, 2.4, 2.5
P00556-7-49
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
VoIP and IPTV Tutorial Questions
1. General pointsa) What is signalling and what differences would you expect to see between
normal telephony and multimedia communication protocols?
b) What type of voice do G.722 and G.729.1 encode?
c) Which protocols are responsible for voice/video transport?
2. H.323a) What is an ITU-T framework, and in what way does it support QoS?
b) What are the main components of an ITU-T framework?
3. SIPa) What happens immediately after the initial handshake?
b) SIP supports ‘presence’. What is this?
P00556-7-50
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
VoIP and IPTV Tutorial Questions (cont.)
4. RTP
a) What is an RTP session?
b) Are RTP packets carried individually across an IP Network?
5. RTCP
a) What are the main functions of RTCP?
b) What sort of QoS information is included in an RTCP reception report block?
P00556-7-51
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Tutorial topics: multicast
1. What IEEE MAC group addresses are IP multicast addresses 224.1.5.20 & 227.129.5.20 mapped into? What happens at a receiver interested in only one of these?
2. Multicast is good for senders. What about receivers? Why does audio multicast work for the receivers? What about video? Discuss.
3. What is IGMP snooping?
P00556-7-52
MultiserviceNetworks
Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010
Tutorial topics: multicast (cont.)
5. Consider the set of four routers interconnected as in the diagram.
If a single multicast packet is injected at a, using simple flooding (forward on all links exceptentry link), what will happen on the internal & external links (b, c, d)? Now use RPF.
6. Draw a diagram to demonstrate flooding + RPF delivering duplicate packets.
7. What messages in which protocol might you use for pruning and grafting?
R
R R
Ra
dc
b