INTRODUCTION
RSVP is a resource reservation setup protocol designed for an integrated services Internet. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path.
RSVP requests resources for simplex flows i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path.
RSVP is not itself a routing protocol. RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded. RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing.
INTERNET
One of the greatest things about the Internet is that nobody really owns it. It is a global collection of networks, both big and small. These networks connect together in many different ways to form the single entity that we know as the Internet. In fact, the very name comes from this idea of interconnected networks.
Fig 2.1 Shows how your computer connects with others
Since its beginning in 1969, the Internet has grown from four host computer systems to tens of millions. However, just because nobody owns the Internet, it doesn't mean it is not monitored and maintained in different ways. The Internet Society, a non-profit group established in 1992, oversees the formation of the policies and protocols that define how we use and interact with the Internet.
COMPUTER HIERARCHY NETWORK
Every computer that is connected to the Internet is part of a network, even the one in your home. For example, you may use a modem and dial a local number to connect to an Internet Service Provider (ISP). At work, you may be part of a local area network (LAN), but you most likely still connect to the Internet using an ISP that your company has contracted with. When you connect to your ISP, you become part of their network. The ISP may then connect to a larger network and become part of their network. The Internet is simply a network of networks.
Fig 3.1 Shows how your computer becomes a part of a network
when you connect to the internet
Most large communications companies have their own dedicated backbones connecting various regions. In each region, the company has a Point of Presence (POP). The POP is a place for local users to access the company's network, often through a local phone number or dedicated line. The amazing thing here is that there is no overall controlling
network. Instead, there are several high-level networks connecting to each other through Network Access Points or NAPs
THE FUNCTION OF AN INTERNET ROUTER
All of these networks rely on NAPs, backbones and routers to talk to each other. What is incredible about this process is that a message can leave one computer and travel halfway across the world through several different networks and arrive at another computer in a fraction of a second.
Fig 3.1.1 Shows the mechanism of Internet using Router
The routers determine where to send information from one computer to another. Routers are specialized computers that send your messages and those of every other Internet user speeding to their destinations along thousands of pathways.
A router has two separate, but related, jobs:
It ensures that information doesn't go where it's not needed. This is crucial for keeping large volumes of data from clogging the connections of "innocent bystanders".
It makes sure that information does make it to the intended destination.
In performing these two jobs, a router is extremely useful in dealing with two separate computer networks. It joins the two networks, passing information from one to the other. It also protects the networks from one another, preventing the traffic on one from unnecessarily spilling over to the other. Regardless of how many networks are attached, the basic operation and function of the router remains the same. Since the Internet is one huge network made up of tens of thousands of smaller networks, its use of routers is an absolute necessity.
INTERNET PROTOCOL : IP ADDRESS
Every machine on the Internet has a unique identifying number, called an IP Address. The IP stands for Internet Protocol, which is the language that computers use to communicate over the Internet. A protocol is the pre-defined way that someone who wants to use a service talks with that service. The "someone" could be a person, but more often it is a computer program like a Web browser.
A typical IP address looks like this: 216.27.61.137
To make it easier for us humans to remember, IP addresses are normally expressed in decimal format as a dotted decimal number like the one above. But computers communicate in binary.
Look at the same IP address in binary: 11011000.00011011.00111101.10001001
The four numbers in an IP address are called octets, because they each have eight positions when viewed in binary form. If you add all the positions together you get 32, which is why IP addresses are considered 32-bit numbers. Since each of the eight positions can have two different states (1 or 0), the total number of possible combinations per octet is 28 or 256. So each octet can contain any value between zero and 255. Combine the four octets and you get 232 or a possible 4,294,967,296 unique values.
Out of the almost 4.3 billion possible combinations, certain values are restricted from use as typical IP addresses. For example, the IP address 0.0.0.0 is reserved for the default network and the address 255.255.255.255 is used for broadcasts.The octets serve a purpose other than simply separating the numbers. They are used to create classes of IP addresses that can be assigned to a particular business, government or other entity based on size and need. The octets are split into two sections: Net and Host. The Net section always contains the first octet. It is used to identify the network that a computer belongs to. Host (sometimes referred to as Node) identifies the actual computer on the network. The Host section always contains the last octet. There are five IP classes plus certain special addresses.
QUALITY OF SERVICE (QoS)
Quality of Service is the most demanding part from Internet. Users and customers have to be more demanding in the kind of service they receive. They should demand quality. 100% availability, bandwidth adherence to the signed contracts, low latency, low jittery and low losses. Arrangements promised some type of service and customers are paying for it; nothing less. This way ISPs (internet service providers) will be forced to improve their installations, and to take into account the tiny details required to lend the best service. Also, monitoring and measurement devices must be provided by ISPs to users, for them to be sure that they are really receiving the desired QoS level, and in case of not, they can find the responsible ISP, if there are multiple ISPs involved in providing the service.
ISPs have to abandon the convenient approach to endorse the infamous "best effort" policy. Because "best effort" really means not effort at all. ISPs should pay attention to the "Quality of Service" problem. They have to study and invest time researching about QoS problems and tools available to deal with them. They have to listen to their customers, and when claims imply a QoS problem, measures must be taken and responsibility must be well established. Each involved ISP must use the test data obtained to redesign and optimize its own network.
To weigh "Quality of Service" in networks or internet services, we have to look for some mechanism to measure this "quality", for having a way to compare services provided by different systems and/or Internet Service Providers (ISP).To measure network or Internet "Quality of Service", we are going to use these methods of measurement:
- Availability
- Bandwidth
- Latency
- Jitter
- Losses
RSVP
Resource Reservation Protocol has been designed to provide end-to-end quality of service to Internet data flows. Typically all IP traffic on the Internet is delivered on a best-effort basis. This delivery method does not address the requirements of multimedia applications such as videoconferencing, real-time IP multicasting and Internet telephony. Resource Reservation Protocol (RSVP) is an effort to address the performance needs of such applications.
RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. Resource Reservation Protocol has been designed to provide end-to-end quality of service to Internet data flows.
RSVP is a signaling and control protocol that doesn't carry application data. It operates on top of IP in the transport layer of the Open Systems Interconnection (OSI) protocol stack.
In short RSVP has the following attributes:
RSVP makes resource reservations for both unicast and many-to-many multicast applications, adapting dynamically to changing group membership as well as to changing routes.
RSVP is simplex, i.e., it makes reservations for unidirectional data flows.
RSVP is receiver-oriented, i.e., the receiver of a data flow initiates and maintains the resource reservation used for that flow.
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" (defined below) to fit a variety of applications.
RSVP provides transparent operation through routers that do not support it.
RSVP supports both IPv4 and IPv6.
DATA FLOWS
RSVP defines a "session" to be a data flow with a particular destination and transport-layer protocol. RSVP treats each session independently, and this document often omits the implied qualification "for the same session".
An RSVP session is defined by the triple: (DestAddress, ProtocolId, DstPort). Here DestAddress, the IP destination address of the data packets, may be a unicast or multicast address. Protocol Id is the IP protocol ID. The optional DstPort parameter is a "generalized destination port" i.e, some further demultiplexing point in the transport or application protocol layer. DstPort could be defined by a UDP/TCP destination port field, by an equivalent field in another transport protocol, or by some application-specific information.
RSVP PROVIDES QUALITY
Host applications use RSVP to request the necessary QoS (such as guaranteed bandwidth) from the network for specific data flows. The QoS request is sent through all the routers along the path of the data flow on a hop-by-hop basis, and at each device the RSVP process attempts to establish and maintain a reservation state to provide the requested service.
Refresh messages are sent periodically by hosts and routers to maintain this state during the duration of the data transfer. The established state ends when the end host sends an explicit "teardown" message after the application has finished sending the data. RSVP also adapts to routing topology and multicast group membership changes.
While RSVP provided QoS for data flows, it does not change existing routing protocols that determine where the packets get forwarded. To obtain routing-related information, RSVP consults the existing IP routing database.
For handling bidirectional data flows, it treats each flow independently and makes unidirectional reservations. The receiver host is responsible for initiating and maintaining the reservation for the flow. This receiver-focused approach accommodates the requirements of dynamic group memberships in IP multicasting environments and addresses diverse receiver requirements.
RESERVATION MODEL
A RSVP reservation request consists of a "flowspec" plus a "filter spec", the pair is called a "flow descriptor". The flowspec specifies a desired QoS. The filter spec, together with a session specification, defines the set of data packets (the flow) to receive the QoS defined by the flowspec.
The flowspec in a reservation request will generally include a service class and two sets of numeric parameters:
an "Rspec" (R for `reserve') that defines the desired QoS
a "Tspec" (T for `traffic') that describes the data flow.
In the interest of simplicity (and to minimize layer violation), the basic filter spec format defined in the present RSVP specification has a very restricted form: sender IP address and optionally the UDP/TCP port number SrcPort.
RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs."downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow.
Fig 5.3.1 Shows the data flow diagram of RSVP
At each intermediate node, a reservation request triggers two general actions, as follows:
1. Make a reservation on a link
The RSVP process passes the request to admission control and policy control. If either test fails, the reservation is rejected and the RSVP process returns an error message to the appropriate receiver(s). If both succeed, the node sets the packet classifier to select the data packets defined by the filter spec, and it interacts with the appropriate link layer to obtain the desired QoS defined by the flowspec.
The detailed rules for satisfying an RSVP QoS request depend upon the particular link layer technology in use on each interface. For a simple leased line, the desired QoS will be obtained from the packet scheduler in the link layer driver, for example. If the link-layer technology implements its own QoS management capability, then RSVP must negotiate with the link layer to obtain the requested QoS. Note that the action to control QoS occurs at the place where the data enters the link-layer medium, i.e., at the upstream end of the logical or physical link, although an RSVP reservation request originates from receiver(s) downstream.
2. Forward the request upstream
A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request.
The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be "merged" as reservations travel upstream.
When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater than that being requested. At that point, the arriving request is merged with the reservation in place and need not be forwarded further; the node may then send a reservation confirmation message back to the receiver. Note that the receipt of a confirmation is only a high-probability indication, not a guarantee, that the requested service is in place all the way to the sender(s).
The basic RSVP reservation model is "one pass": a receiver sends a reservation request upstream, and each node in the path either accepts or rejects the request. This scheme provides no easy way for a receiver to find out the resulting end-to-end service. Therefore, RSVP supports an enhancement to one-pass service known as "One Pass With Advertising" (OPWA). With OPWA, RSVP control packets are sent downstream, following the data paths, to gather information that may be used to predict the end-to-end QoS. The results ("advertisements") are delivered by RSVP to the receiver hosts and perhaps to the receiver applications. The advertisements may then be used by the receiver to construct, or to dynamically adjust, an appropriate reservation request.
FUNCTIONAL SPECIFICATIONS OF RSVP
This below figure shows the RSVP message format
----------------------------------------------------------
Vers | Flags| Msg Type | RSVP Checksum
---------------------------------------------------------
| Send_TTL | (Reserved) | RSVP Length
---------------------------------------------------------
The fields in the RSVP messages are
1.Vers: Usually 1.
2. Flags: 4 bits 0x01-0x08:Reserved.
3. Msg Type:8 bits
1=Path
2= Resv and so on.
4. RSVP Checksum:16 bits
5. Send_TTL:IP TTL value with which the message was sent.
6. RSVP Length: 16 bits- includes the common header and variable length objects that follow
RSVP PROTOCOL MECHANISMS
There are two fundamental RSVP message types: Resv and Path.
Each receiver sends RSVP reservation request (Resv) messages upstream towards the senders. These messages follow exactly the reverse path the data packets will use. Going upstream they create and maintain "reservation state" in each node along the path(s). When Resv messages finally reach the senders, each sender host transmits RSVP Path messages downstream along the uni-/multicast routes provided by the routing protocol(s), following the paths of the data. These Path messages store "path state" in each node along the way.
The path state includes the unicast IP address of the previous hop node used to route the Resv message hop-by-hop in the reverse direction, and the following additional information:
A Sender Template, which describes the format of data packets the sender will originate. This template is in the form of a filter spec used to select sender's packets from others in the same session on the same link. The sender template has the same power and format as the Resv message's filter spec. It specifies the sender IP address and optionally the UDP/TCP sender port.
A Sender Tspec, which defines the traffic characteristics of the data flow the sender will generate. This information is used to prevent over-reservation and Admission Control failures.
An OPWA advertising information known as an "Adspec". This information is passed to the local control traffic, which returns it adequately updated; the updated version is then forwarded downstream in Path messages.
Path messages are sent with the same source and destination address as the data, so that they are routing correctly through non-RSVP clouds. Resv messages are sent hop-by-hop; each RSVP-node forwards a Resv message to the unicast address of a previous RSVP hop.
SOFT STATE
RSVP takes a "soft state" approach where soft state are created in routers and hosts which are periodically refreshed by Path and Resv messages. Any state is deleted if no matching refresh messages are received before the expiration of a "cleanup timeout" interval. States may also be explicitly deleted by a "teardown" message.
Path and Resv messages are idempotent. When a route changes, the next Path message will initialize the path state on the new route, and future Resv messages will establish reservation states there. States on previous now unused segments will timeout.
RSVP messages are IP datagrams with no reliability enhancement. Refresh messages are expected to handle any occasional loss of messages
TEAR DOWN
Teardown messages remove path or reservation state immediately. Although it is not necessary at all, it is recommended that all end hosts send a teardown request as soon as an application finished.
There are two types of teardown messages, PathTear and ResvTear. A PathTear message travels downstream from sender toward all receivers deleting path state and dependent reservation state. A ResvTear message travels upstream from receiver towards all senders deleting reservation state.
A teardown request may be initiated either by an application in an end system (sender or receiver), or by a router as the result of state timeout or service preemption. Once initiated, it must be forwarded hop-by-hop without delay.
Like all other messages, teardown requests are not delivered reliable. Any loss will not cause a failure because the unused state will eventually time out even though it is not explicitly deleted, if a router fails to receive a teardown message beyond the loss point.
ERRORS
There are two error messages, ResvErr and PathErr. PathErr are sent upstream to the sender that created the error; they do not change path state in the nodes through which they pass.
ResvErr are more complex. Since a request that fails may be the result of merging a number of requests, a reservation error must be reported to all of the responsible receivers.
CONFIRMATION
To request a confirmation a receiver Rj includes in the Resv message a confirmation-request object containing Rj's IP address. At each merge point, only the largest flowspec and its confirmation-request object is forwarded upstream. If the Rj's reservation-request is equal to or smaller than the reservation in place on a node, its Resv is not forwarded further but if a confirmation-request object is present, a ResvConf message is sent back to Rj.
This confirmation mechanism has the following consequences:
Any reservation request will result in either a ResvErr or a ResvConf message sent back to the receiver from each sender. The ResvConf message is end-to-end.
The receipt of a ResvConf gives no guarantees. A ResvConf message may be received followed by a ResvErr message.
WORKING EXAMPLE OF RSVP
Host A wants to send multimedia traffic at a constant rate to Host B using the Internet. To facilitate this process, Host A requests QoS (example: bandwidth on demand) from the network using RSVP. The following steps are involved in establishing end-to-end QoS, which is set up before any data is transferred.
The RSVP program in Host A receives the desired QoS request from the multimedia application and sends an RSVP path message to Host B.
This message follows the exact path that the multimedia traffic would take and creates a "path state" across all nodes in the direction of the traffic flow. The path message contains the sender's IP address, format of data packets and details on the traffic characteristics.
On receiving the path message, Host B originates an RSVP reservation request message. The next hop for this message is obtained from the previously established path state and follows the exact reverse direction of the path message. It contains the desired QoS information (in this case the requested bandwidth) and a filter condition that identifies the subset of data packets that should receive the QoS.
The RSVP program in the router, on receiving the reservation request message, passes it to two local decision modules: an admission control module, which determines if the node has sufficient available resources to supply the requested QoS; and a policy-control module, which verifies whether the requester has the administrative privileges to make the reservation. If either check fails, it returns an error notification to the application that made the request. If both checks succeed, the RSVP program configures the packet classifier in the node to determine the data packets that receive the QoS. The RSVP program also configures the packet scheduler to provide the requested QoS on the outgoing link. This creates a reservation state in the node.
After having made the reservation locally, the router sends the reservation request to the next node in the direction of the sender. The process continues on a hop-by-hop basis, and at each node the RSVP program attempts to establish and maintain a reservation state to provide the requested QoS. Finally, the reservation request reaches the sender host and creates a reservation locally. At this point, the multimedia data stream originating from the sender will receive the requested bandwidth from the network.
After having successfully reserved the bandwidth end to end, Host A sends multimedia traffic to Host B.
Fig 6.1 Shows how RSVP works
From the figure we can explain the working of RSVP as follows :
Multimedia application on sender’s PC requests QoS from sender’s network
Sender’s network requests that receiver of multimedia traffic set up RSVP path. Requests takes exact path that multimedia traffic will take once RSVP is set up.
Receiver follows path back to sender, establishing reservation states at each router along the way
When reservation request reaches sender, end-to-end QoS is established and multimedia traffic is sent.
CONCLUSION
RSVP protocol is a must guarantee end-to-end to Quality of Service in Unified Communications which involves both transmission of both video and audio data’s. As a whole RSVP protocol has the following features
1) Makes reservations for both unicast and multicast.
2) RSVP is receiver oriented.
3) RSVP maintains soft state in routers and hosts.
4) It is not a routing protocol but depends upon the present and future protocols.
5) It transports and maintains traffic control and policy control parameters that are opaque to RSVP
6) RSVP provides several reservation styles to fit a variety of applications.
7) RSVP supports both IPV4 and IPV6.
Download this Seminar From:
MediaFire: Download
password:be
0 comments:
Post a Comment
Thanks for your Valuable comment