RSVPHIGHLIGHTSMultimedia NetworkingDefinitionBasic Flow DiagramTerminologyDuring reservation setup, an RSVP QOS request is passed to two local decision modules: 1. Admission control 2. Policy control. Admission Control: Determines whether the node has sufficient available resources to supply the requested resources. Policy Control: Determines whether the user has administrative permission to make the reservation.If both checks succeed, parameters are set in the packet classifier and in the link layer interface to obtain the desired QOS. If either checks fails, the RSVP program returns an error notification to the application process that generated the request.Since the membership of a large multicast group and the resulting tree are likely to change with time,the RSVP protocol specifies the creation of “soft states” , that can be built and destroyed incrementally in the routers and the hosts. For this RSVP periodically sends refresh messages to maintain the state along the reserved paths.Data Flows RSVP defines a session to be a “data flow” with a particular destination and transport layer protocol. An RSVP session is defined by the triple: DestAddress,Protocol ID,DstPort The DstPort is an optional parameter and is a generalized destination port. However the DstPort is necessary to allow more than one unicast session addressed to the same receiver host.Reservation Model An RSVP request consists of : flowspec together with a filterspec. This pair is called the “flow descriptor”. The flowspec specifies a desired QOS. The filterspec together with the session specification defines the set of data packets. The flowspec is used to set parameters in the packet scheduler,while the filterspec is used to set parameters in the packet classifier.The flowspec in a reservation request will generally include a service class and two sets of numeric parameters: Rspec- defines the desired QOS. Tspec- describes the data flow. The format and contents of the above are determined by the integrated service models and are generally opaque to RSVP.Making a Reservation RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the senders. At each intermediate node, a reservation triggers two general actions: 1.The RSVP passes the request to admission and policy control and the check is executed. 2. A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a reservation request is propagated is called the “scope” of that request.The basic reservation model is “one-pass”: a receiver sends a request upstream and each node in the path either accepts or rejects the request.This does not provide a way to determine the end-to-end service. Therefore, RSVP supports an enhancement to one pass service known as One-Pass With Advertising(OPWA). With this scheme, RSVP control packets are sent downstream , flowing the data paths to gather information that can be used to predict the end to end QOS.These results are delivered to the receivers hosts which can dynamically adjust the QOS.Reservation Styles A reservation request includes a set of options termed ’reservation styles’. One style concerns the treatment of reservations for different sessions within the same sessions. Another style controls the selection of senders.It may be explicit or a wildcard entry.Reservation Styles… Sender Reservations Selection Distinct Sender Explicit Fixed Filter Shared Explicit Wildcard None Wildcard Filter1.Wildcard Filter(WF)Style:It creates a single reservation shared by flows from all upstream senders.WF(*(Q)) *- represents the wildcard sender selection Q-flowspec 2. Fixed Filter(FF): It creates a distinct reservation for data packets from a particular sender. FF(S(Q)) 3. Shared Explicit(SE):It creates a single reservation shared by selected upstream senders.SE((S1,S2,..)(Q))RSVP Protocol MechanismsThere are two fundamental RSVP messages: 1.Path 2. Resv Each receiver host sends a Resv message upstream towards the senders. These messages must follow the exact reverse path the data will use. They create and maintain the reservation state in each node along the path.Path: Each RSVP sender host transmits a Path message downstream. These store the the ‘path state’ in each node along the way. This path state includes the IP address of the previous hop node which is used to route the Resv message in the reverse direction. Each Path message contains the following information: 1.Sender Template: Describes the format of data packets that the sender will originate. 2.Sender Tspec: Defines the traffic characteristics of the data flow. 3.Adspec: Used for OPWA.1.Soft State: RSVP takes a soft state approach to manage the reservation state in routers and hosts. A soft state is created and periodically refreshed by Path and Resv messages. 2. Teardown: It is used to remove path or reservation state immediately.Two Types: 1. PathTear-travels downstream 2. ResvTear -travels upstream3. Errors: The two killer reservation problems: 1. KR-1-It arises when already there is a Q0 in place and if another receiver makes a larger Q1>Q0, the result of merging may be rejected by some intermediate node. Solution: In case of failure, any existing reservation is kept in place. 2.KR-II-The receiver is trying to make a reservation of Q1 even though admission control is failing for it in some node.This must not prevent a Q0 <Q1 from establishment. Solution: Blockade State.Blockade State: A blocked state in a node modifies the merging process to omit the offending flowspec. When a ResvErr message is received , its flowspec Qe is used to create or refresh an element of local blockade state. Each element of blocked state consists of a blocked flowspec Qb taken from the error message and a associated blockade timer Tb. When a blockade timer expires , the corresponding blockade state is deleted.RSVP:Functional Specifications ---------------------------------------------------------- Vers | Flags| Msg Type | RSVP Checksum --------------------------------------------------------- | Send_TTL | (Reserved) | RSVP Length ---------------------------------------------------Functional Specifications… 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