Download (direct link):
Frequency Frequent Unspecified Unspecified
Dropping action Drop > PDR Drop > PDR, BPS, None
Mark > CDR, CBS
Table 7.2 Traffic parameters - ATM service categories.
Traffic 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 0 0 0 0
Frequency VeryFrequent Frequent Unspecified Unspecified
Dropping Drop > PCR Drop > PCR, Drop > PCR Drop > PCR
action Mark > SCR, MBS
THE RESOURCE RESERVATION PROTOCOL (RSVP)
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 - traffic engineering (RSVP-“Ň). RSVP-“Ň 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 introducing 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 approximates 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 packets 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 receiver(s), 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,
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.