Download Protocols and Quality of Service

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Distributed firewall wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

AppleTalk 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

IEEE 1355 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

Routing in delay-tolerant networking wikipedia , lookup

Quality of service wikipedia , lookup

Transcript
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
