* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Protocols and Quality of Service
Distributed firewall wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Extensible Authentication Protocol wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Deep packet inspection wikipedia , lookup
Computer network wikipedia , lookup
Airborne Networking wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Internet protocol suite wikipedia , lookup
Communication protocol wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Protocols and Quality of Service CP4022 – Lecture 4 Options Use of techniques that mitigate the problem e.g. multicasting for broadcasts Use of Protocols that can deliver guaranteed capacity (and QoS). Use of Resource broker architectures that dynamically allocate resources Protocols Current protocols are mainly not optimised for use in broadcast environments Use of multicasting can help Reservation protocols will improve QoS Home-based users (in particular) are reliant on many outside factors to provide good QoS. Multicasting Depends on multicast routers (see RFC 1112) Routers maintain multicast groups and deliver messages to individual hosts Cuts down on duplication of messages except for low-use wide-spread connections Multicasting is useful if audience is grouped Reservation protocol RSVP RSVP (RFC 2205) Uses control messages to reserve capacity along a TCP connection Works with TCP/IP - IPv4 and v6 RSVP provides transparent operation through routers that do not support it. RSVP makes resource reservations for both unicast and manyto-many multicast applications, adapting dynamically to changing group membership as well as to changing routes RSVP is receiver-oriented, i.e., the receiver of a data flow initiates and maintains the resource reservation used for that flow. RSVP characteristics summary RSVP is simplex, i.e., it makes reservations for unidirectional data flows. RSVP maintains "soft" state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes. RSVP is not a routing protocol but depends upon present and future routing protocols. RSVP transports and maintains traffic control and policy control parameters that are opaque to RSVP. RSVP provides several reservation models or "styles" to fit a variety of applications. Resource brokers Allows monitoring of connection and tele-service configuration to deliver QOS. An example of a tele-service is a broadcast video stream (and associated viewer) Dynamic Resource broking is not necessary for acceptable QOS --but can help. Resource issues In QoS-able networks If resource reservation fails User needs to initiate another request with reduced requirements. Dynamic resource allocation would reduce call set-up by placing the negotiation process inside the network Standards Two standards for session control ITU H.323 – Packet-Based Multimedia Communications Systems IETF Session initiation Protocol (RFC 2543) from the Multi-Party Multimedia session control working group. SIP and related protocols SIP is designed as part of the overall IETF multimedia data and control architecture incorporating RSVP (RFC 2205) for reserving network resources, the real-time transport protocol (RTP) (RFC 1889) for transporting real-time data and providing QOS feedback, the real-time streaming protocol (RTSP) (RFC 2326) for controlling delivery of streaming media, the session announcement protocol (SAP) for advertising multimedia sessions via multicast the session description protocol (SDP) (RFC 2327) for describing multimedia sessions. The functionality and operation of SIP does not depend on any of these protocols. Tele-service description(TD) Formal descriptions of services are required to enable the adaptation process. Descriptions contain rules that express relationships among participants and their media sessions Broker uses the TD to validate, evaluate and assemble a service Tele-service validation Validation extracts required parameters from the configuration description and substitutes them into the rule expressions Rules relate participants and media streams in various configurations. If these are then true the tele-service is valid. This prevents meaningless configurations that would waste resources Tele-service evaluation Evaluation ranks different configurations in different views. For example User preference view Network View Terminal resource load Cost view What the network can provide Terminal view What the user wants How expensive is it for the user Quality view Media session qualities Tele-service assembly and resource reservation Generation of a configuration based on the tele-service description One is chosen that most closely matches the view required. Resources are reserved by converting the configuration into individual QoS connections which are then requested in the network. Algorithms for Teleservice configuration Bottom-up Top-down Bottom up Top down Summary Better Quality of service can depend on many factors. Some solutions are: Real time protocols Session control Protocols Multicasting Resource broking Time will tell which methods survive