Presentation is loading. Please wait.

Presentation is loading. Please wait.

Internet Protocols for Multimedia DS VT-00 Jerry Eriksson.

Similar presentations

Presentation on theme: "Internet Protocols for Multimedia DS VT-00 Jerry Eriksson."— Presentation transcript:

1 Internet Protocols for Multimedia DS VT-00 Jerry Eriksson

2 Multimedia Networking zAnimation, voice and video - not only text zdistance learning, distributed simulation, distribute work groups zMultimedia networks may replace telephone, television, etc zChallenges - Build hardware and software infrastructure and applications to support multimedia

3 Outline zReal-time challenges zReal-time protocols yRTP, RTCP, RTSP zQoS yDefinitions yGoals z Traffic management architectures yIntServ, Diffserv, RSVP z VoIP yH.323, SIP

4 Real-time Challenges zHigh bandwidth zAudio and video must be played back at the rate they were sampled (voice may be even more difficult) zMultimedia data streams are bursty

5 Internet zPrimary reason: Platform for most networking activities zIntegrated data and multimedia service over a single network (investments) zNot suitable for real-time traffic yOffers only best-effort quality

6 Problems to solve zProvide enough bandwidth zProvide multicast to reduce traffic zProvide protocols that handle that that care of timing issues yDelay, Jitter z QoS- guarantee quality yReserve resource on the internet yTransport protocols z Presentation of the multimedia data (WAP, Voice) z Charging and policing mechaninsm

7 QoS Definitions zQos is a set of technologies that enables network administrators to manage the effects of congestion on application traffic by using network resources optimally zor, allocate different resourses for different data flows

8 QoS classes zBest-effort - No gurantees at all zSoft QoS - differentiated guarantess zHard QoS - full guarantees

9 RTP- Real-time transport protocols zIp-based protocol providing ytime-reconstruction yloss detection ysecurity ycontent identification zDesigned primarily for multicast of real- time data (also unicast, simplex, duplex)

10 RTP - development zDecember 1992, Henning Schulzrinne, GMD Berlin, published RPT version 1 zProposed (version 2) as standard November,1995 zNetscape and Microsoft uses RTP

11 How does RTP works zTimestamping - most important information for real-time applications. yThe sender timestamp according to the instant the first octet in the packet was sampled. yThe receiver uses timestamp to reconstruct the original timing yAlso used for synchronize different streams; audio an video in MPEG. ( Application level responsible for the actual synchronization)

12 How does RTP work zPayload type identifier yspecifies the payload format as well as encoding/compression schemes yThe application then knows how to interpret the payload zSource identification yAudio conference

13 Where is RPT reside zRPT is typically run on top of UDP yUses UDP’s multiplexing and checksum functions zRPT is usually implemented within the application (Lost packets and congestion control have to be implemented in the application level

14 RTCP - Real Time Control Protocol zDesigned to work together with RTP zIn an RTP session the participants periodically send RTCP packet to give feedback on the quailty of the data. zComparable to flow and congestion control of other transport protocols. zRTP produces sender and receivers reports; statistics and packet counts

15 RTCT packet types zRecevier reports: feedback of data delivery yPacket lost, jitter, timestamps zSender report: yIntermedia synchronization, number of bytes sent, packet counters zSDES, BYE, APP

16 RTCP provides the following services zQoS monitoring and congestion control yPrimary function: QoS feedback to the application yThe sender can adjust its transmission yThe receiver can determine if the congestion is local, regional, or global yNetwork managers can evaluate the network performance for multicast distribution

17 RTCP provides the following services (Cont) zSource identification zinter-media synchronization zcontrol information scaling yLimit control traffic (most 5 % of the overall session traffic)

18 RTP/RTCP features zProvides yend-to-end real-time data delivery (functionality and control mechanisms) ytimestamps sequences numbering (up to the application to use it) zUses UDP z Provides not ytimely delivery (needs lower layer reservations) yany form of reliability or flow/congestion control (RTCP) z Not complete - new payload format

19 What is Streaming? zStreaming breaks data into packets; real- time data through the transmission, decompressing just like a water stream. yA client can play the first packet, decompress the second, while receiving the third. yThe user can start enjoying the multimedia without waiting to the end of the transmission

20 RTSP - real time streaming protocol zClient-server multimedia presentation protocol to enable controlled delivery yprovides ”vcr”-style remote control functionality of streamings over IP. yRTSP is an application-level protocol designed to work with RTP (and RSVP) to provide a complete streaming service over internet yIt provides means for choosing channels (UDP etc) and delivery mechanisms (RTP) zDeveloped by RealNetworks, netscape, and columbia university (still an internet draft)

21 RTSP operations and methods zRTSP establish and controls streams zA media server provides playback or recording services zA client requests continues media data from the media server zRTSP is the network is the ”network remote control” between the server and the client

22 RTSP provides zRetrieval of media from media server zInvitation of a media server to a conference zAdding media to an existing presentation zSimilar services on streamed audio and video, just as HTTP does for text and graphics

23 HTTP/RTSP differences zHTTP stateless protocol; an RTSP server has to maintain ”session states” zHTTP is asymmetric; in RTSP both client and server can issue requests zIt uses URL, like HTTP

24 Resources reservation and prioriations zAny QoS better than best-effort. yRouting delays and congestion losses zReal-time traffic

25 Now IP QoS Networking - Integrated services zDefined by an IETF working group to be a key- stone zIS was developed to optimize network and resource utilization which require QoS. zDivided traffic between into different QoS classes. zAn internet router must be able to provide an appriopriate QoS for each flow. (according to a service model)

26 Router function: Traffic control zPacket scheduler manages forwarding of different packet streams. yService class, queue management, algorithms yPolice and shape traffic ymust be implemented at the point where the packets are queued.

27 Router function: Traffic control zPacket classifier indentifies packets of an IP flow in hosts and routers that will receive a certian level of service. yEach packet is mapped by the classifier into a specific class. (same class, same treatment) yThe choice of class is based upon the source and destination, and port number in packet header

28 Admission control zDecision algorithms that a router uses to determine if there are routing resources to accept the requested QoS for a flow yIf the flow is accepted; the packet classifier and packet scheduler reservs the requested Qos for this flow. zChecks user authentification zWill play an important role for charging

29 IntServ (cont) zCommunicates with RSVP to create and maintain flow-specific states in the endpoint hosts and in routers along the path of a flow zRSVP/Intserv are complementary zNot suitable for high volume traffic (speech)

30 Differentiated services zIETF working group (draft, no RFC) zSimplify scheduling and classification using the priority bits in the IP header. zPacket flow must be marked according to SLA; Servive Level Agreements at the edge of the network zThe ISP must assures that a user gets his requsted QoS. zImproves scalability greatly.

31 Mechanisms needed zSetting bits in DS at the network edges and administrative boundaries zUsing those bits to determine how packets are treated by routers inside the network zDS architecture is currently asymmetric; yon-going research for symmetric architecture

32 Diffserv architecture zStatic and long-term yNot need to set up QoS reservation for specific data packets yDS routing example (it is not that easy) zHandle aggregate traffic (not per- conversation) yrequire significantly less sates and processing power than per-conversation.

33 RSVP - reservation protocol zInternet control protocol - not routing protocol zRuns on top of IP and UDP zKey concepts: flows and reservations zApplies for a specific flow of data packets on a specific path. Each flow has a flow descritpor. zBoth unicast and multicast. zDoesn’t understand the content of the flow descriptor

34 RSVP - reservation protocol zSimplex protocol; reservation is done in one direction; zReceiver-initiated. The sender sends QoS wanted to the receiver which sends an RSVP message back to the sender. zThe sender does not need to know the capabilities along the path or at the receiver

35 RSVP - reservation protocol zThe RVSP daemon ychecks admission and policy control. If either fails the RSVP returns error ysets parameters in the packet classifier and packet scheduler ycommunicates with the routing process to determine path

36 Reservation messages PATH and RESV; zPATH messages are periodically from the sender to the receiver and contains a flow spec ydata format, source address, source port ytraffic characteristics zRECV is generated by the receiver and contains flow spec and filter spec yfollows the exact reverse path setting up reservations for one or or more senders at each node

37 Intserv drawbacks zOnly implemented for UNIX platforms zMust be implemented on each node from ’end’-end’ - not scalable zNo secure policy mechanisms zProtecting multimedia - most traffic still are non-multimedia zClose to death, September 1997

38 RSVP renaissance today zAvailability of RSVP signaling on a large number of hosts (Windows 2000) zUse Diffserv as well. zAvailability of policy components and products from many vendors. zRecent work on RSVP signalling handle non-multimedia much better

39 Top-down provisioning zLow overhead and aggregate traffic handling. Bilateral agreements zDifficulty learning the classification criteria that should be configured to specify specific traffic zCannot offer high-quality guarantees required for multimedia applications, unless the network is overdimensioned zTop-down provisioning to coordinate traffic handling along a specific path

40 Youram Bernet The combination of RSVP signaling with aggregate traffic handling mechanisms is able to address the deficiencies of the exclusively top-down provisioned approach without incurring the scalability problems of classical RSVP/intserv usage

41 Enhancing efficiency within diffserv Network zDiffserv provider may dedicate resources support SLA zStatistical multiplexing zDynamic signalling at certain key points; ydynamic admission control

42 Yoram Bernet When managing a network to offer QoS, the manager is faced with certain trade-offs. A given network and its QoS mechanisms can offer a certain quality of guarantees at a certain level of efficiency.

43 Quality/efficiency zTrade-off; An on-going debate yOver-provision the network;Efficiency decreases yLower the resourses;Decrease QoS. zIt is impossible to aviod the overhead of more sophisticated QoS mechanisms unless on is willing to compromise in the trade-off just mentioned

44 Yoram Bernet, QoS expert Microsoft Despite the astounding rate at which netork capacity is increasing, we find ourselves contending with congested networks today and can expect ot do be doing so for the foreseeable future

45 Why IP telephony (VoIP) zRegarded far too unreliable for mass market, but now reliability and quality have quickly improved zAdvantages: Cheaper yNo inter-connect charges; 6-8 kb/s (packet) vs 64kb/s yRegulation costs zNew value-added features; conferencing zSingle network

46 Internet telephony standards zStill immature; latency major issue zITU-T: H.323 (set of protocols) zSIP used to initate a session between users. Simple, cheap. Limited, but popular

47 H.323 Standard architectures zProtocol stack (fig. 9-4) y Audio, video over RTP/RTCP/UDP yData over TCP ySystem Control over TCP

48 H.323 Architecture zComponents yGateway yGatekeeper yMCU zInterwork with SS7

49 Signalling within H.323 zH.323 uses a logicla channel on the LAN zRAS (Registration, admission and status) yGatekeeper Discovery yEndpoint registration yCall management yAdmission procedures yand several more

50 VoIPoW (over wireless (wcdma)) zRather important reserach in Ericsson zChallenge cube

Download ppt "Internet Protocols for Multimedia DS VT-00 Jerry Eriksson."

Similar presentations

Ads by Google