P00556-7-1 Multiser vice Networks xford 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
52
Embed
Welcome to Week Nine! VoIP and IPTV + Introduction to Multicast
Welcome to Week Nine! VoIP and IPTV + Introduction to Multicast. Topics: VoIP and IPTV Introduction to Multicast References and Tutorial Topics. Welcome to Week 4: Multimedia Frameworks and VoIP. Background RTP and RTCP Standards Signalling. Multimedia Transport over Data Networks. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
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
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.
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?