QoS is the subject of ongoing active research and more or less active standardization.
ITU-T has done much work in relation to B-ISDN, in which it effectively relied on the output of the ATM Forum. To this end, ITU-T Recommendations I.356 and I.610, respectively, specify performance measurement methods and QoS objectives for end-to-end connections and define operations and management tools to monitor the QoS parameters. In addition, the B-ISDN signaling specifies mechanisms for negotiating traffic parameters and QoS performance objectives.
Because of its connection-oriented, virtual-circuit approach to packet networking, it is more or less straightforward to deal with the QoS in the PSTN: The characteristics of the virtual circuit are what need to be negotiated among the participants of a session (and between each participant and the network). Given the inherently connectionless and stateless nature of the IP networks, guaranteeing end-to-end QoS is a much more complex matter. Consequently, standardization of relevant protocols is more complex, too. Virtually all QoS work that is related to routing (or, more precisely, forwarding) is performed in the IETF, and so, we concentrate on the IETF developments (some of which are explicitly addressed by the documents issued by other standards bodies).
There are two basic approaches to IP QoS:
1. Guaranteeing certain QoS on a per-flow basis.
The former approach is taken by the Integrated Services (intserv) and Resource Reservation Setup Protocol (rsvp) working groups, the latter by the Differentiated Services working group. In addition, the Multiprotocol Label Switching (mpls) working group is dealing with what effectively amounts to establishing virtual circuits for IP traffic, which makes it particularly suitable to interworking with the PSTN B-ISDN networks (such as ATM and Frame Relay networks). In the rest of this section, we address the respective standardization developments in that order.
The IETF Integrated Services (intserv) working group (www.ietf.org/html.charters/intserv-charter.html ) has been chartered with the development of an abstract packet-forwarding model. The applications of the model to particular Layer 2 protocols (such as ATM) have been, and continue to be, developed in the Integrated Services over Specific Link Layers (issll) working group (www.ietf.org/html.charters/issll-charter.html), which has produced ATM-related RFCs and works on the following link layer protocols: PPP, IEEE 802.2 LAN, and ISO High-Level Data Link Control (HDLC).
The earlier informational RFC 1633 specified the reference model for the network elements, which sets basic functions and terminology (see Figure 1). In this model, an arriving packet passes the:
§ Classifier. Maps the packet into a specific class (the class of the packet determines its treatment).
§ Packet scheduler. Manages the forwarding of different packet streams using a set of queues and possibly other mechanisms, like timers.
§ Output (first-in, first-out) queue.
Figure 1: Implementation reference model for routers.
Source: RFC 1633.
In the upper part of the figure, the routing agent supports a specific routing protocol and maintains the routing database. The reservation setup agent supports a specific resource reservation protocol; after approval by admission control, the traffic control database (which is shared with the classifier and packet scheduler) is modified to reflect the desired QoS. The management agent can modify this database, too, on behalf of the network management requests, in order to arrange controlled link sharing and to set admission control policies.
Following the template defined in informational RFC 2216, two types of services—the controlled-load service and guaranteed service—and their respective network element behavior types are defined in RFC 2211 and RFC 2212, respectively, as follows:
Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded.
Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queuing delays.
To the application processes subscribing to the controlled-load service, the network appears to be unloaded. In other words, the packet loss, if any, will approximate that typical to the transmission medium. As for the delay, it is supposed to be nearly constant, dependent again on the transmission medium delay and the processing time delay in devices along the path. The application process specifies the controlled-load service by providing the Token Bucket Specification (Tspec, defined in RFC 2215). The application process specifies the guaranteed-load service by the same token bucket specification (Tspec) as well as the Reservation Specification (Rspec). Rspec is a pair of numbers that, respectively, specify the data rate (ranging from 1 to 40 TB/s) and the slack term (ranging from 0 to 232 - 1 ms). The slack term is used by any network element to reduce its reservation level (the updated slack term is then passed to the next network element in the chain). RFC 2211 and 2212, respectively, specify the actions of network elements for each of the two types of services.
One resource reservation protocol has been developed, in close cooperation with the intserv working group, by the Resource Reservation Protocol (rsvp) working group (www.ietf.org/html.charters/rsvp-charter.html) in the transport area of the IETF. The protocol is also called RSVP, and is published in RFC 2205.
RSVP is used by the application process at the receiving end of flows (that is, streams of data with the same QoS requirements, which are defined by the destination address related to a particular session) as well as by the network elements along the path among the hosts whose processes are involved in the session. (The protocol has been specifically designed for and used by the multicast sessions, which explains its major features—especially the reservation mechanism described in the following text.) Although choice of a transport layer is not essential to key function of the protocol, the transport layer ports specifically considered in the document are those of UDP and TCP.
The reservations are requested for simplex flows. That means that the protocol treats the receiver and sender as two independent entities (in a manner similar to the single-endedness principle of the IN). Only the receiver makes reservations. If there are two application processes talking to each other, two different and independent reservations will be made: one by the receiver in one process, and one by the receiver in the other.
Figure 2 demonstrates the place of RSVP in the integrated services architecture—in particular, to the interface between a host and a router. The host model is equivalent to that of the router, which underlines the principle that the QoS is defined at the edges by hosts with routers carrying out the requests. The data path (that is, the interface between the packet scheduler of the sender and classifier of the receiver) is clearly separated from that between the two RSVP processes, which explains why the “implementation of RSVP will typically execute in the background, not in the data forwarding path.” (For this reason, following telephony terminology, the Internet community often refers to RSVP messages as the out-of-band signaling, although the difference between in-band and out-of-band is much more subtle here than in the case of the PSTN.) We should clarify, however, that RSVP is not an admission-control or packet-scheduled application, and its role is to reserve rather than provide the resources.
Source: RFC 2205.
An RSVP reservation request uses a flow descriptor, which consists of flowspec (which may, in turn, include the service class, Tspec, and Rspec) and filterspec. The flowspec describes the QoS and is used by the packet scheduler; the filterspec defines the set of packets (that is, the flow) for the given QoS and is used by the packet classifier. Two-reservation options with respect to the treatment of different senders in the same session are supported: (1) establishing a distinct reservation for each sender and (2) making a single reservation shared among all senders. Other two-reservation options with respect to the selection of senders and, thus, the existence and number of filter specs provide (1) the explicit list of senders (with one filter spec for each sender) and (2) the so-called wildcard that explicitly selects all senders (and so eliminates the need for the filterspec).
Following is a description of how RSVP works. The sender transmits the Path message specifying the QoS request. As this message traverses network elements, it is stored in the path state in each of them. The receiver sends back along the same path Resv messages specifying the QoS for the reservation requests. The messages affect a soft (i.e., temporary) state: As the Path messages are periodically retransmitted, so the Resv messages are repeated to maintain this soft state for the duration of the session. These two messages are defined as fundamental by the RSVP standard (RFC 2205), which was designed to identify (via Path messages) all endpoints of a multicast flow. (The Resv messages from separate receivers can be combined into a single request at those points in the network where a flow’s paths merge.) With these two messages, RSVP not only uses existing routing protocols to determine the path of the flow between source(s) and destination(s), but it also reacts to changes in the network topology. Retransmission of Path/Resv over a new path can be used to change a path of a reserved flow, while the absence of retransmissions can be detected by the routers so as to deallocate the QoS resources associated with a delinquent path.
No comments:
Post a Comment