Consolidation of several types of services in the existing communication networks (like ATM and Internet, for example), has been shown a strong dependence relationship between Quality of Service (QoS) of a given distributed application and resource reservations. In this context, Resource ReSerVation Protocol (RSVP) has been specified with the goal of consider recent Internet Integrated Services model (IIS model). However, the good familiarity of ATM and Internet network technologies (Classical IP over ATM or LAN Emulation, for example) also make possible its integration over ATM networks. Hence, the goal of this paper is to present a QoS management architecture, discussing the main integration aspects of the RSVP protocol over ATM networks, which are: signalling, QoS mapping and Virtual Connections (VCs) management. Signalling deal with dynamic QoS renegotiation and VCs heterogeneity, while QoS mapping approaches the mapping between IIS services and ATM service classes. The QoS management architecture treats, along with various other aspects, those that were presented previously.

Keywords: ATM, QoS, RSVP, IIS, management, VCs.

        1.Introduction

        In the present time, distributed applications can be characterized by their QoS requirements. Thus, QoS parameters like delay, throughput, jitter and loss rate could be handled in ATM (Asynchronous Transfer Mode) networks, with the goal of providing to the application user his complete happiness. For an ATM network, that make possible the establishment of point-to-point or point-to-multipoint VCs with specific service classes (CBR, VBR, UBR, ABR, etc.), to use together the RSVP and the IIS model can mean a easier control of the requested QoS.
        The IIS model supports, beyond the best-effort service, two new services destined to the control of QoS: the Guaranteed Service (GS) [11] and the Controlled-Load Service (CLS) [12]. GS provides a service that produces a limited delay, starting from a specific guaranteed bandwidth. On the other hand, CLS provides to an application a service similar to the best-effort service for a non-overloaded network. To ensure this behavior, in conditions of network’s overhead, it uses admission control. Such services are established by the RSVP signalling [10].
        Using the Classical IP over ATM architecture [8, 14], we can dispose the traffic dedicated as much to a single user (unicast) as to an users group (multicast). For this last one, it is important there to be a correspondence among the actions of IP and RSVP protocols and ATM functions (add or remove members of the group, for example). For an ATM network, point-to-multipoint VCs don’t support QoS heterogeneity for receivers, to making difficult its interaction with RSVP as we will see in the section 3.
        Initially, an important aspect of the RSVP integration over ATM it is to distinguish the original conception of each case. While RSVP is flow oriented, ATM connection oriented. After, we can characterize three processes: RSVP and ATM signalling, QoS mapping and VC management. QoS mapping considers the mapping between IIS model QoS and ATM QoS, while VC management concentrates on the amount of necessary VCs and in the mapping between RSVP flows and such VCs. RSVP and ATM signalling treats the dynamic QoS renegotiation and VCs heterogeneity. For ATM technology, particularly, they are interesting the following RSVP functionalities: the reservation styles, dynamic reservation changes and heterogeneous reservations inside a multicast session. Such functionalities make possible a better acceptance of real time applications (heterogeneous and distributed multimedia applications, for example).
        We can identify another distinction related with the network element responsible by the signalling and resource reservation. For RSVP, such functionality is carried out by the receiver, but, for an ATM network it is attributed to the sender. Therefore, we can say that RSVP is receiver oriented, and ATM is sender oriented. Such characteristic is not a serious incompatibility, because a sender could, without larger problems, establish each VC starting from the received signalling of each receiver. This receiver oriented reservation style makes possible RSVP to support several receivers with heterogeneous requirements [18, 13]
        In this context, we identified the importance of an efficient management process, which it should execute control functions on the resources and other network components, and it also allow that applications establish connections according to their requested QoS. Such process is inserted into a management architecture, and its efficiency should have as one of the goals, to guarantee that control messages are not prejudicial to the user data flow. The conception of specify a QoS management architecture has been still reinforced starting from the contributions found in [1, 6, 7].
        In the next sections we will look for to elucidate the points discussed above. In the section 2, we will present a brief vision of RSVP protocol in its original conception, highlighting its functionalities and principles. As the processes of signalling, QoS mapping and VC management involve more complex aspects, these will be particularly analyzed in sections 3, 4 and 5, respectively. Starting from this analysis, and considering several other important aspects, we can describe in the section 6 a QoS management architecture for the chosen context (RSVP, IIS and IP over ATM), which it should provide, in a simple and efficient manner, those functionalities previously commented. Conclusions will be exposed in the section 7 with a summary and some pertinent comments about the subject.

        2. RSVP Protocol

        RSVP protocol [10] is used by an application to request a specific network QoS through the resource reservation. We can summarize the attributes of RSVP in the following items:

• RSVP carries out resource reservation for unicast and multicast sessions.
• Resource reservations are initiated and maintained by the receivers.
• RSVP is not a routing protocol, but it depends of it.
• RSVP introduces the notion of soft state in routers and end systems, with the goal of friendly supporting dynamic user changes and automatic route adaptation.
• Support to multiple reservation styles or shared ways.
• RSVP operates in a transparent manner through routers that don’t support it.
• Heterogeneity in the resource reservation inside a multicast session.
• Dynamic reservation change.

• Fixed-Filter (FF) Style: such style is distinct with explicit sender selection. It is better used for video applications, being able to each video flow to be dedicated to its own RSVP flow.
• Wildcard-Filter (WF) Style: such style is shared with wildcard sender selection. It is used typically for audio applications, where users naturally expect their time of talking.
• Shared-Explicit (SE) Style: such style is shared with explicit sender selection. SE allows a receiver to specify explicitly its sender group. As well as WF style, SE style shows appropriated for multicast applications, in which is unlikely that multiple sources transmit simultaneously.

        Generally, we can adopt the number of RSVP flows created for different reservation styles above. For the FF style, the number of RSVP flows created depends on the amount of explicitly selected senders, that is, for k selected senders there are k+1 RSVP flows created, being one flow for each one of the k senders and an additional flow for the others non-selected senders. For the WF style, only one RSVP flow is created, because all senders share the same reservation. Finally, for the SE style is defined two RSVP flows, being resource reservation flow destined to consider to the explicitly selected senders, while best-effort flow considers to the others senders.
        Besides, more two other characteristics complete RSVP. The first treats of the heterogeneity attributed to QoS of several receivers of a same multicast group, allowing that each one of them specifies different values. Also, in any moment, it should be possible to a receiver join to an IP multicast group using the ATM best-effort service and, when it wants, to request a reservation. The second characteristic refers to the RSVP capacity of allow dynamic QoS specification, providing conditions for a receiver request a new QoS (larger or smaller) if the current is not acceptable.

        3. RSVP and ATM Signalling

        For a better integration between RSVP and ATM networks, two questions should be treated by the ATM signalling: the capacity of providing heterogeneous resource reservations for different receivers of a multicast group, and the capacity of supporting dynamic QoS reservations [17].
        Considering the context of RSVP protocol (Classical IP over ATM or LAN Emulation), we can distinguish two types of service: IP multicast service and QoS service. The first, with best-effort characteristics, it can always be available for a receiver. The second is provided by the IIS model (GS and CLS services). Thus, point-to-multipoint VCs should support both the types of service, with each VC being heterogeneous and allowing for each receiver of an IP multicast group to migrate of a service to another, when it wants.
        Parameters like cost or resource availability can determine that different receivers, of a same multicast group, request heterogeneous QoS reservations. Now, to support heterogeneous QoS reservations, ATM signalling could establish different VCs (point-to-point or point-to-multipoint), being one VC for each requested QoS. The disadvantage of this scheme is that each IP packet needs to be copied, and one copy should be sent for each established VC. Besides, depending on the network topology and the number of members into multicast group, a great amount of additional traffic could be generated due to such copies, causing congestion problems, losses or overhead in the network.
        Besides the VCs heterogeneity discussed above, other question involving RSVP is to support dynamic QoS renegotiation. RSVP was originally conceived to provide such functionality when an user wants to change (increase or decrease) its current QoS. Reserved resources could be adapted by RSVP to the new QoS in any instant, updating all the links along the established path. There can be several reasons so that a receiver tries to change its current QoS. For example, we can mention [3]: a) discontent with its current QoS, wanting to migrate for a different QoS; b) changes in the sender traffic specification; c) addition of a new sender to a existing multicast group, which has a traffic specification larger than the ones of the other existing senders; d) a receiver wants to release its existing reservation.
        Therefore, for integration of RSVP on ATM networks, we should wait that an ATM network supports dynamic QoS renegotiations in existing VCs. For this problem, ATM signalling could request the establishment of a new VC with requested QoS and posterior tear down of current VC. If the establishment of new VC fails, current VC would continue to be used. The process of tear down and establishment of an ATM VC is not simple, demanding a processing time of the network elements and a considerable latency. For an user application, dynamic QoS renegotiation should be transparent for its good operation. Therefore, we can note that such procedure is not suitable, being necessary add to the ATM siganlling other functionalities so that this presents a good integration with RSVP.
        For RSVP signalling messages in ATM VCs, basically, several approaches can be adopted. The main ones are [4]: 1) signalling and data traffic use the same VC; 2) for each RSVP reservation a separate VC is created, which is destined to consider signalling messages; 3) multiplexing of RSVP signalling messages in a simple established point-to-multipoint VC; and 4) multiplexing of RSVP signalling messages in multiple established point-to-point VCs.
        For the first approach, we can verify that the number of established VCs will be minimum. Its largest advantages are that additional VCs don’t need to be established for each data VC, and there also isn’t latency to the transport of signalling messages, because these follow the same path traversed by the data. But, when data traffic in a VC doesn’t obey its initial QoS specifications, RSVP signalling messages can be discarded together with the data. Other variations of this approach are suggested in [4].
        In the second approach, its main advantage is implementation simplicity. Besides, signalling messages will be reliable with relationship to its delivery, independently of the data traffic conditions. But, one disadvantage caused by an additional VC for signalling messages is its additional latency during the ATM signalling. This approach reduces by half the number of supported data VCs.
        The main advantage of the third and fourth approaches consists in a larger economy of established VCs, at the same time that turns reliable the delivery of signalling messages. Such economy occurs because the use of multiplexing process, while reliability appears due to dedicated VC.
        We can indicate a last aspect related to these four discussed approaches, which is constituted of the QoS that will be attributed to a signalling VC. It is obvious that, in the first approach, signalling messages are subject to data VC’s QoS, but, in the last three that have separated signalling VCs, the QoS attributed to these can be specified. The alternative of using best-effort VCs for the signalling is also possible, but in this case, there is risk of message losses when happen congestions in the ATM network.

        4. QoS Mapping
 

        The goal of this section is to present, in a brief way, the mapping between IIS model services and ATM service classes. Such mapping serves to provide to the IP traffic that traverse an ATM network, an effective QoS end-to-end. Other details and specifications about corresponding services and parameters can be found in [5].
        ATM service classes defined in UNI 4.0 [15] are shown in the table 2. We will assume that the reader has an understanding about each one of them, because to describe them is out of the purposes of this section.

 
Table 2. ATM Service Classes (UNI 4.0)

CBR (Constant Bit Rate)

rtVBR (Real-time Variable Bit Rate)

nrtVBR (Non-real-time Variable Bit Rate)

UBR (Unspecified Bit Rate)

ABR (Available Bit Rate)

 
Table 3. The Mapping between IIS Model and ATM Service Classes (UNI 4.0).

IIS Model	ATM
GS	CBR ou rtVBR
CLS	nrtVBR ou ABR
Best-Effort	UBR ou ABR

        4.1 GS Service over ATM Service Classes

        For GS service, three points should be considered in the creation of corresponding ATM VCs:

1. Data flow could have a variable rate.
2. GS service requires real time characteristics (limited delay).
3. Definition of GS service requires that non-conforming traffic has been considered by the best-effort service.

        4.2 CLS Service over ATM Service Classes
 

        As in the subsection 4.1, the goal here is to discuss the creation of corresponding ATM VCs to the considered service. CLS service is partially tolerant to delays and has variable rate. To satisfy its requirements, the use of the following ATM services is recommended: nrtVBR or ABR.
        As the CBR service doesn’t consider variable rates, this could promote a bad use of resources if used with CLS. For the condition of that, exceded traffic will be treated using a dedicated VC, CBR service satisfies the CLS requirements. The mapping between CLS service and CBR is equivalent to the GS service and CBR.
        For rtVBR service, as this imposes strong restrictions of delay in an ATM network, the establishment of a VC becomes more complex than CLS service demands, and despite of the rtVBR service to satisfy CLS requirements, such combination is not recommended. The mapping between CLS service and rtVBR is equivalent to the GS service and rtVBR.
        As the UBR service doesn’t provide any guarantee, this doesn’t satisfy the CLS service requirements. If the mapping occurs, this should be equivalent to the best-effort service and UBR, as we will see ahead.
        The ATM service class more suitable for the IP best-effort service is UBR. The nrtVBR and ABR classes are also possible options.

        5. VCs Management for RSVP and IIS Model
 

        VCs management consists, basically, in a control process over the mapping between RSVP flows and ATM VCs. It is necessary during RSVP operation, as for signalling messages as for own data flow (with QoS or not), allowing to the senders use different combinations.
        There are two approaches used to manager VCs [4]. In the first, individual VCs (point-to-point or point-to-multipoint) are used to consider a simple reservation, i. e., a simple RSVP flow. Therefore, each reservation can be mapped in one or more VCs. The main advantage of this approach is its low implementation complexity, but, in certain cases, it will need to maintain a great amount of VCs and associated resources.
        The second approach considers the mapping of multiple reservations in collective VCs. A particular case, called aggregation model, considers multiple reservations multiplexed in a simple VC. The main advantage of it is to avoid the signalling latency, because existing VCs are used to transport an any initial traffic. The aggregation model can also be used with point-to-point or point-to-multipoint VCs, and it has as larger difficulty the QoS specification for used VC. For example, for a moderate QoS the number of established VCs can be considerable. Besides, an additional demage would also be the loss, for the ATM network, of the capacity to carry out routing basing in the desirable QoS.
        Along this section, we discuss only the most important aspects involved in the first management approach, because second approach has still been researched and needs deeper studies.

        5.1 Mapping between a RSVP Flow and a Simple VC

        In this scheme, occurs the mapping between a simple VC (point-to-point or point-to-multipoint) and each established RSVP flow. Initially, for a point-to-multipoint VC we can already identify the problem of heterogeneity, when multiple receivers request different QoSs. In this case, such scheme adopts the maximum resource reservation requested by the receivers, doing with that small or nonexistent reservations are bettered.
        With relationship to the dynamic QoS renegotiation for a VC, as we saw in the section 3, an ATM network doesn’t still support such functionality and, therefore, a new QoS for a VC would be obtained with tear down of current VC and the establishment of the new, causing a considerable latency. To avoid the excessive accumulation of signalling messages in the network promoted by consecutive renegotiations, in [4, 16] a timing mechanism with queues is suggested.
        The mapping between a RSVP flow and a simple VC has two advantages: 1) data traffic that traverse the ATM network in a given VC is only, don’t having copies of this traffic in another VCs; and 2) to each receiver of point-to-multipoint VC an identical service is provided. As we can note, such scheme is homogeneous and it doesn’t consider different receivers requesting different QoSs.

        5.2 Mapping between a RSVP Flow and Multiple VCs

        In any RSVP implementation over ATM networks, the support to multiple receivers with different QoSs is necessary, even if ATM doesn’t still contain such functionality. The scheme of mapping a RSVP flow in multiple VCs could be used to provide such heterogeneous reservations of several receivers. In this scheme, we can identify two models: limited heterogeneity model and full heterogeneity model. These will be better discussed ahead and they can be described in [4, 16] with more details.

        5.2.1 Limited Heterogeneity Model

        Limited heterogeneity model adopts the mapping between a RSVP flow in two VCs (point-to-point and/or point-to-multipoint), being one dedicated to consider best-effort traffic and another dedicated to consider QoS traffic. Therefore, receivers of a multicast group are limited either to the best-effort service or to a simple alternative QoS.
        In the figure 1 we can find the illustration of a functional example of this model, where two receivers (R1 and R2) request a best-effort service and two another (R3 and R4) request distinct QoSs. As we can verify, two point-to-multipoint VCs are established, being one destined to consider best-effort traffic (traffic provided to the receivers R1 and R2), and another destined to consider QoS traffic with QoS (traffic provided to the receivers R3 and R4). You can repair that C3 switch will use in the direction of C2 the maximum resource reservation from the reservations of R3 and R4. For this example, only a sender has been considered.

        5.2.2 Full Heterogeneity Model

        Full heterogeneity model adopts the mapping between a RSVP flow in multiple VCs, being one VC established for each requested QoS by one or several receivers of a multicast group, including the best-effort service. Therefore, the number of established VCs is dependent and not limited.
        The figure 2 illustrates an example of such a model. Observe in the figure that receivers R3 and R4 don’t more share the same QoS, having each one of them a dedicated VC.
        The main advantage that full heterogeneity model presents is the fact of providing to a receiver exactly what it asks, but one of the costs of this advantage is the use of a larger amount of network resources. Besides, this model requests that each IP network layer packet be copied to consider all the established VCs, causing a considerable additional traffic in the ATM network, depending on the network topology and size of the receivers group.

        6. QoS Management Architecture

        Integration characteristics of RSVP and IIS model over ATM networks, previously discussed in this paper, were good to show that, for IIS model services, the resource management can be made, for each flow, basing in the scheduling, traffic policing and traffic shaping.
        The QoS management architecture is composed of a QoS manager, through which applications can request network resource reservations along the path traversed by a data flow. It is important we consider that, such architecture should avoid that control messages cause a significant overhead in the connections, damaging the normal user data flow. For this, we will adopt that control data and user data will be transmitted by distinct VCs, also aiding the appearance of another control functions that can be implemented.
        Besides, the QoS manager entity should directly interact with the layers and protocols, dealing with management aspects, such as: management policies, QoS monitoring, QoS adaptation, QoS negotiation and renegotiation. Applications also be able to directly obtain the services provided by the QoS manager, sending requests or obtaining information, as for example: the establishment of a new VC with specific QoS, a dynamic renegotiation for a larger QoS, receiving a notification to reduce the current QoS due to congestion problems, etc.
        The management policies will define which actions and strategies should be taken in the system, with the goal of execute the established rules in its specification. Additional studies still need to be done for a more appropriate and accurate definition of such policies. QoS monitoring process should be simple, without carrying significant overheads, avoiding that management system has low performance. Still, internal monitoring mechanisms will be available detecting QoS violations.
        In the occurrence of QoS violations, management system should achieve the automatic QoS adaptation, trying, whenever possible, to maintain the QoS initially requested by the user, instead of beginning the renegotiation of a degraded QoS (or to abort the session). Such functionality is fundamental to deal with possible changes that can happen in the system, and that perhaps degrade the current user QoS. Besides, if the system cannot recover of QoS violations using the adaptation process, these will be notified to user by the manager, which commands the renegotiation of a degraded QoS, or simply abort the application depending on system conditions.
        With relationship to QoS negotiation and renegotiation processes, the user should be able to use them, interacting with the manager to obtain its desirable QoS. One process can be rejected depending on user’s needs, end system characteristics and network. With the goal of increase the flexibility of management system and to organize the resource distribution, additional characteristics and information could be provided to the user during the execution of these processes.

        6.1 " QoS Manager" Entity

        "QoS manager" entity, included in the QoS management architecture specified in this section, is illustrated in the figure 3. This will has as responsibility, to carry out the following functions:

• To manager local and network resources (network interface buffers and bandwidth, for example) through the cooperation with layers, protocols and other components (socket, network interface driver, IP network layer, etc.);
• To support reservation states and its renegotiations for different existing flows, through the transmission of control messages addressed to the network or a certain application;
• To create, to manager, to modify and to remove reservations, which will be dedicated to the different data flows;
• To manager the mappings or existing associations, as for example, between flows and their reservations, between flows and their VCs, among services of different network technologies, etc;
• To execute traffic shaping and monitoring;
• To control the admission of connections and flows;
• To achieve sophisticated control functions, without demaging the user data flow.

        This new QoS connection establishment phase, demands from manager the execution of a initial actions set, such as: resource reservation (buffers, for example), initiation of reservation state(s) along the connection, execution of an admission control and the necessary mappings, according to the initially traffic specification provided by the application during the connection request.

        If the establishment of requested connection confirms with success, the involved application be able to begin the data transmission. Otherwise, a renegotiation process should commands the interactions between application and QoS manager, with the goal of look for a new solution for the refused connection.
        During the active time of an established connection, the manager is still responsible for:

• To manager the reserved and available resources.
• To achieve traffic shaping and monitoring according to its specification.
• To apply management policies, when necessary.
• To sustain or to renegotiate reservation states.
• To modify or to remove reservations due to an application request.
• To achieve QoS adaptation, when necessary and possible.
• To execute different control functions to, for example, asynchronously notify an application or the QoS manager, etc.

        7. Conclusion

        Along this paper, one of the discussed points was RSVP protocol and IIS model operation on ATM networks, presenting its main characteristics and describing the points that need more complete studies. Three main points were described: signalling, QoS mapping and VCs management. They are part of a proposed work, which involves the specification of a QoS management system over ATM networks, and that should use the RSVP functional structure to reach its goals.
        For ATM signalling, a larger likeness with RSVP would be reached starting from the support to the two functionalities: to provide heterogeneous QoSs for different receivers of a same multicast group and to allow dynamic QoS renegotiation in existing VCs. The first functionality appears due to parameters like cost, for example, and it can be supported by two models: limited heterogeneity model and full heterogeneity model. On the other hand, dynamic QoS renegotiation occurs with the creation of a new VC and posterior releasing of current one. However, these methods present some inconveniences for both functionalities, being necessary to suggest modifications in ATM signalling, in such a way that it supports as much the establishment of heterogeneous VCs as renegotiating QoS parameters in a VC (point-to-point and/or point-to-multipoint).
        RSVP signalling can be made by dedicated VCs or not, depending on the demanded reliability for its messages. As last signalling aspect, we should consider that UNI 4.0 [9, 15] allows that point-to-multipoint VCs accept receivers without need to notify the sender. This capacity, called Leaf Initiated Join (LIJ), is the first effort toward a better integration with RSVP, but the above issues stay without solution as yet.
        During the section 4, about the QoS mapping, we tried to present as IIS model services can be mapped in ATM service classes for UNI 4.0. We noted that a great number of combinations is possible, but not all them are recommended because determinate requirements are not carry out.
        Besides, we can adopt a different functional point of view, verifying the occurrence of another type of mapping, now among RSVP flows and ATM VCs. Such mapping, approached in the area of VCs management, it is applied as much to user’s data as to signalling messages, helping, in some cases, temporarily to avoid the heterogeneity problem. Several VCs management policies can be implemented, determining if a RSVP flow must be mapped on a new VC or on a pre-existing VC. Other information about this subject are available in [2, 3].
        Therefore, our next actions will be taken in the attempt of specifying the functional blocks that compose the " QoS Manager " entity (illustrated in the figure 3), to define which management policies are necessarily applied to the different cases, and also to indicate possible implementation problems that should be avoided. Besides the aspects discussed in this paper, another important factor, that it has contributed in the choice of RSVP protocol for the proposed management system, is its flow oriented conception. As this offers a scalable context, the management system can have a better control of the network and of its applications, when necessary.

Acknowledgements: I gratefully acknowledge to FAPESP (Fundação de Amparo à Pesquisa do Estado de São Paulo – Foundation for Assistance in Reserach of São Paulo State) by the financial support.

        8. References

[1] M. Santos, L. Kiatake, F. Meylan. S. Kofuji and J. Courtiat. Simulation and Analysis of IP/ATM Switching and Routing. Accepted at 2th IEEE International Conference an ATM – ICATM99, January 1999, France.

[2] L. Berger. RSVP over ATM Implementation Requirements. RFC 2380, August 1998.

[3] L. Berger. RSVP over ATM Implementation Guidelines. RFC 2379, August 1998.

[4] E. Crawley, L. Berger, S. Berson, F. Baker, M. Borden and J. Krawczyk. A Framework for Integrated Services and RSVP over ATM. RFC 2382, August 1998.

[5] M. Garret and M. Borden. Interoperation of Controlled-Load Servive and Guaranteed Service with ATM. RFC 2381, August 1998.

[6] A. Guelfi. Um Estudo sobre Aplicações Multimídia em Redes ATM. Dissertação de Mestrado, Universidade Federal de Santa Catarina, Junho 1998.

[7] F. Meylan, L. Kiatake, M. Santos, S. Kofuji and J. Courtiat. An Experimental Study for Transmitting MPEG-2 Streams over ATM Networks. Presented at the 1^st IEEE International Conference an ATM – ICATM98, June 22-24, 1998, Colmar, France.

[8] M. Laubach. Classical IP and ARP over ATM. RFC 2225, April 1998.

[9] M. Maher. ATM Signalling Support for IP over ATM – UNI Signalling 4.0 Update. RFC 2331, April 1998.

[10] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin. Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification. RFC 2209, September 1997.

[11] S. Shenker, C. Partridge and R. Guerin. Specification of Guaranteed Quality of Service. RFC 2212, September 1997.

[12] J. Wroclawski. Specification of Controlled-Load Quality of Service. RFC 2211, September 1997.

[13] J. Wroclawski. The Use of RSVP with IETF Integrated Services. RFC 2210, September 1997.

[14] G. Armitage. Support for Multicast over UNI 3.0/3.1 Based ATM Networks. RFC 2022, November 1996.

[15] The ATM Forum. ATM User-Network Interface (UNI) Signalling Specification, Version 4.0. July 1996, Available at ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps.

[16] S. Berson. IP Integrated Services Support in ATM. Internet Draft, June 13, 1996.

[17] A. Demirtjis, S. Berson, B. Edwards, M. Maher, B. Braden and A. Mankin. RSVP and ATM Signalling. ATM Forum Contribution 96-0258, January 25, 1996.

[18] D.J. Mitzel, D. Estrin, S. Shenker and L. Zhang. An Architectural Comparison of ST-II and RSVP. Proceedings of Infocom’94, June 1994.