Supporting IP Multicast Integrated Services in ATM Networks - CiteSeerX

Supporting IP Multicast Integrated Services in ATM Networks

L. Salgarellia, A. Corghia , H. Sanneckb and D. Witaszekb a CEFRIEL/Politecnico di Milano via Fucini 2 I-20133 Milano Italy b GMD-FOKUS Kaiserin-Augusta-Allee 31 D-10589 Berlin Germany

ABSTRACT

This paper presents an integrated, server-based mechanism for the ecient support of the IP Integrated Services (IIS) model in ATM networks, namely the Multicast Integration Server (MIS) architecture. Instead of viewing IP-ATM multicast address resolution and QoS support separately, the approach in this paper is to consider such issues in an integrated manner. The Multicast Integration Server is capable of IP Multicast to ATM NSAP address resolution using the EAsy Multicast Routing THrough ATM clouds (EARTH) protocol, as well as of QoS management using the Resource ReSerVation Protocol (RSVP). With the use of EARTH, several ATM point-to-multipoint connections with dierent QoS parameters can be associated to a single IP multicast address. An RSVP server within the MIS is used to distribute RSVP messages inside the ATM cloud and to set the corresponding QoS state in the address resolution table of EARTH. In addition, this paper de nes a quantized heterogeneity model which supports, together with the MIS, advanced IIS features as QoS heterogeneity and dynamic QoS changes in IP-ATM networks. Keywords: IP, ATM, RSVP, EARTH, integrated services, multicast

1. INTRODUCTION

The ecient support of the IP Integrated Services architecture (IIS ) in ATM networks is nowadays a challenging research topic in the internetworking area. The IIS architecture is based on the Resource Reservation Protocol (RSVP ). RSVP is the signalling by which end-users request to the network QoS for their data ows. Following the IP multicast model, IIS and RSVP rely on a receiver-oriented model, where a receiver is not only capable of deciding whether to join or leave a multicast sessiony, but is also allowed to choose the associated QoS independently from the other participants. In this sense, IIS and RSVP support QoS heterogeneity. In addition, for better eciency, RSVP includes sophisticated reservation mechanisms, allowing receivers to request for wildcard resource reservations, where groups of senders are entitled to use the same reserved resources, and dynamic QoS changes. Trac description parameters de ned by the IIS assume all Internet trac to be bursty, while the key QoS parameters are supposed to be the end-to-end delay and the minimum guaranteed bandwidth. Admission control, authentication and policy mechanisms are supposed to complete the IIS architecture. The ATM service model is sender-oriented: the originating node of a multipoint session is the only entity allowed to add or delete leaf nodes. No multicast addresses are foreseen by currently implemented ATM standards (UNI 3.0/3.1, Q.2931 ), thus senders have to know the unicast addresses of all the relevant receivers. In addition, the originating node sets the QoS of the session, which is unique for all the receivers. A plenty set of trac and QoS parameters are de ned for both UNI 3.1 and Q.2931, for several classes of service, ranging from the Constant Bit Rate (CBR) to the Unspeci ed Bit Rate (UBR). 1

2

3,4

5

This work was partially funded by the EEC as part of the ACTS project AC012 MULTICUBE. Additional author information: L.S.: Email: [email protected]; Telephone: +39-2-23.954.257; Fax: +39-2-23.954.254. A.C.: Email: [email protected]; Telephone: +39-2-23.954.1; Fax: +39-2-23.954.254. H.S.: Email: [email protected]; Telephone: +49-30-34.637.175; Fax: +49-30-34.638.175. D.W.: Email: [email protected]; Telephone: +49-30-34.637.348; Fax: +49-30-34.638.348. y A set of the IP address space is dedicated to Multicast addresses, also known as class-D addresses. End-hosts join or leave class-D addresses by means of the IP Group Management Protocol (IGMP). Packets sent to a given class-D address are replicated and delivered to receivers who joined that multicast address.

To appear in Proc. of SPIE Voice&Video'97, Broadband Networking Technologies

1

Several works highlighted how the ecient integration of IIS and IP Multicast with ATM faces several problems, from the mapping of the service classes, to the management of data and of control Virtual Channels (VCs), and nally to the integration of the service models. This paper introduces an integrated, server-based approach to the problem of the integration of IIS and IP Multicast with ATM networks, namely the Multicast Integration Server (MIS) architecture. Within a given ATM cloud, the Multicast Integration Server is responsible for IP Multicast to ATM NSAP address resolution, using the EARTH protocol, and for QoS management, using RSVP. For each multicast session, the Multicast Integration Server controls both EARTH and RSVP protocol messages, attending to the distribution of session information among the participants. In addition, a quantized heterogeneity model for the ecient support of QoS heterogeneity in ATM networks is proposed. The paper is organized as follows: after section 2, which introduces issues and known solutions to the problem of IIS/IP Multicast-ATM integration, section 3 describes the Multicast Integration Server architecture, together with the quantized heterogeneity model. Section 4 highlights the bene ts of our solution. Open issues are analyzed in section 5, while section 6 concludes the paper. 6{10

11

2. IP MULTICAST INTEGRATED SERVICES IN ATM NETWORKS: BACKGROUND

The development of IP Integrated Services over an ATM network can be exploited only by an ecient merging of the advanced capabilities provided by the ATM link-layer with the enhanced features of the IIS architecture. On one side, IP multicast communication should be able to exploit the data replication capabilities oered by ATM hardware. This is possible by mapping IP multicast sessions into (a set of) ATM point-to-multipoint channels: for this reason, a mechanism for the resolution of IP Multicast addresses to ATM NSAP addresses must be developed. On the other side, the IP Integrated Services mechanisms should be able to take advantage of QoS features provided by the ATM infrastructure.

2.1. IP Multicast over ATM

The IP Multicast service model is receiver-oriented: hosts who want to participate in a multicast session as receivers join the related IP class-D address. The IP Multicast architecture takes care of distributing data sent to the classD address to receivers who joined it. Senders do not even care about the unicast addresses of receivers. On the contrary, ATM embraces a sender-oriented philosophy: only the senders are able to establish new VCs, to add or delete receiversz. However, the most ecient mechanism to transport IP multicast data ows in ATM networks is exactly to involve ATM point-to-multipoint channels, thus enabling the use of ATM hardware fabric for data replication. Hence the need for a mechanism for the translation of IP class-D addresses to a set of ATM NSAP addresses, which are used by senders to open point-to-multipoint channels towards the receivers of a multicast session. Currently, the IETF standard for IP-ATM multicast address resolution is the Multicast Address Resolution Server (MARS ). The MARS solution follows a hard-state approach, and retains the separation of LIS'sx connected by IP multicast routers. One MARS serves one LIS for both IP unicast and multicast address resolution. Bypassing routers for inter-LIS communication would require coordination of multiple MARS's and could congest the network. Another approach is followed by the EARTH (EAsy IP multicast Routing THrough ATM clouds) protocol, published as a draft in the ION{ working group of IETF. EARTH, in contrast to MARS, allows ecient shortcuts for multicast connections and separates address resolution for IP unicast and multicastk . In addition, EARTH supports a soft-state approach and ATM QoS features. EARTH introduces the concept of MLIS (Multicast Logical IP Subnet), spanning a whole physical ATM network (ATM cloud) and served by a single EARTH server. The EARTH's shortcuts for multicast trac inside the MLIS, bypassing edge routers on the borders between LIS's, help to achieve better performance in terms of join/leave latency and better eciency in the multicast distribution tree (MCT) establishment . 12

13

11

z These considerations refer to the ATM-Forum UNI 3.1 speci cation. x Logical IP Subnet (Classical IP over ATM approach). { ION - Internetworking over NBMA (Non-Broadcast Multiple Access). k The unicast IP addresses are resolved by contacting the regular ATM-ARP

server, while for multicast addresses the EARTH server is queried. The MCT is the routing tree established by Inter Domain Multicast Routing (IDMR) protocols in order to replicate and distribute IP packets towards the receivers of a multicast session.


2

ATM cloud (MLIS)

EARTH_join EARTH_join

LIS A

LIS B

EARTH_request EARTH_request Sender

Receiver 1

Receiver 4

EARTH Server Receiver 3

Receiver 2 EARTH_multi EARTH_multi

Multipoint data VC Point-to-point control VC

Figure 1. Distribution of basic EARTH messages within the MLIS. As shown in gure 1, a potential receiver of an IP multicast ow, whatever unicast LIS it is located in, sends its registration messages (EARTH join) within a given refresh period to the EARTH server with its own IP and ATM addresses, and optionally the requested source of the multicast trac. A sender, or a re-sender (MRouter)yy of a given IP multicast group, periodically queries the EARTH server with EARTH request messages in order to get the membership information. The EARTH server answers with the EARTH multi message, containing the NSAP addresses of all receivers registered for a requested source. The sender keeps its local cache of the membership information, and is thus capable of opening and dynamically managing the set of point-to-multipoint connections to the receivers. EARTH messages and data-structures oer full support for QoS connections. In particular, source speci c QoS requested by receivers can be registered within the EARTH server's address resolution table (MARPTable), either by means of a reservation protocol (RSVP), by network management mechanisms or manually by a network operator. Senders examine QoS information retrieved together with membership information, and are thus capable of opening both best-eort and QoS point-to-multipoint connections, depending on receivers' requests. Senders notify the EARTH server about the success or failure in the opening of a new QoS connection, using the EARTH QoS notify message.

2.2. IP Integrated Services over ATM

Existing work in the area of IIS over ATM focuses mainly on two problems: the mapping of IIS services to ATM services and the mapping of RSVP over ATM signalling. Current standards for ATM signalling oer wide sets of parameters for de ning trac pro les, QoS requirements and characteristics of the services. This gives several options for mapping IIS services to ATM services, and thus this problem can be considered as almost solved. On the other hand, the problem of mapping RSVP to ATM signalling is crucial, because it deals with the possibility to support IIS over ATM enabling ATM shortcuts for transporting QoS IP ows. In this case, the diculties arise from the dierent service models adopted by IIS and ATM: while the former is receiver-oriented and supports QoS heterogeneity and dynamic QoS renegotiation, the latter is sender-oriented and supports only homogeneous and static QoS. Several works have proposed dierent mechanisms capable to handle RSVP over ATM signalling. The one described in [8] provides RSVP-driven shortcuts capabilities to ATM networks, with minor changes to RSVP. In this case, it is possible to transport RSVP ows with QoS point-to-multipoint VCs, but neither dynamic QoS renegotiation nor QoS heterogeneity are supported. In addition, even if ATM shortcuts are provided for data- ows, RSVP messages are still transported hop-by-hop within each ATM cloud. Another approach has been taken by other works. In particular, [6] focuses on ecient support of advanced RSVP capabilities, such as QoS heterogeneity and dynamic QoS renegotiation. That paper proposes a full heterogeneity model, where in order to support QoS heterogeneity a sender should open a single VC for each QoS level required by any receiver. This would raise 10,14,8

8,9,6,15

14

yyAn MRouter, interconnecting the MLIS at the IP layer with another network, can act as a re-sender for trac coming from a sender which is located outside the MLIS.


3

ATM cloud (MLIS) LIS A

LIS B

Sender

Receiver 1

Receiver 4

Multicast Integration Server Receiver 3

Receiver 2 Multipoint data VC

EARTH & RSVP protocol messages

Point-to-point control VC

Figure 2. The Multicast Integration Server architecture. scalability problems due to the number of ATM VCs needed to support a given multicast session, and would not involve ATM point-to-multipoint enhanced capabilities, with data replication performed by the hardware fabric of the switches. Alternative solutions are proposed in the same paper. For example, the limited heterogeneity model foresees the use of a single point-to-multipoint VC for the best-eort trac and a single point-to-multipoint VC for QoS trac. In this case, apart from the best-eort class of service, only one homogeneous QoS class is provided for a given multicast session. In this paper, we propose a new model for supporting QoS heterogeneity in IP-ATM networks, namely the quantized heterogeneity model, de ned in section 3.2..

2.3. Motivation for the Multicast Integration Server

Known solutions for the integration of IIS and IP Multicast with ATM treat multicast address resolution and QoS support issues separately. This raises eciency, scalability and resource consumption issues, and would force either to adopt a reduced set of capabilities for the IP Integrated Services over ATM (e.g. without support to QoS heterogeneity or dynamic QoS renegotiation), or to improve the current ATM signalling in order to meet speci c IIS needs. On the contrary, the approach in this paper is to consider both IP-ATM address resolution and QoS support issues in an integrated manner. By the merging of a layer-3 protocol as RSVP and a layer-2 protocol like EARTH, we design a generalized, integrated and server-based approach for providing shortcuts for both best-eort and QoS multicast ows in IP over ATM networks.

3. THE MULTICAST INTEGRATION SERVER ARCHITECTURE

The Multicast Integration Server (MIS) architecture aims at an ecient merging of the advanced capabilities of the link-layer (ATM) and the network-layer (IIS). The MIS integrates the EARTH architecture for layer-2 multicast address resolution and the RSVP protocol for support to layer-3 QoS in an IP-ATM network. The MIS architecture can eciently implement advanced IP-ATM service models, as the quantized heterogeneity de ned later in section 3.2..

3.1. Introduction to the MIS

The Multicast Integration Server is a specialized node on an ATM cloud (MLIS in EARTH terminology). A MIS is composed of an EARTH server, for IP class-D to ATM NSAP address resolution and layer-2 QoS management, and of an RSVP server, for layer-3 QoS management. The address of the MIS is a well-known address to every IP node on the MLIS. Each participant in an IP Multicast session within the MLIS, either sender or receiver, opens a control VC to the MIS. The control VCs are used to exchange EARTH and RSVP protocol messages between IP nodes and the MIS, as shown in gure 2. On one side, EARTH protocol messages are exchanged between EARTH clients (IP end-systems) and the EARTH server on the MIS for resolving IP class-D addresses to ATM NSAP addresses dynamically. On the other side, RSVP protocol messages are exchanged between RSVP daemons (IP end-systems) and the RSVP server on the MIS, for To appear in Proc. of SPIE Voice&Video'97, Broadband Networking Technologies

4

QoS level 2

ATM cloud (MLIS)

QoS level 1

LIS A LIS B

Sender

Best-effort

Receiver 1 Receiver 6

Receiver 2 Receiver 5 Receiver 3 Receiver 4

Figure 3. Quantized heterogeneity model. distributing information about the requested QoS. In particular, PATHy messages are sent from sender(s) to the MIS, where the RSVP server processes, replicates and forwards them to receivers. At the same time, all reservations (RESVz messages) within the MLIS are sent to the MIS, merged and forwarded to the sender(s). This server-based model, where the RSVP server within the MIS acts as a dispatcher of protocol messages, contrasts with the usual RSVP distributed processing adopted on conventional IP networks (see also [17] for a server-based approach to enforce reservations on shared/switched Ethernet). Note that MIS operations are concerned only with the management of control messages (EARTH and RSVP). The MIS itself is not a MultiCast Server, and has nothing to deal with data distribution, that is performed by the standard ATM infrastructure by means of point-to-multipoint VCs. 12

3.2. MIS service model: the Quantized Heterogeneity model

Although any service model for IIS over ATM can be eciently supported by the MIS architecture, in this paper the quantized heterogeneity (QH) model is proposed as the advanced service model oered by the MIS. The QH model represents a compromise between the full and the limited heterogeneity models, by supporting a limited number of QoS levels, including the best-eort class, for each multicast session. Since every ATM point-to-multipoint VC is related to a single QoS level, a limited number of ATM point-to-multipoint VCs per session are allowed. As shown in gure 3, each sender of a multicast session can open one best-eort point-to-multipoint connection and a limited number of QoS point-to-multipoint connections with dierent QoS characteristics. As a consequence, every receiver can choose the desired QoS level only among the allowed ones. The best-eort point-to-multipoint connection guarantees that each receiver can always join a multicast group even if no resources for a QoS connection are available, as required in [6]. The QH model does not de ne any guideline for the management of information about the allowed QoS levels in a multicast session. Moreover, it does not pose any constraint about the strategy that must be followed in the allocation of a given data stream on the ATM VCs. As we will describe in the next sections, the QH model can be eciently integrated in the MIS architecture using the Multicast Integration Server in order to manage (i.e. to de ne and distribute) information about the allowed QoS levels. 6

y PATH messages carry a description of the sender's data stream (SENDER TSPEC object). An ADSPEC16 object may be included, which carries additional information (e.g. delay estimates) and can be updated by every IIS-aware network element along the path from sender to receivers. z RESV messages carry QoS requirements of receivers.


5

ATM cloud (MLIS) LIS A

LIS B

PATH message with the original Traffic Descriptor plus the allowed QoS levels

Sender

Receiver 1

PATH message with a single Traffic Description Sender parameter

ATM cloud (MLIS)

Receiver 1

Receiver 4

Multicast Integration Server

Receiver 4

Multicast Integration Server Receiver 3

Receiver 3

Receiver 2

Receiver 2

Multipoint data VC

PATH messages

Multipoint data VC


RESV messages


(a) Distribution of PATH and RESV messages within the MLIS.

PATH messages

(b) Processing of PATH messages at MIS.

Figure 4. Distribution of RSVP messages within MLIS.

3.3. MIS: joint operation of RSVP and EARTH

In a given ATM cloud, an RSVP server and an EARTH server cooperate within the MIS in order to provide ecient IP Multicast Integrated Services. Following the quantized heterogeneity model, the MIS can provide a limited number of QoS levels for senders' point-to-multipoint data VCs to each multicast session. While the EARTH server in the MIS works following the standard operations described in section 2.1, the RSVP server collects all trac speci cation messages (PATH) and reservation messages (RESV) and re-distributes them towards the participants in the session (cfr. gure 4(a)). The RSVP server in the MIS can enforce administrative policies, in particular about the allowed QoS-levels in every multicast session: as shown in gure 4(b), information about allowed QoS-levels can be appended to PATH messages in the MIS before redistributing them to receivers. We argue that capacity-based admission control is a layer-2 issue. Considering ATM that means: trying to setup a new VC or to add a leaf to an existing VC. Success or failure are beyond the control of the layer-3 setup protocol (RSVP). Therefore the MIS implements a mechanism for remote capacity admission control, including conversion of QoS information from layer-3 to layer-2 format and actual setup of layer-2 data paths through EARTH. In the following part of this section, we present the detailed operational model of the entire architecture ( gure 5), highlighting the issues relevant to layer-3 (IP) with respect to those relevant to layer-2 (ATM), and identifying the inter-relations between EARTH and RSVP. After the preliminary phase, where receivers join the multicast session by registering their NSAP addresses to the EARTH server in the MIS (phase 0), and senders retrieve such information, as described in section 2.1, operations go on as follows: Layer 3: The RSVP daemon in the sender, or re-sender (MRouter), sends PATH messages towards the MIS (phase 1). If the sender transmits a multi-layer data stream (refer to section 4.2), the information about the pre-de ned QoS levels must be included in the PATH message (in an ADSPEC object), e.g. using the Hierarchic Token Bucket Tspec. At the MIS, PATH state is established and, if the sender did not decide on the QoS levels, an ADSPEC with pre-con gured ATM QoS levels is appended. Then the PATH message is replicated and forwarded to registered receivers (phase 2). Receivers send RESV messages upstreamx (phase 3). The RSVP server at MIS performs policy admission control and RESV state is established, but no RESV message is yet forwarded upstream (pending 18

x upstream

- from receiver to sender.


6

(Re-)Sender 8: RESV

MIS

8: RESV_ERROR (MIS) 1: PATH

Receiver 4/6: RESV_ERROR (receiver) 2: PATH (ADSPEC)

7: RESV (MIS)

Layer-3 signalling

RSVP server

Layer-2 signalling

EARTH server

3: RESV (receiver)

4: QSSI

6B: EARTH_qos_notify

5: EARTH_multi

0: EARTH_join

Control VC

6A: Capacity admission control / QoS VC setup Layer-2 data

RSVP vif Data (QoS) VC EARTH control endpoint

Figure 5. \Layered" view on message distribution within the MLIS. admission control). The translation of layer-3- to layer-2-QoS takes place and the EARTH server is noti ed about the QoS requested by receivers, through its QoS Support Interface (QSSI) (phase 4). Layer 2: Upon receipt of the next request (EARTH request message) by the sender, a message containing address resolution information (EARTH multi) including the new requested ATM QoS parameters is sent upstream by the EARTH server at the MIS (phase 5). The EARTH client at the sender sets the received state and gets a call-back about successful establishment of a (leaf to a) QoS VC from the ATM driver (phase 6A). Note that, supposing successful admission control, at this point, data begins to ow on the QoS VC. The success/failure report from the ATM driver is sent back to the EARTH server (EARTH qos notify, phase 6B). On receipt of the EARTH qos notify, the EARTH server at MIS informs the RSVP server about success or failure of the layer-2 admission procedure. Layer 3: If successfully admitted, the RESV message is forwarded (with next hop object set to the MIS' address) to the upstream sender/MRouter (phase 7), and pending admission control is resolved. If other reservations for this sender arrive, they have to be admitted as described above, but only one RESV message is forwarded within the usual RSVP timer intervals (i.e. [session, sender, QoS-level]-merging takes place as de ned by the usual RSVP merging procedure). The RSVP server regards the reservation as 'installed' on his 'virtual interface' (vif) towards the receiver, which is actually its control VC to this receiver. Through this vif, RSVP messages are sent and received, however the real reservation takes place at layer-2 in the (re-)sender. After receipt of the RESV message at the sender, the usual state consistency check is performed. Capacity admission control is always successful (as it has already been performed at layer-2) and the RESV message is forwarded upstream, if needed, outside MLIS{ (phase 8). On failure of the policy admission (phase 4) or capacity admission (phase 6) control, a RESV ERROR message is sent downstream to the requesting receiver only. The sender is never noti ed that a RESV message of this receiver has arrived. Thus, it is not necessary to convey RSVP messages over two hops to nally be noti ed about a reservation failure, as it would be when capacity admission control is managed by RSVP at the sender. Some RSVP protocol processing failure results in an RESV ERROR message back to the MIS (phase 8), which in turn leads to deleting the EARTH server QoS state for this sender for all receivers and, after the next EARTH refresh, to teardown of the entire QoS-VC. This occurs only if the PATH state of sender and MIS somehow dier, e.g. when a new PATH and a RESV referring to an older PATH state are concurrently transmitted.

4. DISCUSSION ON THE MIS

In this section we brie y highlight which are the main bene ts that are introduced by the MIS architecture: modularity, support for advanced applications, and internetworking. { This

is needed if the sender is actually a MRouter/re-sender, and thus the session has senders outside MLIS.


7

Best-effort VC Sender

Base-Layer VC (QoS-0)

ATM pt-mpt VCs

Enhan.-Layer-1 VC (QoS-1)

MLIS

Rec.7 (QoS-0) Rec.1 (best-effort) Rec.6 (QoS-0) Rec.2 (best-effort)

Rec.3 (QoS-0 + QoS-1)

Rec.4 (QoS-0 + QoS-1)

Rec.5 (QoS-0)

Figure 6. Quantized heterogeneity model: distribution of a hierarchic data stream.

4.1. Modularity and protocol independence

The MIS is the only location where QoS-relevant information passes from layer-3 to layer-2 and back. This design issue is essential for protocol independence in the MIS architecture, as the two protocols, EARTH and RSVP, will exchange information just through a well-de ned interface. Under these assumptions it should be possible to replace the EARTH protocol with MARS and/or to substitute RSVP with another reservation protocol. Moreover, the MIS should work also without RSVP using a manual or a SNMP-based con guration of QoS VCs at the server. Although these substitutions should be well-supported by the MIS speci cation, they may create serious drawbacks to the resulting architecture. If we exchange EARTH with MARS, thus partitioning the MLIS in a set of LIS's, the advantage to have end-to-end point-to-multipoint connections (shortcuts) is lost, as the MARS architecture requires that each inter-LIS connection passes through an edge-router. On the other hand, the substitution of RSVP with another reservation protocol could prevent the possibility for the MIS to oer speci c support to advanced QoS merging and heterogeneity features which are proper of RSVP. Finally, the modularity of the MIS allows the integration of service models dierent from the quantized heterogeneity proposed in this paper, as the limited or the full heterogeneity model de ned in [6]. 12

4.2. Support for advanced applications

Some features of the MIS architecture, mainly the quantized heterogeneity model, are speci cally de ned in order to support advanced audio/video applications, i.e. applications which code their output data streams using a multilayer coding technique like MPEG2 or the wavelet coding. Let us consider a videoconference scenario composed of a single presenter and several listeners, e.g. a distance learning session. The speaker endpoint is the source of a video data stream which is hierarchically encoded. Hence the information content of the stream is splitted in a multilayer description providing one coarse approximation (baselayer) and N enhancement-layers which allow to improve the qualityk of the base-layer signal. As shown in gure 6, it is possible to map the dierent sub-layers that are included in the hierarchic data stream on dierent ATM VCs. Having a data stream coded in N sub-layers (base-layer, enhancement-layer-1, ..., enhancement-layer-(N ? 1)), and following the QH model, it is possible to de ne N QoS levels, plus the best-eort. Packets belonging to each quality layer are sent on the corresponding QoS VC, i.e. the base-layer is mapped on the QoS-0 VC, enhancement-layer-1 is mapped on the QoS-1 VC and so on. The best-eort VC can be used to transmit a copy of the packets of the base-layer to receivers that requested the best-eort service only. In this case the sender needs only to duplicate IP packets belonging to the base-layer. No other packet replication is required at the IP layer. If a receiver requests the QoS level Qh it will get the base-layer (QoS-0 VC) plus the rst h enhancement-layers (QoS-1 + QoS-2 + ... + 19

20

k In this context we do not give a more speci c de nition of the data stream quality since it strictly depends on the particular compression algorithm that is adopted during the coding phase; it may involve the frame rate, the image resolution and so on.


8

QoS-h VCs). This mapping solution is just one alternative; the QH model does not pose any constraint, thus any other mapping solution that xes an upper threshold on the maximum number of allowed SVCs per session is valid. On the other hand, if the data stream is not hierarchically structured, no information is available to classify the IP packets in a set of dierent layers. Thus, if we want to de ne a set of QoS levels as foreseen by the QH model, the sender must replicate each IP packet it sends N times, one time for each of the N de ned QoS levels (QoS VCs). In this case, it is necessary to pose a low limit to the number of allowed QoS levels, for reducing the number of packet replications needed at the sender. Moreover, shaping and policing at the ATM layer are applied without any a priori knowledge on the data stream and can cause some undesired data loss at the network layer, since the sender transmits more packets than the ones that are allowed by the bandwidth reserved on the opened connections.

4.3. Internetworking

Using the MIS architecture the major internetworking issues can be eciently addressed. They involve both the EARTH signalling and the RSVP signalling. The MLIS concept, introduced in the EARTH architecture, avoids the major restrictions existing inside an ATM network organized in LIS's. If the ATM cloud is split in a set of LIS's, as described in [12], hosts belonging to dierent LIS's can communicate via edge routers only, even if the LIS's share the same physical network. The overhead of going from a sender to a receiver which belongs to a dierent IP subnet, via the path instead of in the case of multicast connections is very high because layer-3 processing is involved and at the ATM level the same data may have to pass through the switch several times. In the EARTH framework this problem is mostly solved, since sender and receivers are directly connected at the ATM layer inside an MLIS even if they belong to dierent LIS's. Other internetworking issues between MLIS and other networks are eciently addressed by the EARTH protocol itself (refer to [11]). On the \RSVP-side" no internetworking issues exist as the MIS architecture fully supports both the standard RSVP speci cation and the advanced RSVP features for the multilayer coding applications. If the MIS framework provides the QH model, only a limited number of QoS levels are allowed inside the MLIS even if the senders do not use a hierarchic coding technique . In this case, PATH messages coming from non-hierarchic senders outside MLIS are treated by the MIS in the same way as PATH messages coming from non-hierarchic senders located inside MLIS. That is, information about allowed QoS levels is appended in an ADSPEC object to the PATH messages, while they transit in the MIS. For example, let's consider an ATM cloud connected via a single MRouter to an external LAN. A sender for a given multicast session is located on the LAN and does not use any hierarchic coding technique, thus it transmits PATH messages specifying just a single QoS level. In this case, the MRouter forwards PATH messages to the MIS where the RSVP server appends the information about allowed QoS levels and forwards hierarchic PATH messages towards the receivers. 21

18

5. OPEN ISSUES

5.1. Scalability issues

Major scalability issues depend on the MIS-centric organization of the MIS architecture. A single server both for multicast address resolution and for QoS management may become a bottleneck if the ATM cloud size grows. Assuming to use the ATM UNI 4.0 this problem could be re-addressed to the ILMI which supports anycast addresses, thus allowing to have more than one EARTH server and more than one MIS per ATM cloud. Any request to an anycast address is routed to the \nearest" system that registered itself with the network to provide a particular service associated to the anycast address. Currently two other solutions, which support UNI 3.X signalling, are proposed in [11]: server synchronization and server hierarchy. These solutions are based on the Server Cache Synchronization Protocol (SCSP). No scalability matters are due to the RSVP protocol. In fact the distribution of the RSVP signalling messages is organized on the base of the EARTH control connections. In large MLIS's where multiple EARTH servers cooperate via the SCSP protocol, multiple MIS's exist. The RSVP messages will be delivered from the sender to the proper MIS and, in turn, from the MIS to the receivers that have joined the session via the EARTH control VCs. The RESV messages will follow the reverse path. 22

If the sender uses a hierarchic coding technique, the number of QoS levels is implicitly de ned by the number of layers of the multilayer data stream.


9

5.2. MIS with Multilayer Routing technologies

The use of multilayer routing technologies, like IP Switching or the Cell Switch Router (CSR), should be taken in consideration to cooperate with MLIS's, and further to establish ATM shortcuts between dierent MLIS's, avoiding layer-3 packet processing. IP Switching and Cell Switch Routing technologies are ow based schemes. To initiate connections, information on trac ows are employed: only identi ed long-lived IP ows are mapped on a virtual circuit and switched over an ATM network (cell-by-cell forwarding). All other trac is routed on hop-by-hop basis. By the usage of ATM shortcuts, both resource reservation oriented packet ows (e.g. packet ows supported by RSVP) and packet ows with best-eort services achieve less packet delivery latency and higher throughput. An MLIS could be connected to a multilayer router with an EARTH client in it, forwarding the trac to (from) the MLIS. In this case, future studies could concern shortcuts established in the multilayer router between senders outside the MLIS and receivers in the MLIS and vice-versa (i.e. ATM shortcuts between dierent MLIS's connected by a multilayer router) and triggered by the MIS. This would require that either the EARTH client (in the router) or the MIS would have to support the speci c protocols used for exchanging the needed information between multilayer routers. 23

24

25,26

6. CONCLUSIONS

In this paper we have presented an advanced architecture for the support of IP Multicast Integrated Services in ATM networks, namely the Multicast Integration Server. After the study of the problems arising from the integration of Multicast IIS with ATM, our model has been presented. The MIS oers an integrated, server-based approach to the support of QoS multicast services in IP over ATM networks. The key feature of the MIS architecture is the ecient integration between multicast address resolution and layer-2 QoS models (EARTH) with layer-3 QoS mechanisms (RSVP and IIS). An informal analysis of the MIS architecture has been presented, highlighting the key bene ts introduced by our approach. Future work will be addressed primarily towards a prototype implementation of the MIS architecture. This will allow a deep study on performance analysis, developed on a real networking environment. In addition, further study on the de nition of our architecture will try to address the open issues highlighted in the previous section of this document.

REFERENCES

1. D. Clark, R. Braden, and S. Shenker, \Integrated Services in the Internet Architecture: an Overview," RFC1633, IETF, June 1994. 2. L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala, \RSVP: A New Resource ReSerVation Protocol," IEEE Network , Sept. 1993. 3. G. Ratta and others (editors), \User-Network Interface (UNI) Speci cation Version 3.1," tech. rep., ATM Forum, 1994. 4. ATM Forum Technical Committee, \User-Network Interface (UNI) Speci cation Version 3.0," tech. rep., ATM Forum, 1993. 5. ITU-T, \Q.2931: B-ISDN User-Network Interface Layer 3 Speci cation for Basic Call/Bearer Control," tech. rep., ITU-T, Mar. 1994. 6. S. Berson and L. Berger, \IP Integrated Services with RSVP over ATM," Work in progress - Internet Draft, IETF, Mar. 1997. draft-ietf-issll-atm-support-03.txt, .ps. 7. M. Borden, E. Crawley, B. Davie, and S. Batsell, \Integration of real-time services in an IP-ATM network architecture," RFC1821, IETF, Aug. 1995. 8. A. Birman, V. Firiou, R. Guerin, and D. Kandlur, \Provisioning of RSVP-based services over a large ATM network," in Proc. of IEEE Global Internet 1996, J. Crowcroft and H. Schulzrinne, eds., Nov. 1996. 9. A. Demirtjis, S. Berson, et al., \RSVP and ATM signalling - ATM Forum/96-0258," ATM Forum Technical Committee, MPOA Sub-working Group, ATM Forum, Jan. 1996. http://www.isi.edu/b~erson/atmforum2-96.txt. 10. R. Onvural and R. Balay, \Issues in Mapping INTSERV Service Speci cations to ATM Service Categories," ATM Forum Technical Committee, Joint BoF (SAA, MPOA, LANE), ATM Forum, Feb. 1996. ATM Forum/96-0096. To appear in Proc. of SPIE Voice&Video'97, Broadband Networking Technologies

10

11. M. Smirnow, \EARTH - EAsy IP multicast Routing THrough ATM clouds," Work in progress - Internet Draft, IETF, Mar. 1997. draft-smirnov-ion-earth-02.txt. 12. G. Armitage, \Support for Multicast over UNI 3.0/3.1 based ATM Networks," RFC2022, IETF, Nov. 1996. 13. G. Armitage, \VENUS - Very Extensive Non-Unicast Service," Work in progress - Internet Draft, IETF, July 1996. draft-armitage-ion-venus-00.txt. 14. M. Garret and M. Borden, \Interoperation of Controlled-Load and Guaranteed Services with ATM," Work in progress - Internet Draft, IETF, Mar. 1997. draft-ietf-issll-atm-mapping-02.txt. 15. L. Berger, \RSVP over ATM Implementation Guidelines," Work in progress - Internet Draft, IETF, Mar. 1997. draft-ietf-issll-atm-imp-guide-00.txt. 16. J. Wroclawski, \The Use of RSVP with IETF Integrated Services," Work in progress - Internet Draft, IETF, July 1997. draft-ietf-intserv-rsvp-use-02.txt. 17. R. Yavatkar, D. Homan, Y. Bernet, F. Baker, and R. Kennedy, \SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over Ethernet," Work in progress - Internet Draft, IETF, Feb. 1997. draftyavatkar-sbm-ethernet-03.txt. 18. L. Salgarelli and A. Corghi, \Extensions to RSVP and Int-Serv Characterization Parameters for Hierarchially Encoded Trac," unpublished draft, June 1997. 19. ITU-T, \Generic coding of moving pictures and associated audio," 1993. Reccomendation H.262, Committee Draft. 20. J. Kovacevic and M. Vetterli, Wavelet and subband coding, Prentice Hall, 1995. 21. L. Zhang, R. Braden, S. Berson, S. Herzog, and S. Jamin, \Resource ReSerVation Protocol (RSVP) - Version 1 Functional Speci cation," Work in progress - Internet Draft, IETF, June 1997. draft-ietf-rsvp-spec-16.ps, .txt. 22. T. M. C. Partridge and W. Milliken, \Host anycasting service," RFC1546, IETF, Nov. 1993. 23. P. Newman, G. Minshall, and T. Lyon, \Flow Labelled IP: A Connectionless Approach to ATM," in Proc. IEEE Infocom96, IEEE, Mar. 1996. 24. Y. Katsube, K. Nagami, and H. Esaki, \Cell Switch Router - Basic Concept and Migration Scenario," in Proc. Networld+Interop'96 Engineer Conference, July 1996. 25. P. Newman, W. L. Edwards, R. Hinden, E. Homan, F. C. Liaw, T. Lyon, and G. Minshall, \Ipsilon Flow Management Protocol Speci cation for IPv4 - Version 1.0," RFC1953, IETF, May 1996. 26. Y. Katsube, K. Nagami, and H. Esaki, \Toshiba's Router Architecture Extensions for ATM : Overview," RFC2098, IETF, Feb. 1997.


11