The Label Mapping Message The Traffic Parameters TLV

166 LABEL DISTRIBUTION PROTOCOLS • VeryFrequent value 2: That is, the available rate should average at least the CDR when measured over any time interval equal to or longer than the shortest packet time transmitted at the CDR. • Reserved values 3 to 255 . Finally, the 8-bit weight field is used to indicate the CR-LSP’s relative share of the excess bandwidth. Weight values range from 1 to 255. The value 0 means that the weight is not applicable.

7.2.5 Classes of Service

Class services can be constructed by appropriately manipulating the traffic parameters, and the rules regarding passing, marking, and dropping a packet. In Table 7.1, we give the traffic parameters and rules for marking and dropping packets for three classes of service: delay sensitive DS service, throughput sensitive TS service, and best effort BE service . In the delay sensitive service, the network commits with high probability to deliver packets at a rate of PDR with minimum delay. Packets in excess of PDR will be discarded. In the throughput sensitive service, the network commits to deliver with high Table 7.1 Traffic parameters – DS, TS, and BE service classes. Traffic Parameters Delay sensitive Throughput sensitive Best effort PDR User-specific User-specific Infinite PBS User-specific User-specific Infinite CDR PDR User-specific Infinite CBS PBS User-specific Infinite EBS Frequency Frequent Unspecified Unspecified Dropping action Drop PDR Drop PDR, BPS, Mark CDR, CBS None Table 7.2 Traffic parameters – ATM service categories. Traffic parameters CBR RT-VBR NRT-VBR UBR PDR PCR PCR PCR PCR PBS CDVT CDVT CDVT CDVT CDR PCR SCR SCR – CBS CDVT MBS MBS – EBS Frequency VeryFrequent Frequent Unspecified Unspecified Dropping action Drop PCR Drop PCR, Mark SCR, MBS Drop PCR Drop PCR THE RESOURCE RESERVATION PROTOCOL RSVP 167 probability packets at a rate of at least CDR. The user can transmit at a rate higher than CDR but packets in excess of CDR have a lower probability of being delivered. In the best effort service there are no service guarantees. In Table 7.2, we give the traffic parameters and rules for marking and dropping packets for the ATM service categories: constant bit rate CBR, real-time variable bit rate RT- VBR, non-real-time variable bit rate NRT-VBR , and unspecified bit rate UBR.

7.3 THE RESOURCE RESERVATION PROTOCOL RSVP

An alternative signaling protocol to LDP and CR-LDP is the resource reservation protocol – t raffic engineering RSVP-TE . RSVP-TE is an extension of the resource reservation protocol RSVP which was designed to support the integrated services intserv architecture. In order to understand RSVP-TE, we first have to understand how RSVP works. In view of this, in this section we describe the main features of RSVP and in the following section we describe RSVP-TE. The intserv architecture was developed by IETF in the mid 1990s with a view to intro- ducing QoS in the IP network. The following two service classes were defined in intserv: 1. Guaranteed service: This service provides firm bounds on the end-to-end queueing delay with no packet loss for all conforming packets. 2. Controlled-load service: This service provides the user with a QoS that closely approx- imates the QoS of the best effort service that the user would receive from an unloaded network. Specifically, a user might assume the following: a. A very high percentage of transmitted packets will be successfully delivered by the network to the receiver. The percentage of packets not successfully delivered must closely approximate the basic packet error rate of the transmission links. b. The end-to-end delay experienced by a very high percentage of the delivered pack- ets will not greatly exceed the minimum end-to-end delay experienced by any successfully delivered packet. In intserv, the sender specifies how much traffic it will transmit to its receivers, and a receiver specifies how much traffic it can receive and the required QoS, expressed in terms of packet loss and end-to-end delay. This information permits each IP router along the path followed by the sender’s packets to perform the following functions: 1. Policing: This is used to verify that the traffic transmitted by the sender conforms to the sender’s Tspec, a set of traffic descriptors that characterize the traffic transmitted by the sender. 2. Admission control: This is used to decide whether an IP router has adequate resources to meet the requested QoS. 3. Classification: This is used to decide which IP packets should be considered as part of the sender’s traffic and be given the requested QoS. 4. Queueing and scheduling: In order for an IP router to provide different QoS to different receivers, it has to be able to queue packets into different queues and to transmit packets out of these queues according to a scheduler. The intserv architecture requires a signaling protocol for the reliable establishment and maintenance of resource reservations. As in MPLS, intserv does not require the use of a specific signaling protocol, and it can accommodate a variety of signaling protocols, 168 LABEL DISTRIBUTION PROTOCOLS of which RSVP is the most popular one. RSVP was developed to support the intserv architecture, but it can be used to carry other types of control information. This is because RSVP is not aware of the content of the RSVP protocol fields that contain traffic and policy control information used by the routers to reserve resources. RSVP can be used to make resource reservations for both unicast and many-to-many multicast applications. RSVP was designed with a view to supporting multiparty conferences, i.e., many-to- many, with heterogeneous receivers. In RSVP, the resource reservation is decided and initiated by a receiver, since only the receiver actually knows how much bandwidth it needs. This approach also permits a receiver to join or leave a multicast whenever it wants. One problem with the receiver-initiated approach is that the receiver does not know the path from the sender to itself. Therefore, it cannot request resource allocation on each router along the path since it does not know which are these routers. This problem is solved using the Path message that originates from the sender and travels along the unicast or multicast route to the receiver. The main purpose of the Path message is to store the path state information in each node along the path and to carry information regarding the sender’s traffic characteristics and the end-to-end path properties. The following is some of the information contained in the Path message: • Phop : This is the address of the previous hop RSVP-capable router that forwards the message. This address is stored in the path state information at each node, and is used to send the reservation message upstream towards the sender. • Sender template : This field carries the sender’s IP address and optionally the UDPTCP sender port. • Sender TSpec : This defines the traffic characteristics of the data flow that the sender will generate. The sender Tspec format that is used for the intserv architecture will be described below. • Adspec : This carries one-pass with advertising OPWA information. This is information advertisements gathered at each node along the path followed by the Path message. This information is delivered to the receiver, who can then use it to construct a new reservation request or to modify an existing reservation. Upon receipt of the Path message, the receiver sends an Resv message towards the sender along the reverse path that the Path message followed see Figure 7.19. The following is some of the information contained in the Resv message: • Flowspec : Specifies the desired QoS. It consists of the receiver TSpec, the RSpec, and the service class. The receiver TSpec is a set of traffic descriptors that is used by the nodes along the path to reserve resources. The RSpec defines the desired bandwidth Sender Receiver Path Path Path Path Resv Resv Resv Resv Figure 7.19 An example of the path and resv messages. THE RESOURCE RESERVATION PROTOCOL RSVP 169 and delay guarantees. When RSVP is used in intserv, the service class could be either the guaranteed service or the controlled-load service. The format for the receiver TSpec and RSpec used in the intserv architecture is described below. • Filter spec : Defines the packets that will receive the requested QoS that was defined in the flowspec. A simple filter spec could be just the sender’s IP address and optionally its UDP or TCP port. When a router receives the Resv message, it reserves resources per the receiver’s instruc- tions and then sends the Resv message to the previous hop router obtained from the path state information. RSVP messages are sent in raw IP datagrams without a TCP or UDP encapsulation. UDP encapsulation is permitted for routers that do not support raw IP datagrams. RSVP makes use of the notions of data flow and session. A session is defined by the parameters: destination IP address, protocol id, and optionally destination port number. A data flow is simply the packets transmitted by a sender in a particular session. RSVP is simplex; that is, it makes reservations for unidirectional data flows. Therefore, in order for two users A and B to communicate both ways, two separate sessions have to be established; one session from A to B, and another one from B to A.

7.3.1 Reservation Styles

Three different reservation styles, i.e., schemes, can be used with RSVP. In order to understand these schemes, let us consider the case where a number of senders transmit information to the same receiver. Each sender transmits its own data flow of packets in a session, which is defined by the receiver’s IP address and protocol id. One reservation option is concerned with the resource reservation of these sessions. In particular, let us assume that several of these data flows pass through the same router. The router has the option to establish a separate reservation for each data flow or to make a single reservation for all of the data flows. A second reservation option controls the selection of the senders. It can be explicit or wildcard. In the explicit sender selection, the receiver provides a list of senders from which it wishes to receive data. A sender cannot send packets to the receiver unless its IP address is in the explicit list. In the wildcard sender selection, any sender can transmit data to the receiver. Based on these two options the following three different styles have been defined: 1. Wildcard-filter WF style: Any sender can transmit to the session. There is a single resource reservation shared by all of the data flows from all upstream senders. The resource reservation is the largest of all requested reservations. 2. Fixed-filter FF style: A separate reservation is made for each particular sender that is specified in the explicit list of senders. Other senders identified in the explicit list who transmit in the same session do not share this reservation. 3. Shared explicit SE style: A list of senders is explicitly stated, and there is a single shared reservation for all of their flows.

7.3.2 Soft State

RSVP takes a soft state approach to managing the reservation state in the routers and hosts. That is, the state information in each router and host has to be periodically refreshed by 170 LABEL DISTRIBUTION PROTOCOLS Path and Resv messages. The state of a reservation is deleted if no matching refreshing messages arrive before a cleanup timeout interval. State can also be deleted by an explicit teardown message. When a route changes, the next Path message will initialize the path state on the routers along the new route and the Resv message will establish a reservation on each of these routers. The state of the unused route will time out. RSVP sends its messages as IP datagrams with no guarantee that they will get deliv- ered. An RSVP message might never get delivered due to transmission errors or buffer overflows. This situation is taken care by the periodic refresh messages. Sending refresh messages increases the load on the network, but it eliminates the need to use a reliable protocol such as TCP which guarantees the reliable delivery of RSVP messages.

7.3.3 The RSVP Message Format

An RSVP message consists of a common header followed by a variable number of objects. Each object contains a group of related parameters and it has a variable length. The common header format is shown in Figure 7.20. The following fields have been defined: • Vers : A 4-bit field used to indicate the protocol version number. • Flags : A 4-bit field used for flags; no flags have been specified. • MsgType : The message type is specified by a number carried in this 8-bit field. The following message types and numbers have been specified: ◦ 1 – Path ◦ 2 – Resv ◦ 3 – PathErr ◦ 4 – ResvErr ◦ 5 – PathTear ◦ 6 – ResvTear ◦ 7 – ResvConf • RSVP checksum : A 16-bit checksum calculated on the entire message. • Send TTL : An 8-bit field that contains the IP time to live value. • RSVP length : The total length in bytes is stored in this 8-bit field. The length includes the common header and all of the objects that follow. The object format is shown in Figure 7.21. The following fields have been defined: • Length : A 16-bit field used to indicate the total length in bytes of the object. It must be a multiple of four, and at least equal to four. • Class-num : An 8-bit field used to identify the object class. • C-Type : An 8-bit field used to define the object type. MsgType RSVP checksum RSVP length Vers Send_TTL Reserved Flags 4 Bits 4 Bits 16 Bits 8 Bits Figure 7.20 The common header format. THE RESOURCE RESERVATION PROTOCOL RSVP 171 Object contents 2 Bytes 1 Byte 1 Byte Length bytes Class-num C-Type Figure 7.21 The object format. The following object classes have been defined: • NULL : The contents of a NULL object are ignored by the receiver. • SESSION : Contains the IP destination address, the IP protocol id, and optionally a destination port. This object is required in every RSVP message. • RSVP HOP : Carries the IP address of the RSVP-capable router that sent this message. For messages sent from the sender to the receiver, the RSVP HOP object is referred to as the previous hop PHOP object; for messages sent from the receiver to the sender, it is referred to as the next hop NHOP object. • TIME VALUES : Contains the value for the refresh period used by the creator of the message. It is required in every Path and Resv message. • STYLE : Defines the reservation style plus style-specific information. It is required in every Resv message. • FLOWSPEC : Carries the necessary information in an Resv message to make a reserva- tion in a router. • FILTER SPEC : Defines which data packets should receive the QoS specified in the FLOWSPEC object. It is required in a Resv message. • SENDER TEMPLATE : Defines the sender’s IP address and perhaps some additional demultiplexing information, such as a port number. It is required in a Path message. • SENDER TSPEC : Contains the traffic characteristics of the sender’s data flow. It is required in a Path message. • ADSPEC : Carries the one-pass with advertising OPWA information. As discussed above, this information is gathered at each node along the path that is followed by the Path message. This information is delivered to the receiver, who can then use it to construct a reservation request or adjust an existing reservation appropriately. • ERROR SPEC : Specifies an error in a PathErr, ResvErr, or a confirmation in a Resv- Conf message. • POLICY DATA : Carries information that allows a router to decide whether a reservation is administratively permitted. It can appear in a Path, Resv, PathErr, or ResvErr message. One or more POLICY DATA objects can be used. • INTEGRITY : Carries cryptographic data to authenticate the originating node to verify the contents of this RSVP message. • SCOPE : Carries an explicit list of sender hosts towards the information in the message is to be forwarded. It can appear in a Resv, ResvErr, or ResvTear message. • RESV CONFIRM : Carries the IP address of a receiver that requested a confirmation. It can appear in a Resv or ResvConf message. Below, we describe the Path and Resv messages.