RSVP to ATM SVC Mapping: test specification
version 1.6, Mar 25 1999
Editor: Tiziana Ferrari, INFN-CNAF
Contributors: P.Fasano (CSELT), T.Ferrari (INFN-CNAF)

1. Participants

EPFL (CH), SWITCH (CH), GRNET (GR), GARR/INFN (IT), RedIRIS (SP), Dante (UK)

2. Introduction

The goal of this experiment is to verify if the integration of the IP and ATM QoS mechanisms is viable and applicable for the support of applications devised by the academic and research community. The interest in this type of integration is many fold:
  1. It fits the TEN-155 network infrastructure and type of traffic, since the backbone is ATM based and applications are IP based.
  2. For some NRNs the access to the backbone is IP based, but with the integration of ATM and RSVP applications may still make use of the ATM QoS features in the backbone, while the access to the backbone is through RSVP.
  3. According to the TEN-34 test programme results, SVCs can be deployed in a wide area ATM network and RSVP is now supported by several vendors, also the protocol standard development process has now reached its maturity.
  4. It gives the possibility to make use of the ATM QoS features (even if limited to the backbone of the network) to a wider range of user applications.
Since the ATM QoS features need the support of the ATM signalling protocol in the backbone, the pre-requisite of this test is the existence of a stable ATM overlay network with UNI access points at the edge, or, if possible, supporting PNNI in the backbone. This implies the need of dedicated VPs for the tunnelling of signalling protocol until the SVC service will not be offered in the backbone.

ATM QoS features vs RSVP

ATM QoS and RSVP are complementary to many respects.
In the first place, ATM relies on dedicated circuits and offers a very rich variety of QoS parameters. The disadvantage of this approach is that in order to benefit from it, the ATM signalling support is required and end-system must be natively connected to an ATM infrastructure. In addition, only few applications can use ATM natively.
On the other hand, RSVP does not require a specific type of layer 2 technology (it runs on top of IP), so it's more flexible. Three different QoS services are available with RSVP: best-effort, controlled-load and guaranteed.
The effective deployment of RSVP in TEN-155 requires a mapping scheme to ATM since the IP-based QoS guarantees depend on the traffic conegestion at the ATM layer (the production network is based on UBR connections, which means no guarantees at the ATM layer).
The problem of the RSVP-ATM mapping is challenging for some reasons (see RFC 2382).
  1. RSVP is receiver oriented (because the reservation request is issued by the receiver), while ATM signalling is sender oriented (the connection set-up request is issued by the sender and forwarded hop by hop to the receiver).
  2. RSVP reservations are based on "soft states", i.e. reservations need not to be explicitly torn down (they timeout) and their profile can be dynamically updated through re-negotiation. On the other hand, ATM connections have an "hard state".
  3. In RSVP connection set-up and data transfer are not separated, since data, PATH and RESV messages are issued in parallel. On the other hand, in ATM the data transfer phase starts only after the connection set-up acknowledgement is received and consequently ATM connections are rather delay sensitive.
  4. There is no straightforward mapping between the Integrated Services and the ATM classes of service. In particular, RSVP QoS services are mostly defined in terms of delay, while the ATM classes are defined in terms of bit rate.
Most of these issues have been recently addressed by the IETF working group issll with a set of   RFCs.
The integration of RSVP and ATM is relevant subject which appears in several test programmes devised for Academic and Research backbones (see a for example the vBNS network test programme).

3. Proposal

The mapping of the RSVP signalling to the ATM signalling can be tested in two different scenarios:
  1. RSVP to ATM SVC mapping in a transit router (for example in the connection point between an edge RSVP could, e.g. a NRN test network, and the TEN-155 overlay network)
  2. RSVP to ATM SVC mapping both in the end-system and in routers.
In both cases a preliminary phase of tests will be run in laboratory.

Test applications

Tentative list:
  1. RSVP capable traffic generators using configurable traffic profiles (mgen, netperf -RSVP aware version-);
  2. RSVP capable videoconferencing tools;
  3. Mcast: RSVP aware MPEG1/MPEG2 video streaming for Winsock2 platforms (Uni. of Athens);
  4. Condor: a high throughput computing application based on the configuration of distributed remote clusters of CPUs to be used by batch jobs developed at the Computer Science department of the Wisconsin University;
  5. MONARC (Models of Networked Analysis at Regional Centres for LHC Experiments): a CERN project for the test of performances of a distributed object-oriented databases used for data analysis in the high energy physics experiments.

Test phases

3.1. FIRST SCENARIO: RSVP-ATM mapping only in the router

In this scenario the router gives the IP-based application the opportunity to take advantage of the capabilities of the core ATM network.
In the transport router the Rspec parameters are mapped into the ATM UNI QoS parameters. In addition, after the virtual circuit set-up phase, the VPI/VCI numbers used to send the flow packets through the TEN-155 ATM cloud are added to the flow state information in the transport router. During the ATM connection establishment IP packets cross the ATM cloud through a permanently configured best-effort PVC or through a best-effort SVC. After the connection set-up completion the IP packets will be switched to the SVC. The same connection is also used by the RSVP PATH messages. If the SVC is a two way connection (the reverse has been set up), then the PATH messages will use this SVC in both ways, otherwise the RSVP messages will keep using the best-effort PVC.

Admission control relies on the result of both the initial RSVP Call Admission Control and the CAC on the boundary between the IP and ATM cloud.

The interoperability between RSVP re-negotiation and ATM connection profile re-negotiation is another interesting issue to be investigated.

Network configuration
Figure 1: RSVP to ATM SVC mapping only in the routers
SW and HW requirements
  1. an overlay ATM network with ATM signalling tunnelling and with UNI access points, if possible supporting PNNI;
  2. RSVP aware applications and a set of end-systems whose operating systems implement the RSVP protocol;
  3. a set of traditional RSVP capable routers on the path from the end node to the transit router;
  4. RSVP capable transit routers (at least two of them) which implement the RSVP ATM mapping. They need ATM interfaces and an ATM connection to TEN-155. The routers need to implement per VC shaping in order to inject traffic according to the QoS requested at connection set-up.
Candidate platforms
Tentative list:
  1. CISCO
  2. Telebit
  3. IBM
  4. Torrent (but not available yet)

3.2 SECOND SCENARIO: RSVP-ATM mapping both in the router and in the end-system

In this second scenario the RSVP-to-ATM mapping functionality is be implemented both by the routers which interconnect the LIS (Logical IP Subnets) into which the test network is divided and by the ATM drivers of the end-systems (which have a native ATM connection to the router of the LIS they belong to).
The testbed can be divided into several LIS, for example one for each NRN and one for the TEN-155 backbone, each interconnected through a router which implements the RSVP-to-ATM mapping. The resulting ATM connectivity is made of several hops, as illustrated by the network configuration in  figure 2.
Network configuration with multiple LIS
Figure 2: RSVP to ATM SVC mapping both in the routers and in the end-systems
Initially a best-effort ATM SVC is used by the source to transfer both data (for example an audio and a video stream) and RSVP messages to the first router. Data and RSVP messages are transparently carried through a best-effort SVC which traverses several LIS and ends up in the destination host. A best-effort ATM connection is also used by the destination to send back RESV messages. If the CAC succeeds, n dedicated SVCs are set-up, where n is the number of flows generated by the source.
The QoS parameters of each SVC depend on the IP flow characteristics specified by the source through the RSVP parameters.
In order to put the equipment to test, generate more sources/receivers can be added to background traffic.
Network configuration with a single LIS
A simpler network configuration is the one in which just one LIS is configured. In this case, as illustrated in figure 3, the RSVP to ATM SVC mapping functionality needs to be supported only in the end-systems. This network configuration is intended only for the debugging of the mapping in the end-systems.
Figure 3: single LIS, RSVP to ATM SVC mapping only in the end-systems
SW and HW requirements:
  1. RSVP capable applications, for example VIC and VAT, or classical IP applications supported by SMR (see below) or by other equivalent tools;
  2. end-systems mounting modified ATM drivers which are able to map RSVP parameters into ATM parameters
  3. best-effort traffic generators
  4. RSVP-to-ATM mapping capable routers
  5. ATM network interfaces for end-systems and routers capable of per VC shaping
  6. ATM switching capable of per VC shaping
  7. ARP servers.
If no per VC shaping functions are supported by each ATM device on the path between source and destination, then no real QoS monitoring tests can be performed: the test is limited to a protocol functionality analysis.
Candidate end-system platforms
Tentative list:
  1. Solaris 2.5 and 2.6 with Session Monitor and Reservation [SMR]: developed at CSELT (Centro Studi E Laboratori Telecomunicazioni), Italy, it is an "interactive console aimed to generate RSVP messages for every kind of application". Through a graphic interface SMR generates reservations on behalf of any IP application. Specific Tspec and Rspec parameters can be set manually or automatically through SMR. For each platform a single istance of SMR controls and monitors all the RSVP sessions running. SMR can be applied in a simple RSVP environment and in a combined RSVP-ATM environment. SMR also supports some reservation monitoring functions both at the IP and ATM layer.

    2. SMR provides an interface between the RSVP module and the ATM device driver. i.e. it maps RSVP to UNI 3.1 signalling and vice versa.

    HW and SW requirements:

    1. Sun workstations running Solaris 2.5 and 2.6 and with FORE ATM adapters. The current SMR prototype requires the support of a modified version of the ATM Fore Device driver for Solaris 2.5 and 2.6. As the current Fore ATM device driver versions do not support traffic shaping (best-effort traffic is injected into non-UBR SVCs), the traffic must be shaped by an ATM switch or by the ATM interface of the router in the LAN. For this reason the current SMR implementation does not give the possibility to study the QoS RSVP - ATM interoperability issues, apart from the protocol functionality.
    2. SRM installed on senders, receivers and, optionally, on the router, if the routing functions are implemented by a workstation;
    3. UNI 3.1;
    4. ATM equipment (switch or ATM interface for router) implementing traffic shaping or any equivalent technical solution to inject shaped traffic into the TEN-155 backbone;
     
  2. Linux: under development at EFPL.

3. Summary

3.1 Type of required equipment
  1. 1st SCENARIO
    • - routers
  2. 2nd SCENARIO
    • routers
    • ATM switches (in ATM edge clouds)
    • ATM NICs
3.2 Capabilities
  1. 1st SCENARIO
    • RSVP capable applications or devices generating RSVP messages on behalf of traditional non RSVP capable applications
    • RSVP capable routers in the access networks
    • RSVP to ATM SVC mapping capabilites in the border routers
    • ATM signalling capabilities in the border routers
    • per VC shaping in the ATM interfaces to the TEN-155 overlay of network in the border routers
    • ARP server/s
  2. 2nd SCENARIO
    • all the requirements previously defined plus
    • end-systems running operating systems which support the RSVP to ATM SVC mapping functionality
    • ATM NICs in the end-systems supporting UNI
    • ATM NICs and ATM switches supporting per VC shaping
    Reference documents:
    • RFC 2379: RSVP over ATM ATM Implementation Guidelines
    • RFC 2381: Interoperation of Controlled-Load Service and Guaranteed Service with ATM
    • RFC 2382: A framework for Integrated Services and RSVP over ATM
    • RFC 2380: RSVP over ATM implementation requirements
3.3 Reference equipment
  1. 1st SCENARIO
    • routers: CISCO, IBM, Telebit, (Torrent)
  2. 2nd SCENARIO
    • Solaris 2.5 or 2.6 workstations running SMR and mounting FORE Runner ATM adapters (SMR)
    • Linux
    • routers: see previous scenario
3.4 Schedule
First QTP semester, after the ATM SVC test

3.5 Number of kits 3.6 Location/management
  1. 1st SCENARIO
    • edge RSVP cloud routers: participants, probably sharable
    • RSVP-to-ATM routers: participants or backbone, prob. not sharable
    • end-systems: participants, sharable
  2. 2nd SCENARIO
    • end-systems: participants, sharable
    • edge cloud ATM switches: participants, sharable
    • RSVP-to-ATM routers: participants and/or backbone, prob. not sharable
3.7 Infrastructure requirements
  1. ATM signalling tunnelling (UNI or PNNI tunnelling) or signalling service if available
  2. DBR VPs for establishement of QoS ATM SVCs
  3. SBR (UBR) VPs for establishment of best effort SVCs
  4. per VC shaping
  5. minimum VP bandwidth 2 Mbps, if possible, bandwidth in the range [2, 15] Mbps

4. Bibliography

  1. Integrated Services over Specific Link Layers (issll),  working group home page
  2. RFC 2379: RSVP over ATM Implementation Guidelines; L. Berger.
  3. RFC 2381: Interoperation of Controlled-Load Service and Guaranteed Service with ATM; M. Garrett et al.
  4. RFC 2382: A Framework for Integrated Services and RSVP over ATM; E. Crawley et al.
  5. RFC 2380: RSVP over ATM Implementation Requirements; L. Berger.
  6. C.Song, L.Cunningham, R.Wilder;

    7. Quality of Service Development in the vBNS, IEEE Communications Magazine, May 1998.
  7. Integraed Services over ATM Experiments; http://carmen.cselt.it/isatm-exp/index.html
  8. Schill A., Kuehn S., Breiter F.; Internetworking over ATM: Experiences with IP/IPng and RSVP, 7th Joint European Networking Conference, Budapest, Hungary, 1996.