Chapter 10 Advanced Network Architectures

Transcription

1 Chapter 10 Advanced Network Architectures Integrated Services in the Internet RSVP Differentiated Services Network Interconnection Models MPLS Multimedia Networking Real-Time Transport Protocol Session Control Protocols

2 Chapter 10 Advanced Network Architectures Integrated Services in the Internet

3 Integrated Services IP Model Defines a flow as a stream of IP packets Generated by a sender and destined to a destination That require the same QoS Provides QoS to individual flows in the Internet Better than Best Effort for some applications Support for real-time voice and video applications Requires traffic management mechanisms to deliver appropriate QoS to each flow Packet classification, scheduling, admission control Explicit reservation of buffers and bandwidth resources for individual flows at every node Resource Reservation Protocol (RSVP) provides means for making reservations

4 Network Service Models Best effort service No guarantees; suitable for elastic traffic At low loading, suitable for many traffic classes Guaranteed service bound on maximum delay guarantee on available bandwidth Controlled load service delay consistent with lightly loaded network

5 IntServ Router Model Input driver Routing agent Routing database Classifier Internet forwarder Reservation agent Admission control Management agent Traffic control database Packet scheduler Output driver Accept/reject a flow Identify a packet s flow Buffering to control loss Transmission scheduling to control delay Traffic management mechanisms discussed in Chapter 7

6 End-to-End Performance End-to-end performance for an individual flow is the result of per-switch performances delay, jitter, loss, bandwidth Per-switch performance depends on: per-packet processing common to all packets specific per-connection or per-class treatment Resources must be allocated by RSVP at each node for each flow Router 1 Router 2 Router 3

7 Admission Control Individual flow negotiates admission into the network Flow Descriptor has two parts 1. Filter specification (filterspec) provides information required by classifier to identify the packets in the flow 2. Flow specification (flowspec) describes traffic properties of flow and QoS requirements Traffic Specification (Tspec) describes traffic in terms of a token bucket Request Specification (Rspec) describes QoS in terms of bandwidth, delay, loss Each node along path must decide whether a flow can be accepted

8 Guaranteed Service Intended for flows that require real-time packet delivery Provides a firm delay bound Each flow is shaped by (b,r) leaky bucket b token bucket size r token rate Police the flow to ensure compliance Reserve bit rate R>r at every node (weighted fair queueing) Account for other network parameters D b R + ( H 1) m R + H j= 1 M R j From Chapter 7: m maximum packet size in flow M max packet size in network R j bit rate of link j H number of hops in path

9 Controlled Load Service Intended for flows that can tolerate some delay but are sensitive to traffic overload Equivalent to Best Effort under Light Traffic Low delay and low loss, but no quantitative guarantees Less complex than guaranteed service Each flow is shaped by (b,r) leaky bucket Use admission control to limit volume of controlled load service Reserve bit rate for the entire class to ensure light traffic mode Police each flow to ensure compliance; Non-conforming packets accorded best effort service

10 IntServ involves High Complexity Input driver Routing agent Routing database Classifier Internet forwarder Reservation agent Admission control Packet scheduler Management agent Traffic control database Output driver Number of (application) flows can become extremely large Per-flow treatment involves high complexity Traffic Management Per-flow classifier Per-flow queueing Per-flow scheduling Hugh table sizes & high hardware complexity Admission Control Set up & maintenance of individual flows High processing load IntServ is not scalable

11 Chapter 10 Advanced Network Architectures RSVP

12 ReSerVation Protocol (RSVP) RSVP is an IP signaling protocol to setup and maintain flowspecific state in hosts and routers Multicast-oriented Performs resource reservations for multipoint-multipoint applications Adapts changing group membership & routes Unicast, a special case Simplex Requests resources from sender to receiver Bidirectional flows require separate reservations Receiver-oriented Receivers initiate and maintain resource reservations Soft-state at intermediate routers Reservation valid for specified duration Released after timeout, unless first refreshed

13 RSVP Sessions S1 S2 Multicast distribution by Internet R1 R3 R2 Session: a data flow identified by destination address (unicast/multicast), transport layer protocol, & destination port # (optional) Packets flow from multiple senders to multiple receivers

14 RSVP Architecture Host Router Application Data RSVP process Policy control RSVP Routing process RSVP process Policy control RSVP Admission control Admission control Classifier Packet scheduler Data Classifier Packet scheduler Data Application requests QoS from RSVP process RSVP prepares & sends request messages to router Policy control determines if application allowed to make request Admission control determines if resources available; sets up classifier & packet scheduler

15 RSVP Reservations Request RSVP Reservation Requests include: Flowspec: specifies traffic and performance requirements of a flow RSVP carries flowspecs and installs them in switches Flowspec invokes admission control & sets scheduler Filterspec describes packets that can use resources Wildcard filter: single reservation for all senders in a session Fixed filter: distinct reservation for each sender Dynamic filter: single reservation for a specified set of senders RSVP does not interpret the flowspecs and filter specs, it only carries them

16 PATH PATH S RESV R1? RESV PATH R2 PATH RESV R3? RESV Rx? Sender multicasts PATH message that describes traffic flow Uses an existing routing protocol Each router stores address of previous RSVP router (PHOP) and inserts its address in last hop field and forwards message, establishing the path in the reverse direction Receiver unicasts RESV message to reserve resources (Can request confirmation from sender) Each router performs admission & policy control (Send PathErr message if rejected) Reservations may be modified or merged as RESV proceeds back to sender

17 Reservation Merging Path S Path R1 Path Path R3 Resv Path Rx1 Resv Resv Resv Rx2 Resv R2 Path Path Resv R4 Rx3 Resv Resources are shared among receivers up to point where paths to different receivers diverge RSVP process at nodes will merge requests at node where sufficient resources are already reserved Request is not forwarded beyond merge point

18 Reservation Styles S1, S2, S3, R1, R2, R3 belong to the same session Can S2 & S3 share the bandwidth reserved by S1? Yes if application has one sender transmit at a time No if multiple senders transmit How does router know which senders can access a reserved resource? Explicit List Wildcard (Any sender in session) S1 S2,S3 Router R1 R1, R3 Fixed Filter Separate reservations Explicit list Wildcard Filter Shared reservations Wildcard (all senders) Shared Explicit Filter Shared reservations Explicit list

19 Example S1 a c R1 S2, S3 b Router d R2 R3

20 Wildcard Filter Send Reserve Receive WF( *{4B} ) (a) *{4B} (c) WF( *{4B} ) WF( *{4B} ) (b) *{3B} (d) WF( *{3B} ) WF( *{2B} ) Wildcard request for 4B from R1 Wildcard request for 3B & 2B from R2 and R3; Merged into 3B request Inputs merge requests to 4B before upstream Example: audioconferencing with different bitrates

21 Fixed Filter Send Reserve Receive FF( S1{4B} ) (a) S1{4B} S2{5B} (c) FF( S1{4B}, S2{5B} ) FF( S2{5B}, S3{B}) (b) S1{3B} S3{B} (d) FF( S1{3B}, S3{B} ) FF( S1{B} ) FF request from R1 for 4B from S1, 5B from S2 FF request from R2 for 3B from S1, B from S3 FF request from R3 for B from S1 Merge request to S1 for 3B Merge request to S1 for 4B Example: all-to-all videoconference

22 Shared Explicit Send Reserve Receive SE(S1{3B}) (a) (S1,S2){B} (c) SE((S1,S2){B}) SE((S2, S3){3B}) (b) (S1,S2,S3) {3B} (d) SE((S1,S3){3B}) SE(S2{2B}) SE request for B for S1 & S2 from R1 SE request for 3B for S1 & S3 from R2 SE request for 2B for S2 from R2 Merge to union of list (S1, S2, S3) & max request, 3B Example: layered video

23 RSVP Soft State Reservations are valid for a timeout period Need to refresh reservation state by resending PATH & RESV messages before expiry time Reservation removed if not refreshed by timeout RSVP runs directly over IP with type=46 message delivery is not reliable Assume 1 in 3 consecutive messages gets through Nominal refresh rate specified by R (usually 30 sec) Refresh period for a receiver randomized from (0.5R, 1.5R) to avoid simultaneous refresh attempts PathTear & ResvTear messages explicitly delete reservations

24 RSVP Message Header Version Flags Msg Type RSVP Checksum Send_TTL Reserved RSVP Length Version: 1 Flags: undefined Internet Checksum Send_TTL: TTL of originating IP packet Detects non-rsvp routers Length: total RSVP message Message Types Path Resv PathErr PathTear ResvTear ResvConf

25 RSVP Message Objects SESSION: IP destination address, IP protocol number, and destination port # RSVP_HOP: IP address of RSVP-capable router that sent this message TIME_VALUES: refresh period R. STYLE: reservation style information not in flowspec or filterspec objects FLOWSPEC: desired QoS in a Resv message. FILTER-SPEC: set of packets that receive desired QoS in a Resv message. SENDER_TEMPLATE: IP address of the sender in Path message. SENDER_TSPEC: sender s traffic characteristics in Path message. ADSPEC: carries end-to-end path information in Path message. ERROR_SPEC: specifies errors in PathErr and ResvErr; confirmation in ResvConf. POLICY_DATA: enables policy modules to determine whether request is allowed INTEGRITY: cryptographic and authentication information to verify RSVP message SCOPE: explicit list of senders that are to receive this message. RESV_CONFIRM: receiver IP address that is to receive the confirmation.

26 Chapter 10 Advanced Network Architectures Differentiated Services

27 Differentiated Services Differentiated Services (DiffServ) model is designed to be scalable and to provide QoS Traffic is aggregated into a limited number of classes Service is on aggregate-flow basis, not per individual flow Each class receives a well-defined service treatment at each DiffServ router No per-flow signaling

28 Forwarding Path Architecture H H H H A A A C SLA Notwithstanding A C = Core Router A = Access Router H = Host DiffServ Domain H C A TCA A C Complexity at the Edge User negotiates Service Level Agreement (SLA) with service provider SLA includes a Traffic Conditioning Agreement (TCA) stipulating service level, traffic profile, marking, shaping Access Router classifies user packets and marks them in DS field of IP header as belonging to a specific class conditions packet stream so it conforms to profile

29 Forwarding Path Architecture H H H H A A A C A C = Core Router A = Access Router H = Host DiffServ Domain H C A A C Simplicity in the Core Aggregate-flow or class identified by a particular value in the DS field Core routers provide a limited number packet forwarding options called Per-Hop Behaviors (PHBs) Value in DS field identifies class and PHB Router resources reserved on aggregate-flow basis, not per-flow

30 Differentiated Services Field DSCP CU Differentiated Services Codepoint (DSCP) Six bits in the IPv4 TOS field DSCP value specifies PHB in core router Currently Unused Router uses DSCP as index that determines buffering & scheduling treatment for a packet A recommended set of DSCP-to-PHB mappings But service providers free to choose their own mapping TOS Backwards Compatibility: Default (Best Effort), 11x000 Network Control

31 Per-Hop Behaviors Several PHBs defined by IETF DE (Default) PHB: Best effort Expedited Forwarding (EF) PHB: Premium Low loss, low latency, low jitter, assured-bandwidth end-toend transfer Assured Forwarding (AF) PHB: Better than Best Effort High assurance of delivery if traffic profile kept Four independent AF classes Provide four levels of assurance Three values of packet drop precedence within each level Router must preserve sequence of packets within same microflow (same application flow, same AF level)

32 PHB and Traffic Management PHB definition do not specify mechanism to implement behavior EF PHB HOL priority queueing, Weighted Fair Queueing, or combination AF PHB: Different levels of drop-precedence RED with IN/OUT (RIO) Maintain running averages Q IN : avg # conforming packets in buffer Q T : avg # total packets in buffer IN packets dropped according to RED algorithm using Q IN OUT packets dropped according to RED using Q T OUT packets dropped more aggressively than IN packets

33 Possible Core Router Design Define two basic priority classes serviced Use RIO mechanism on the lower priority queue(s) Y High Priority Input Packet EF? Scheduler Output Packet N Low Priority Could define several classes Each with separate queue RIO Queue Management

34 DiffServ across Domains H H H H A A A C Local DS domain H A C A A B B = Border DS router B Contracted aggregate rate C Transit network SLA must be in place between domains Egress border router must condition traffic to contracted profile Ingress border router classifies & conditions traffic DSCP values may need to be mapped if domains use different DSCP-PHB mappings

35 Traffic Conditioner Meter Classified packets Marker Shaper/ dropper Conditioned packets Meter measures traffic and checks for conformance to traffic profile Token bucket to check peak rate, sustained rate, maximum burst size Marker sets DSCP Remark to lower class if non-conforming Shaper/Dropper: Shape to profile; drop nonconforming packets

36 Bandwidth Broker Bandwidth Broker responsible for allocating and controlling bandwidth within a DS domain Users contact BB to negotiate SLA BB uses policy database to determine whether a user can request certain services BB determines whether resources are available to handle a request BB translates flow database into TCAs to setup packet classifiers & meters in edge routers BB allocates traffic to classes within domain BB negotiates agreements with other DS domains

37 Chapter 10 Advanced Network Architectures Network Interconnection Models

38 Network Interconnection Host 1 Host 2 A B ATM Network SONET Network Optical Network F G Network 1 C D E Network 3 IP Network IP Network Network 2 Server network (Network 2) provides transport service to Client networks (Network 1 & Network 3) Control Plane Issues: Server network & client networks may use different technologies What signaling is used and how are paths determined?

39 End-to-End Protocol Stacks Host 1 Host 2 Application Application TCP IP A IP B IP C D E F IP G IP TCP IP Data Link Data Link AAL ATM ATM ATM ATM AAL ATM Data Link Data Link PHY PHY PHY PHY PHY PHY PHY PHY PHY Network 1 Network 2 Network 3 Example: IP over ATM Hosts run TCP/IP Client networks are IP networks Server network is ATM

40 Approaches to Interconnection Overlay Model Independent control planes Client interacts with server network through User-Network Interface (UNI) Signal across UNI to request or release connections No network state information passes from server network to client network Secure & appropriate when networks run by different administrations Addressing method in client & server networks different Need ARP Client & server networks can evolve independently Peer-to-Peer Model Same control plane spans client & server network Client network knows state of server network e.g. OSPF information shared among networks RSVP implemented in all networks Client network can make routing decisions involving server network Higher efficiency Same addressing scheme in client and server networks No need for address resolution protocol Interdependence makes evolution more difficult

41 Overlay Example: IP over ATM MPS2 MPS1 MPS3 Host1 IP router Default path Host2 Edge device Client network ED ED Client network MPC1 MPC2 ATM switch Multiprotocol over ATM (MPOA) uses overlay approach Edge Device (ED) interposed between IP net & ATM net ED contains MPOA client (MPC) to set up & release VCs ATM has MPOA servers (MPS) for IP-ATM address resolution & IP packet forwarding

42 Overlay Example: IP over ATM MPS2 MPS1 MPS3 Host1 IP router Default path Host2 Edge device Client network ED ED Client network MPC1 MPC2 Short-cut path ATM switch First packets from Host 1 to Host 2 are routed using MPSs Ingress ED monitors packet flows When long-lived flow detected, MPD decides to set up VC Sends ARP request, which is routed along routed path Reply informs ingress ED of egress ED s ATM address VC set up & subsequent packet use ATM shortcut

43 Routing Scalability in Overlay Model ATM network Routers are interconnected with ATM VCs in full mesh Many router adjacencies N 2 for full mesh Routing algorithm becomes unnecessarily complex Many message exchanges when topology changes Routing could be simplified if ATM nodes used IP routing MPLS addresses this problem

44 Peer-to-Peer Example: IP + ATM Client IP A B C D IP ATM PHY y3 y4 y5 x x x x x y1 y2 Server network Client IP Nodes combine ATM switching & IP routing Initially packets are routed, hop by hop Packets flow along default VCs x When long-lived flow detected, node sets up shortcut Client establishes VC shortcut y1 Node A establishes VC shortcut y2 And so on

45 Chapter 10 Advanced Network Architectures MPLS

46 What is MPLS? IP LER IP L1 LSR IP L2 LSR IP L3 LER IP Multiprotocol Label Switching (MPLS) A set of protocols that enable MPLS networks Packets are assigned labels by edge routers (which perform longest-prefix match) Packets are forwarded along a Label-Switched Path (LSP) in the MPLS network using label switching LSPs can be created over multiple layer-2 links ATM, Ethernet, PPP, frame relay LSPs can support multiple layer-3 protocols IPv4, IPv6, and in others

47 Why MPLS? Labels enable fast forwarding But longest-prefix match is also fast Circuits are good (sometimes) Conventional IP routing selects one path, does not provide choice of route Label switching enables routing flexibility Traffic engineering: establish separate paths to meet different performance requirements of aggregated traffic flows Virtual Private Networks: establish tunnels between user nodes

48 Proposals Leading to MPLS IP Switching: IP+ATM proposed by IPSILON Traffic-driven label assignment: create & teardown shortcut paths according to flow activity Cell-Switch Router: proposed by Toshiba Traffic-driven label assignment Topology-driven label assignment: when node changes entries in IP routing table new ATM shortcuts are created & torn down Request-driven label assignment: signaling can request setting up of new labels to set up explicit paths Tag Switching: proposed by Cisco Multiprotocol tag or label: over multiple layer-2 technologies Label stacking: generalizes ATM 2-level hierarchy Topology-driven & request-driven label assignment ARIS (Aggregate Route-Based IP Switching): proposed by IBM Label merging: optimization of label usage

49 Separation of Forwardng & Control All proposals leading to MPLS separate forwarding and control Routing and signaling Labeled packets Control component Routing and signaling Routing tables Forwarding tables Switch fabric Forwarding component Routing and signaling Labeled packets Before MPLS: forwarding & control intertwined Transition to CIDR (control) meant forwarding had to change to longestprefix match With MPLS: forwarding & control are separate All forwarding done with label switching Different control schemes dictate creation of labels & label-switched paths Control & forwarding can evolve independently

50 Labels and Paths Ingress LSR Ingress LSR Ingress LSR Egress LSR Ingress LSR Ingress LSR MPLS domain Ingress LSR Label-switched paths (LSPs) are unidirectional LSPs can be: point-to-point tree rooted in egress node corresponds to shortest paths leading to a destination egress router

51 Forwarding Equivalence Class IP2 IP1 LER IP2 IP1 L1 L1 LSR IP2 IP1 L2 L2 LSR IP2 IP1 L3 L3 LER IP1 IP2 IP1 IP2 FEC: set of packets that are forwarded in the same manner Over the same path, with the same forwarding treatment Packets in an FEC have same next-hop router Packets in same FEC may have different network layer header Each FEC requires a single entry in the forwarding table Coarse Granularity FEC: packets for all networks whose destination address matches a given address prefix Fine Granularity FEC: packets that belong to a particular application running between a pair of computers

52 MPLS Labels ATM cell VPI/VCI PPP or LAN frame Layer 2 header MPLS header Layer 3 header Label Exp S TTL 20 bits 3 bits 1 bit 8 bits Labels can be encoded into VPI/VCI field of ATM header Shim header between layer 2 & layer 3 header (32 bits) 20-bit label + 1-bit hierarchical stack field + 8-bit TTL 3-bit experimental field (can be used to specity 8 DiffServ PHBs)

53 Label Stacking Swap and Push Swap Pop and Swap Push Pop A B C D E F G IP IP MPLS allows multiple labels to be stacked Ingress LSR performs label push (S=1 in label) Egress LSR performs label pop Intermediate LSRs can perform additional pushes & pops (S=0 in label) to create tunnels Above figure has tunnel between A & G; tunnel between B&F All flows in a tunnel share the same outer MPLS label

54 VC Merging Conserves Labels Non-VC merging A 6 E 5 B 3 7 F 6 C D Input cell streams In Out Output cell stream VC merging A B 5 6 E F C D Input cell streams In Out Output cell stream Packet 3 Packet 2 Packet 1 AAL5 End-of-Packet bit can be used to reassemble packets

55 Label Distribution Label Distribution Protocols distribute label bindings between LSRs upstream Label request for 10.5/16 downstream LSR 1 LSR 2 (10.5/16, 8) Downstream-on-Demand Mode LSR1 becomes aware LSR2 is next-hop in an FEC LSR1 requests a label from LSR2 for given FEC LSR2 checks that it has next-hop for FEC, responds with label

56 Label Distribution upstream downstream LSR 1 LSR 2 (10.5/16, 8) Downstream Unsolicited Mode LSR2 becomes aware of a next hop for an FEC LSR2 creates a label for the FEC and forwards it to LSR1 LSR2 can use this label if it finds that LSR2 is next-hop for that FEC

57 Independent vs. Order Label Distribution Control Ordered Label Distribution Control: LSR can distribute label if It is an egress LSR It has received FEC-label binding for that FEC from its next hop LER (10.5/16, 3) (10.5/16, 7) LSR (10.5/16, 9) (10.5/16, 8) LSR (10.5/16, 8) (10.5/16, 6) LER Independent Label Distribution Control: LSR independently binds FEC to label and distributes to its peers

58 Label Distribution Protocol LSR UDP Hello UDP Hello TCP open Initialization Label Request Label Mapping LSR Label Distribution Protocol (LDP), RFC 3036 Topology-driven assignment (routes specified by routing protocol) Hello messages over UDP TCP connection & negotiation (session parameters & label distribution option, label ranges, valid timers) Message exchange (label request/mapping/withdraw)

59 MPLS Routing Scalability ATM network LSR MPLS network LSR LSR LSR LSRs are visible to non-mpls routers Fewer router adjacencies Routing traffic & processing load reduced

60 RSVP-TE Congestion Underutilized Extensions to RSVP for traffic-engineered LSPs Request-driven label distribution to create explicit route LSPs Single node (usually ingress) determines route Enables traffic engineering RSVP Path message includes label request object to request label binding Explicit route object (ERO) RSVP Resv message includes label object

61 RSVP Path Message

62 RSVP Resv Message

63 MPLS Survivability IP routing recovers from faults in seconds to minutes SONET recovers in 50 ms MPLS targets in-between path recovery times Basic approaches: Restoration: slower, but less bandwidth overhead Protection: faster, but more protection bandwidth Repair methods: Global repair: node that performs recovery (usually ingress node) may be far from fault, depends on failure notification message Local repair: local node performs recovery (usually upstream from fault); does not require failure notification

64 MPLS Restoration No protection bandwidth allocated prior to fault 1 Normal operation Failure occurs and is detected 8 New paths are established after a failure occurs Traffic is rerouted onto the new paths Alternate path is established, and traffic is re-routed

65 MPLS Protection Working path Protection path Traffic carried on working path Failure on working path is detected Protection paths are setup as backups for working paths 1+1: working path has dedicated protection path 1:1: working path shares protection path Protection paths selected so that they are disjoint from working path Faster recovery than restoration Traffic is switched to the protection path

66 Generalized MPLS MPLS: Connection-oriented Leverages IP routing protocols, with TE extensions, to provide means for selecting good paths Provides signaling for establishing paths With appropriate extensions, Generalized MPLS can provide the control plane for other networks: SONET networks that provide TDM connections WDM networks that provide end-to-end optical wavelength connection Optical networks that provide end-to-end optical fiber path

67 Hierarchical LSPs Virtual circuit TDM circuit Lightpath TDM circuit Virtual circuit A B C D E F G H I J TDM switch Lambda cross-connect LSR GMPLS allows node with multiple switching technologies to be controlled by one control component Notion of label generalized: TDM slot, WDM wavelength, optical fiber port LSP Hierarchy extended to generalized labels MPLS LSP over SONET circuit over wavelength path over fiber

68 GMPLS Associated Protocols OSPF Extensions Disseminate link state for optical & SONET links Signal quality, protection capability, link bundling, interface types available Link Bundling DWDM causes optical fiber to appear as large number of links & hence routing adjacencies Link bundling aggregates parallel links so single adjacency required Link Management Protocol (LMP) New protocol that automates management of component links Provides separate control channel so data channels can be transparent, e.g. as in a lightpath that carries only data

69 Chapter 10 Advanced Network Architectures Multimedia Networking

70 Multimedia Internet Applications Remote Local Interactive Continuous Playback Streaming Local Playback Storage Download

71 Multimedia Application Types Storage/Download Capturing/or downloading multimedia sequences to/from storage devices Local playback Playback of multimedia sequences from a local disk Streaming On-line playback of multimedia sequences stored on remote servers May pause during playback to account for network congestion Continuous playback Continuous on-line playback of remote multimedia sequences No pausing allowed Interactive Multi-participant interactive multimedia sessions

72 Multimedia Applications cont d Application Type Storage Download Example Video Production Off-line video editing Application QoS Requirements Bandwidth Delay Jitter Errors / Losses High Medium-Hi Medium Medium-Hi Medium None High None Local Playback DVD Playback N/A N/A N/A None Streaming Real Audio/ Real Video Low - high High Medium Medium Continuous Playback Live Broadcast High Medium Low Medium Interactive Audio/Video Conference Low Low Low High

73 Components of Multimedia Applications System components Capture and playback systems Encoders and Decoders File storage format and storage devices Real-time transport protocol (RTP) Real-time Streaming Protocol (RTSP) Session Description Protocol (SDP) Session Initiation/Announcements protocols (SIP/SAP) H.323 Multimedia Communications

74 Compatibility Requirements Network Real-time protocol Real-time protocol Encoders Decoders Compatible CODEC Streaming protocol File Format Storage

75 Multimedia protocol stack MGCP/Megaco H.323 SDP SIP Signaling Quality of Service Reservation Measurement RTSP RSVP RTCP TCP UDP IPv4, IPv6 Media Transport H.261, MPEG PPP AAL3/4 AAL5 PPP RTP Application daemon kernel Sonet ATM Ethernet V.34

76 Chapter 10 Advanced Network Architectures Timing Recovery (from Chapter 5)

77 Timing Recovery for Synchronous Services Synchronous source sends periodic information blocks Network output not periodic Network Applications that involve voice, audio, or video can generate a synchronous information stream Information carried by equally-spaced fixed-length packets Network multiplexing & switching introduces random delays Packets experience variable transfer delay Jitter (variation in interpacket arrival times) also introduced Timing recovery re-establishes the synchronous nature of the stream

78 Introduce Playout Buffer Packet Arrivals Packet Arrivals Playout Buffer Packet Playout Packet Playout Sequence numbers help order packets T max Delay first packet by maximum network delay All other packets arrive with less delay Playout packet uniformly thereafter

79 Playout clock must be synchronized to transmitter clock Time Send times Arrival times Playout times Receiver too slow; buffer fills and overflows T playout time Time Receiver too fast buffer starvation Time Receiver speed just right Many late packets T playout time T playout time

80 Clock Recovery Timestamps inserted in packet payloads indicate when info was produced t 4 t 3 t 2 t 1 Timestamps + - Buffer for information blocks Error signal Add Smoothing filter Counter Adjust frequency Playout command Recovered clock Counter attempts to replicate transmitter clock Frequency of counter is adjusted according to arriving timestamps Jitter introduced by network causes fluctuations in buffer & in local clock

81 Synchronization to a Common Clock Transmitter Receiver f s M Network M f r M = # ticks in local clock In time that net clock does N ticks f n /f s =N/M N ticks f n N ticks Δf=f n -f s =f n -(M/N)f n f r =f n -Δf Network clock Clock recovery simple if a common clock is available to transmitter & receiver E.g. SONET network clock; Global Positioning System (GPS) Transmitter sends Δf of its frequency & network frequency Receiver adjusts network frequency by Δf Packet delay jitter can be removed completely

82 Chapter 10 Advanced Network Architectures Real-Time Transport Protocol RTCP RTSP

83 Real-Time Protocol RTP (RFC 1889) designed to support realtime applications such as voice, audio, video RTP provides means to carry: Type of information source Sequence numbers Timestamps Actual timing recovery must be done by higher layer protocol MPEG2 for video, MP3 for audio

84 RTP Scenarios & Terminology Chair of conference obtains IP multicast address & pair of consecutive UDP port #s Even port #: audio Odd port # for RTCP stream Each media sent on a separate RTP session Fixed-length RTP PDUs sent during session Each RTP multicasts periodic receiver reports on RTCP port Mixers and Translators

85 RTP Packet Format V P X CC M Payload Type Sequence Number Version (2) Padding flag Time Stamp SSRC Identifier CSRC Identifier Extension Header Flag Contributing Source Count (# CSRC IDs) Marker (significant events, e.g. frame boundaries)

86 RTP Packet Format V P X CC M Payload Type Sequence Number Time Stamp SSRC Identifier CSRC Identifier Payload Type: e.g. PCM, MPEG2, Sequence Number: detect packet loss Timestamp: sampling instant of first byte Synchronization Source: ID for synch source CSRC List: contributing sources to payload

87 RTP Packet

88 RTP Control Protocol (RTCP) RTP companion protocol Monitors quality of service at receivers Conveys monitored info to senders Canonical Name CNAME for each participant RTCP Packets Sender Report Packet Receiver Report Packet Source Description (SDES) BYE: end of participation by sender APP: application specific functions

89 RTCP Packet

90 Real Time Streaming Protocol (RTSP) RFC 2326 VCR-like user control of display: play, rewind, fast forward, pause, resume, etc One connection for control messages One connection for media stream TCP or UDP can be used for the control channel

91 RTSP Operations Web browser HTTP GET Presentation desc. SETUP Web server Media player PLAY Media stream Media server PAUSE TEARDOWN Client Server

92 Chapter 10 Advanced Network Architectures Session Control Protocols SIP

93 Session Initiation Protocol Session: association involving exchange of data between Internet end systems Internet telephone call; multimedia videoconference; instant messaging; event notification Session Initiation Protocol Setting up, maintaining, terminating session People & media devices Multicast or mesh of unicast connections Support for user mobility Over UDP or TCP

94 SIP Protocol Text-based client-server protocol with syntax similar to HTTP Transaction: client request /server(s) response(s) Basic signaling through transactions SIP Request: method invoked INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER INVITE & ACK used to initiate calls

95 registrar INVITE sip: c= IN IPv m=audio RTP/AVP 0 (2) (3) INVITE sip: tom@ c= IN IPv m=audio RTP/AVP 0 (5) ringing (1) (4) (7) SIP/ OK proxy (6) SIP/ OK (8) ACK (9) Media flow

96 SIP System Components User Agents: software in end system that acts on behalf of a human user User Agent Client: to initiate a call User Agent Server: to answer a call Network Servers: call routing to establish a call Proxy Server: receives request, determines server to send it to, and forwards request; Response flows in reverse direction Redirect Server: returns message telling client address of next server Registrar: registrations on current user locations

97 INVITE REQUEST INVITE request to UAS of desired user Use name, e.g. address, telephone # Usually IP address or hostname not known As message passes a SIP device, IP address of device attached to VIA header Used for reverse path Command Sequence header Request method and sequence number Content type: default Session Description Protocol (SDP)

98 Response UAC sends INVITE request to network server Request proxied/redirected until server found that knows IP address of user Response message contains: Same Call ID; CSeq; To/From Reach address to send transactions directly to UAS Information about media content

99 SIP Ethereal Capture user1 calls user2 using Helmsman User Agent This User Agent is available at

100 INVITE: User1 sending out Invite Request for User2 Description of Invite Packet: Header contains information about the call. E.g.. To, From, Via.

101 TRYING: User1 trying to connect to User2 Header Description of Trying Packet:

102 RINGING: Packet Description: Connection has been established with User2, waiting for User2 to answer the call.

103 OK and ACK : Connection has been established and user1 sends out a OK packet User1 sends an ACK packet to user2 Packet Description for OK :

104 Packet Description for ACK :

105 BYE: User2 wants to disconnect, sends a BYE packet User2 is trying to disconnect and hence sends Trying Packet Packet Description for BYE: OK is sent by User2 once call is successfully disconnected

106 Chapter 10 Advanced Network Architectures Session Control Protocols H.323 Communications Systems

107 H.323 Systems Support for real-time multimedia communications on LANs & packet networks H.323 provides call control, multimedia management, bandwidth management, interfaces to other networks H.323 terminals carry voice, audio, video, data, or combination Gateways handle signaling messages between packet network & other networks Gatekeeper handles call control inside H.323 net Multipoint control unit combine media streams

108 Gatekeeper MCU Telephone Gateway IP network Public Telephone Network H.323 Terminal H.323 Terminal

109 Scope of H.323 Microphone Speakers Camera, Display Audio Codec Video Codec Receive Path Delay Data Equipment System Control H.225 Layer LAN I/F System Control User I/F H.245 Control Call Control RAS Control

110 H.323 Protocols H.225: call control within H.323 net RTP/RTCP used for audio/video streams H.245: control channel to set up logical channels RAS: registration, admission control, bandwidth management RSVP Resource Reservation Protocol: allows user to request a specific amount of bandwidth

111 Typical H.323 Stack H.323 Multimedia Applications, User Interface Data Applications Media Control Terminal Control and Management V.150 T.120 T.38 Audio Codecs G.711 G G Video Codecs H.261 H.263 H RTCP H Call Signaling H.245 H RAS RTP UDP TCP TCP/UDP UDP TCP/UDP TCP UDP IP

112 Basic Call Setup Signaling H Setup Call Proceeding Progress Alerting Optional GW Connect CONNECTED GW Release Complete

113 Call Setup Capture TCP Control Packets No. Time Source Destination Protocol Info TCP 1748 > 1720 [SYN] Seq= Ack=0 Win=16384 Len= TCP 1720 > 1748 [SYN, ACK] Seq= Ack= Win=17520 Len= TCP 1748 > 1720 [ACK] Seq= Ack= Win=17520 Len= H CS: Setup-UUIE TCP [Desegmented TCP] TCP 1748 > 1720 [ACK] Seq= Ack= Win=17516 Len= H CS: Alerting-UUIE TCP 1748 > 1720 [ACK] Seq= Ack= Win=17477 Len= TCP [Desegmented TCP] TCP 1748 > 1720 [ACK] Seq= Ack= Win=17473 Len= H CS: Connect-UUIE TCP 1749 > 1862 [SYN] Seq= Ack=0 Win=16384 Len= TCP 1862 > 1749 [SYN, ACK] Seq= Ack= Win=17520 Len= TCP 1749 > 1862 [ACK] Seq= Ack= Win=17520 Len= TCP [Desegmented TCP] H setup Alerting Connecting Negotiating Channel Usage TCP [Desegmented TCP] H.245 TerminalCapabilitySet MasterSlaveDetermination H.245 TerminalCapabilitySet MasterSlaveDetermination TCP [Desegmented TCP] TCP [Desegmented TCP] H.245 TerminalCapabilitySetAck MasterSlaveDeterminationAck H.245 TerminalCapabilitySetAck MasterSlaveDeterminationAck TCP [Desegmented TCP] H.245 OpenLogicalChannel OpenLogicalChannel OpenLogicalChannel TCP 1749 > 1862 [ACK] Seq= Ack= Win=16900 Len= RTCP Receiver Report RTCP Receiver Report RSVP PATH Message. SESSION: IPv4, Destination , Protocol 17, Port SENDER TEMPLATE: IPv4, Sender , Port RSVP RESV Message. SESSION: IPv4, Destination , Protocol 17, Port Requesting Bandwidth

114 Data Transfer Capture No. Time Source Destination Protocol Info TCP 1862 > 1749 [ACK] Seq= Ack= Win=17004 Len= H.245 OpenLogicalChannelReject OpenLogicalChannelAck OpenLogicalChannelAck MiscellaneousCommand MiscellaneousCommand OpenLogicalChannelConfirm RTP Payload type=itu-t H.263, SSRC= , Seq=12977, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=12978, Time= TCP 1862 > 1749 [ACK] Seq= Ack= Win=16920 Len= TCP 1503 > 1752 [ACK] Seq= Ack= Win=17315 Len= RTP Payload type=itu-t H.263, SSRC= , Seq=12980, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=12981, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=12982, Time= , Mark TCP 1753 > 1503 [PSH, ACK] Seq= Ack= Win=17520 Len= TCP 1503 > 1753 [PSH, ACK] Seq= Ack= Win=17495 Len= RTP Payload type=itu-t H.263, SSRC= , Seq=12983, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=12984, Time= , Mark TCP 1753 > 1503 [ACK] Seq= Ack= Win=17499 Len= TCP 1749 > 1862 [ACK] Seq= Ack= Win=16896 Len= H.245 MiscellaneousCommand RTP Payload type=itu-t H.263, SSRC= , Seq=32093, Time= , Mark TCP [Desegmented TCP] TCP 1753 > 1503 [PSH, ACK] Seq= Ack= Win=17499 Len=268 RTP video H.263 Packet More Control RTP Audio G TCP 1503 > 1753 [PSH, ACK] Seq= Ack= Win=17227 Len=106 Time=51984, Mark RTP Payload type=itu-t G.723, SSRC= , Seq=32091, Time= TCP 1753 > 1503 [ACK] Seq= Ack= Win=17331 Len= TCP 1754 > 1503 [ACK] Seq= Ack= Win=17168 Len= RTP Payload type=itu-t G.723, SSRC= , Seq=32092, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=12996, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=12997, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=32109, Time= , Mark RTP Payload type=itu-t G.723, SSRC= , Seq=32093, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=12999, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=13000, Time= RTP Payload type=itu-t H.263, SSRC= , Seq=13001, Time= , Mark

115 Media Gateway Control Protocols Enable simple terminal equipment (i.e. telephone) to connect to Internet for IP telephone service Two components: Media Gateway: performs media format conversion between telephone & Internet Residential Gateway: interacts between telephone and call agents in Internet Call agents interact with SS7 signaling network to setup calls Call agents use Media Gateway Control Protocol