Internet Engineering Task Force L. Salgarelli, Editor / A. Corghi INTERNET-DRAFT CEFRIEL/Politecnico di Milano draft-salgarelli-issll-mis-00.txt M. Smirnow / H. Sanneck / D. Witaszek 10 November 1997 GMD-FOKUS Expires: 15 May 1998 Supporting IP Multicast Integrated Services in ATM Networks Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo presents an integrated, server-based mechanism for the efficient 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 memo is to consider such issues in an integrated manner. In particular, the MIS architecture defines how a layer-3 setup protocol as RSVP can be mapped to and integrated with a layer-2 multicast address resolution protocol as EARTH - EAsy Multicast Routing THrough ATM clouds. With the use of EARTH, several ATM point-to-multipoint connections with different QoS parameters can be associated to a single IP multicast address. An RSVP server (RSVP-S) 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 (setup protocol mapping). In addition, this memo defines a quantized heterogeneity model which supports, together with the MIS, advanced IIS features as QoS heterogeneity and dynamic QoS changes in IP-ATM networks. Editor's note The postscript version of this memo contains figures that are not included in the text version, so it would be best to use the postscript version. Figures will be converted to ASCII in a future version. INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Contents 1 Introduction 3 1.1 Motivation .................................................. 3 1.2 Scope ....................................................... 3 1.3 Architectural Overview ...................................... 4 1.4 Operational Overview ........................................ 4 2 Multicast Integration Server 6 2.1 Relation of layer-2/layer-3 protocols ....................... 6 2.2 Functional description: setup protocol mappings ............ 8 2.3 Internetworking ............................................. 11 2.4 Example ..................................................... 12 3 Service model: Quantized Heterogeneity 14 4 Specification 15 4.1 Interfaces .................................................. 15 4.1.1 QSSI and eRSRR........................................ 15 4.1.2 User Interface........................................ 15 4.1.3 Traffic Control Interface............................. 16 4.1.4 Routing Support Interface............................. 16 4.2 MARP Table .................................................. 17 4.2.1 MARPTable manipulation................................ 18 5 Discussion 18 6 Security considerations 21 A Glossary 21 Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 2] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 1 Introduction 1.1 Motivation The main problem of existing architectures for the support of IP in ATM networks is that they lack a solution for the integration of IIS with ATM and IP Multicast with ATM. Instead of trying to focus on the two problems separately, a generalized, integrated approach for providing mapping of IP multicast flows to ATM pt-to-mpt connections for both best effort and QoS multicast flows as well as RSVP control traffic should be designed. Main advantages of the integrated approach over existing architectures should include, but not be limited to, increased efficiency, reduced layer-3 processing, reduction of the amount of identical data passing the switch several times, reduced VC consumption, reduced reservation establishment delay, and finally layer-2 vs. layer-3 protocol independence. In this memo we consider such an integrated solution, trying to merge RSVP [1] with the EARTH protocol [2]. We call this solution Multicast Integration Server (MIS). In particular, this memo focuses on the definition of how a layer-3 setup protocol like RSVP can be mapped on a layer-2 protocol as EARTH (setup protocol mappings), in order to design an integrated architecture. This memo bases on [3] for what is related to service mapping issues. We are considering EARTH, not MARS [4], not because of differences in address resolution between the two (the multicast ARP support in EARTH mainly follows perfectly specified parts of that in MARS ), but because of architectural advantages of EARTH - support for source specific and quality of service specific groups, support for multicast shortcuts (bypassing IP routers) over the entire ATM cloud which is in this case considered to be a Multicast LIS (MLIS). Benefits of EARTH are becoming even more clear when one starts considering IP multicast together with the resource reservation over ATM. 1.2 Scope The architecture presented in this memo is open (i) to any resource reservation protocol based on receiver initiated reservations and soft state approach, and also (ii) to any IP multicast over ATM address resolution protocol based on Multicast ARP (MARP) server, supporting QoS in its MARP cache, transporting QoS objects to hosts within ATM network, and finally providing shortcuts. However, in order to keep this memo readable and short we base the specification on RSVP and EARTH coexistence within the ATM network. Additional publications referenced below cover more details. The Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 3] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 paper [5] describes all design alternatives for the proposed architecture, while this memo concentrates on a chosen one. Further details on the solution presented here could be found in [6], while details on EARTH could be found in [2]. We assume ATM as defined by UNI 3.1. 1.3 Architectural Overview The Multicast Integration Server is a specialized node in an ATM cloud (MLIS in EARTH terminology). A MIS is composed by an EARTH server (EARTH-S), for IP class-D to ATM NSAP address resolution and layer-2 QoS management, and of an RSVP server (RSVP-S), for layer-3 QoS management. The ATM NSAP address of the MIS is a well-known address to each IP node on MLIS. Each participant to an IP Multicast session within 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. On one hand, EARTH protocol messages are exchanged between EARTH clients (IP end-systems) and the EARTH-S on the MIS for dynamically resolving IP Class-D addresses to ATM NSAP addresses. On the other hand, RSVP protocol messages are exchanged between RSVP entities(1) (IP end-systems) and the RSVP-S on the MIS, for distributing information about the requested QoS. In particular, PATH messages are sent from sender(s) to the MIS, where the RSVP-S processes, replicates and forwards them to receivers, while all reservations within the MLIS are sent to the RSVP-S, merged and forwarded to the sender(s). This server-based model contrasts to the usual RSVP distributed processing (see also [7] for a server-based approach to enforce reservations on shared/switched Ethernet). More details about the RSVP server approach followed in this memo can be found later in section 2.1. However RSVP as well as EARTH protocol semantics remain unchanged from their original specifications [1, 2]. The MIS is the only point where the layer-3 protocol (RSVP) is mapped on the layer-2 technology (controlled by EARTH). 1.4 Operational Overview In IP over ATM networks, we argue that capacity-based admission control is a layer-2 issue. For ATM that means: trying to setup a new VC or adding a leaf to an existing VC. Success or failure are ________________________________ (1)We call "RSVP entities" the standard implementations of RSVP residing on each IP node of MLIS, excluding the MIS, e.g. the RSVP daemons on UNIX workstations. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 4] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Figure 1: "Layered" view on QoS setup message distribution and setup protocol mappings in the MIS architecture. beyond the control of the layer-3 setup protocol (RSVP). Therefore the MIS implements a mechanism for remote capacity admission control and actual setup of layer-2 data paths triggered by EARTH. Figure 1 gives a generic overview about the layer-3 and layer-2 signalling involved for the setup of a QoS VC. In brief, the sender, using layer-3 signalling (RSVP), informs the MIS (1) about its traffic profile, while the MIS (2) forwards this information to receiver(s). Receivers request resource reservation (3). These requests are mapped from layer-3 to layer-2 within the MIS (4), and forwarded to the sender (5) as layer-2 signalling (EARTH). Sender (6) sets-up point-to-multipoint VC(s) according to the requested reservation, and (7) acknowledge layer-2 reservation(s) to the MIS. Within the MIS (8), layer-2 acknowledgment is mapped to layer-3, and finally (9) layer-3 acknowledgment is forwarded to the sender. The shown interface between RSVP-S and EARTH-S at the MIS is the only point where QoS-relevant information passes from layer-3 to layer-2 and back, i.e. the MIS is the only location where layer-3 to layer-2 setup protocol mapping and QoS translation take place. This design feature is essential for the protocol independence and avoidance of un-coordinated operation in the MIS architecture. It should also be noted that on failure of a QoS VC setup, no reservation merging takes place and the sender needs not to be notified about the rejected QoS setup. Reservation rejection can already take place at the MIS before passing QoS information to layer-2, e.g. because of policy reasons. The detailed functional description of the mechanism briefly introduced in this section will be presented in section 2.2. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 5] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Figure 2: Distribution of PATH and RESV messages using MIS: a server- based approach to RSVP. 2 Multicast Integration Server 2.1 Relation of layer-2/layer-3 protocols The architecture presented in this memo is server-based, and integrates the EARTH protocol [2] (layer-2) and the RSVP protocol [1] (layer-3). The core of the architecture is its server, the Multicast Integration Server. The MIS is composed by an EARTH server (EARTH-S) plus an RSVP server (RSVP-S). The EARTH-S implements the whole set of functionalities foreseen by the EARTH specifications [2]. On the other side, the RSVP-S is a slightly modified implementation of a normal RSVP protocol instance. RSVP-S differs from a standard RSVP implementation for the characteristics described in the following. Server-based approach. All RSVP protocol messages related to MLIS have to pass through RSVP-S, which process and eventually modifies them before redistributing them to end-stations or Mrouters, as shown in figure 2. Processing of PATH messages. RSVP-S collects all PATH messages coming from end-stations or Mrouters on MLIS, processes and replicates them, and redistributes them to all participants in a given RSVP session. Before redistribution, RSVP-S can enforce administrative or security policies on PATH messages. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 6] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Processing of RESV messages. RSVP-S collects all RESV messages coming from end-stations or Mrouters on MLIS, processes and merges them, and forwards them to the proper sender(s) of the session. Before redistribution, RSVP-S can enforce administrative or security policies on RESV messages. Resource reservation policy enforcement. In order to limit the number of ATM VCs needed to support every multicast session, but nevertheless providing a (limited) support for reservation heterogeneity, the RSVP server approach proposed in this memo provides a mechanism for supporting a limited number of QoS levels (i.e. a limited number of point-to-multipoint VCs) per RSVP session. Given a traffic profile (sender's Tspec) generated by a source, the RSVP-S at the MIS can associate a certain number of QoS levels to such profile, basing on policy information, statistics, or other mechanisms. As the standard PATH message arrives at the MIS, the RSVP-S decides which QoS levels are allowed for the related RSVP session, and appends an ADSPEC object containing one Tspec for each allowed QoS level, before re-distributing the message to receivers (refer to figure 2). In addition, RSVP-S can enforce a particular policy on RESV messages before forwarding them towards senders, e.g. RSVP-S can reject reservations to a given set of receivers, or can refuse reservations of a given type. It is out of the scope of this document (i) the definition of the algorithm for the generation of multiple Tspec from a single given Tspec(2), and (ii) the definition of the format of the ADSPEC object which contains multiple Tspecs. However the structure of such an object could be very simple, as a simple sequence of TOKEN_BUCKET objects [8], one for each allowed QoS level. Protocol mapping of RSVP with EARTH is realized through two local interfaces provided by the EARTH-S: the Quality of Service Support Interface (QSSI) and the earth Routing Support for Resource Reservation (eRSRR) interface. QSSI provides a mean for the RSVP-S to communicate to the EARTH-S the desired QoS for a given (set of) receiver(s) and for EARTH-S to inform the RSVP-S about success or failure of layer-2 admission control (see section 2.2). eRSRR is used by RSVP-S in order to get from EARTH-S information (i.e. IP/NSAP addresses) about receivers participating in a multicast ________________________________ (2)The algorithm could be in principle even a statically defined table mapping a set of allowed Tspecs for each "class" of possible Tspec. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 7] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 session, e.g. when RSVP-S has to replicate and re-distribute PATH messages. QSSI and eRSRR will be described in more detail in section 4.1. EARTH and RSVP protocol messages are exchanged between clients and the MIS by way of point-to-point best-effort ATM VCs (control VCs) between each client and the MIS. Clients of the MIS are end-stations and Mrouters on MLIS that want to participate in an IP over ATM multicast session. Each client must have a standard instance of the RSVP protocol running, plus an EARTH client. The EARTH client implements exactly the features foreseen by the EARTH specifications [2]. The RSVP entity on each client implements all the standard functionalities foreseen by RSVP specifications [1], plus a particular implementation of the Traffic Control Interface (TCI: [1, par. 3.11.2]). This TCI is a quasi-dummy TCI, in the sense that actual resource reservation is performed locally on senders at layer-2 by EARTH, as described later in section 2.2. On end-stations (or Mrouters) no particular communication between the local EARTH client and the local instance of RSVP is needed. Note that MIS operations are concerned only with the management of control messages (EARTH and RSVP). The MIS itself is not a MultiCast Server [4], and has nothing to deal with data distribution, that is performed by the standard ATM infrastructure by means of point-to-multipoint VCs. 2.2 Functional description: setup protocol mappings Functionally, the MIS architecture implements the RSVP protocol for layer-3 resource reservation, and EARTH as a layer-2 multicast address resolution protocol with QoS supporting features. In IP-over-ATM networks, capacity-based admission control is a layer-2 issue, i.e. capacity-based admission control is the operation concerned to the capability of setting-up a new VC or adding a leaf to an existing VC. Using UNI3.1 this operation takes place at the sender(s). However, since is the MIS, not the sender(s), which implements policy admission-control, our architecture adopts 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. All the relevant information needed by the admission-control procedure pass from the RSVP-S to the EARTH-S and back through the QSSI, as shown in the following of this section. After the preliminary phase (not completely shown in figure), where: Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 8] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Figure 3: "Layered" view on message distribution within the MLIS. o receivers join the multicast session by registering their NSAP addresses to the EARTH server in the MIS (phase 0); o senders retrieve such information, querying the EARTH-S (with the EARTH_request message); o eventual PATH messages from outside MLIS reach the forwarder(s), operations go on as follows: Phase 1, layer-3: PATH message(s) are forwarded to the MIS. The RSVP daemon in the sender, or re-sender (MRouter), sends PATH messages towards the MIS. Phase 2, layer-3: re-distribution of PATH messages. At the MIS, PATH state is established and an ADSPEC with pre-configured ATM QoS levels is appended. RSVP-S obtains from EARTH-S the addresses of registered receivers through the eRSRR interface, then the PATH message is replicated and forwarded to registered receivers through each point-to-point control VC. Phase 3, layer-3: RESV messages sent to the MIS. Receivers send RESV messages upstream(3) to the MIS. The RSVP-S performs policy admission control and RESV state is established, but no RESV message is yet forwarded upstream (pending admission control). Phase 4, layer-3 to layer-2: notification about requested QoS. The translation of layer-3- to layer-2-QoS takes place in the RSVP-S and the EARTH-S is notified about the QoS requested by ________________________________ (3)upstream - from receiver to sender. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 9] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 receivers through the QSSI. Phase 5, layer-2: notification of QoS to sender(s). 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 6A, layer-2: remote capacity admission control (on sender(s)). The EARTH client at the sender triggers ATM signalling in order to establish a (leaf to a) QoS VC. It sets the received state and gets a call-back about the success/failure in the establishment of the (leaf to) QoS VC from the ATM layer. Note that, supposing successful admission control, at this point, data might begin to flow on the QoS VC. Phase 6B, layer-2 to Layer-3: remote capacity admission control (on MIS). The success/failure report of the establishment of the (leaf to) QoS VC is sent back to the EARTH server (EARTH_qos_notify). On receipt of the EARTH_qos_notify, the EARTH server at MIS informs the RSVP server (through the QSSI) about success or failure of the layer-2 admission procedure. Phase 7, layer-3: RESV message to sender(s). Supposing successful policy and remote capacity admission procedures, the RESV message is forwarded (with next hop object set to the MIS' address) to the upstream sender/MRouter, 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 defined 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. Phase 8, layer-3: re-distribution of RESV messages outside MLIS. 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(4). Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 10] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Phase 4/6/8, layer-3: handling of reservation errors. 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 notified that a RESV message of this receiver has arrived. Thus, it is not necessary to convey RSVP messages over two hops to finally be notified 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 sent 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 differ, e.g. when a new PATH and a RESV referring to an older PATH state are concurrently transmitted. 2.3 Internetworking Internetworking between each MLIS and the rest of the Internet is concerned with two aspects: the layer-3 setup protocol and the layer-2 multicast address resolution protocol. On one hand, the MIS architecture adopts standard RSVP protocol messages. PATH messages incoming in MLIS are treated by RSVP-S as PATH messages generated by a node on MLIS. Also PATH messages outgoing from MLIS are standard RSVP PATH messages. In this case, additional ADSPEC objects defining allowed (policed) QoS levels for a given session that are used within MLIS are converted by Mrouters to single-Tspec PATH messages before forwarding them outside MLIS. The single-Tspec object could be generated using the highest Tspec of the ones contained in the multi-Tspec PATH message. At the same time, reservation incoming from outside MLIS are bounded by Mrouters to the nearest QoS-level available for that session, before forwarding them to the MIS. RESV messages forwarded by Mrouters outside MLIS are standard RSVP reservation messages. The MIS architecture foresees the use of all the other RSVP protocol messages without modifications. On the other hand, internetworking issues related to the multicast address resolution protocol are efficiently addressed by the EARTH ________________________________ (4)This is needed if the sender is actually a MRouter/re-sender, and thus the session has senders outside MLIS. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 11] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Figure 4: Internetworking: example. protocol, which specifies interworking with non-ATM clouds via DVMRP and via SCSP in case of multiple EARTH servers in large ATM clouds. 2.4 Example In order to describe how the MIS architecture works, in this paragraph a complete and accurate description of an extensive case-of-study is presented. Let's consider the example that is shown in figure 4. For a given multicast session there are two senders and four receivers distributed on different networks. One of the two senders is on the external LAN L1 (we assume that both the LAN L1 and the LAN L2 are Ethernets), while the other one is inside the ATM cloud. The receivers are distributed on all the three networks: R1 and R2 are on the ATM cloud, while R3 and R4 are on the external LANs. Multicast router M1 is the ingress router for the flow generated by S1 and the egress router for the flow generated by S2. Multicast router M2 acts like egress router for both these data flows. All the receivers join a determined multicast session, namely MS1, using IGMP, on the LANs, and EARTH inside the MLIS. The inter-operation between these two protocol works according to the EARTH specification [2]. Once all the receivers have joint the multicast session and the senders have solved the multicast IP address in the proper set of NSAP addresses two point-to-multipoint best effort connections are opened inside the ATM cloud: the former Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 12] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 originating from the sender S2 to the set and the latter from M1 to . Moreover, M1 forwards the data packets from S to the LAN L1 and M2 forwards all the data packets (both from S and from M1(5)) to the LAN L2. No reservations have been still requested, so the QoS functionalities of the EARTH protocol have not yet been employed. The EARTH table (MARPTable) of the MIS contains the information on all the receivers as best-effort receivers for the multicast session MS1. The senders, following the standard RSVP specifications [1], transmit the RSVP PATH messages to the multicast group. The PATH messages originated at S1 are received by R3 and M1. The receiver R3 receives directly the PATH message and it requests the desired reservation by sending a RESV message up to the sender. Since M1 is a Mrouter, it has to forward the PATH message to the ATM end-points that have joint the session and it will ask for a reservation according to the requests of the ATM receiver. According to the model described in the paragraph 2.2, the PATH message is sent to the MIS, where the RSVP server takes care of replicating and properly forwarding the messages to the joined receivers. The egress Mrouter M2 in turn forwards the message to the external LAN L2. The PATH messages originated at S2 are delivered following the same rules; in this case, both M1 and M2 acts like egress routers toward the external LANs. Outside the ATM cloud the reservation of resources takes place as defined in [1, 9]. On the contrary, inside the ATM cloud, the MIS approach is applied. As a consequence, the external receivers (i.e. R3 and R4) send their reservation requests to the corresponding previous hops (respectively M1 and M2) and the reservation takes place between the Mrouter (it acts like a re-sender) and the receiver. On the contrary the reservation inside the MLIS follows the rules that have been presented in the paragraph 2.2. All the ATM receivers send the RESV message to the MIS(6), where both the RSVP tables and the EARTH tables are updated and the pending reservation state is set. The senders in the MLIS will be informed about the pending reservations through the EARTH_multi message and then try to set up the corresponding QoS point-to-multipoint VCs directly to receivers. ________________________________ (5)M1 acts like a sender with respect to the ATM cloud; it is actually a re-sender of the data flow originated at S1. (6)Note that the MIS is actually the previous hop for each ATM receiver; but no reservations take place between the MIS and receiver, as the QoS connections are directly opened from the sender to the receiver. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 13] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Figure 5: Quantized heterogeneity model. 3 Service model: Quantized Heterogeneity Although any service model for IIS over ATM can be efficiently supported by the MIS architecture, in this paper the quantized heterogeneity (QH) model is proposed as the advanced service model offered by the MIS. The QH model represents a compromise between the ``full'' and the ``limited heterogeneity'' models specified in [10], by supporting a limited number of QoS levels, included the best-effort class, for each multicast session. Since each ATM point-to-multipoint VC provides a single QoS level, a limited number of ATM point-to-multipoint VCs per session are allowed. As shown in figure 5, each sender of a multicast session can open one best-effort point-to-multipoint connection and a limited number of QoS point-to-multipoint connections with different QoS levels. As a consequence, each receiver can choose the desired QoS level only among the allowed ones. The best-effort 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 [10]. The QH model does not define any guidelines about how to manage 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. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 14] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 The QH model can be efficiently integrated in the MIS architecture using the Multicast Integration Server in order to manage (i.e. to define and distribute) information about the allowed QoS levels, using multi-Tspec PATH messages. In this case, senders may generate single-Tspec PATH messages, while information about the pre-configured allowed QoS levels are appended to outgoing PATH messages by RSVP-S at the MIS, enforcing resource reservation policy on the ATM cloud, as described in section 2.1. 4 Specification 4.1 Interfaces EARTH, being an ATM protocol supporting IP multicast with embedded support for the QoS settings, should work even without any reservation protocol to enable QoS settings. In any case, it would provide an address resolution for best effort flows, supporting minimal QoS functionality in order to allow setup of QoS VCs by manual configuration (UI) or management protocols. 4.1.1 QSSI and eRSRR The EARTH-S in the MIS architecture supports resource reservation with two local interfaces: QSSI (Quality of Service Support Interface) and eRSRR (earth Routing Support for Resource Reservations). These interfaces define specific messages in order to pass information to/from the EARTH-S. The QSSI provides the EARTH_QoS_notify message, used to set the requested QoS information in the EARTH-S. For example, RSVP-S sends this message to the EARTH-S when accepting a reservation. With the same message, sent on QSSI in the opposite direction (from EARTH-S to e.g. RSVP-S), the EARTH-S reports a success or a failure of connection establishment at the sender side. The routing support interface (eRSRR) gives the possibility to get locally from the EARTH-S information about receivers participating in a multicast session (needed e.g. for the RSVP-S) with two messages: EARTH_query, to request an address resolution, and EARTH_response returning to the requester addresses of receivers which joined the group. 4.1.2 User Interface The operation of the MIS can be customized through the User Interface (UI). The UI allows the customization of both the EARTH-S and the RSVP-S. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 15] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Through the User Interface the EARTH-S could be customized to support: o Best effort service only (zero QoS), or also non-zero values for QoS. o Additional interfaces, like QSSI or routing support interface for interworking with RSVP or with other means for resource reservation. o Manual configuration of the MARPTable (with the use of the primitives described in 4.2.1). The RSVP server can be customized with the use of UI for the following topics: o Support for hierarchically encoded traffic flows or other. o QoS-levels Generation Algorithm. o Local policies to handle non-conformant (with regard to traffic description) reservation requests. o Mapping of QoS levels to ATM QoS parameters used by UNI signalling. 4.1.3 Traffic Control Interface The generic Traffic Control Interface (TCI) is defined in RSVP specifications [1]. In the MIS architecture, TCI is implemented as follows: o TCI at sender or forwarder (Mrouter): only a 'dummy' admission control has to be present as the VC setup has been already successful (of course local policies could be enforced, however an admission rejection at this points has a high message/latency overhead). o TCI at MIS: a link-layer dependent adaptation module (LLDAL) has to be added (as for any other link-layer) which interfaces to the EARTH server's QoS Support Interface (QSSI). 4.1.4 Routing Support Interface The Routing Support for Resource Reservation interface (RSRR) defined in [11], is implemented in the MIS architecture by simply mapping Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 16] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 control VC endpoints to RSVP virtual interfaces [1]. 4.2 MARP Table The Multicast Address Resolution (Protocol) Table (MARPTable), hold by the EARTH-S and EARTH-clients, stores membership information, including multicast address resolution as well as QoS information. MARPTable codes source-specific and QoS-specific information as shown below. MARPTable = null _ MARPTableEntry [, MARPTableEntry [, ... ]] MARPTableEntry = SourceSpecEntryList = SourceSpecEntry [, SourceSpecEntry [...]] SourceSpecEntry = QoSSpecMembers = QoSMembers [, QoSMembers [...]] QoSMembers = MemberList = null _ RecId [, RecId [...]] RecId: = where: null - represents an empty (e.g. zeroed) data structure[s]; a _ b _ ... - mutually excluding alternatives a, b, ...; a [, a [, ...]] - one or any number of instances of entity of type a; - a set of elements a, b, ... Terms used in the description of MARPTable are: MultIPAddr : Multicast IP Address (i.e IP Class D Address). SourceIPAddr : is either IP Address of a source of multicast traffic or must be zero, when multicast group has only registered receivers but no specified source. QoSLevel : a value representing a quality of service level - to be mapped into a quality of service supported by ATM signalling (QoS levels defined in the table QoSMap). The value zero means best effort service. RecNSAPA, RecIPAdd : NSAP and IP Addresses of a receiver registered with EARTH. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 17] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 4.2.1 MARPTable manipulation The messages defined by the EARTH specification, as well as the ones used in QSSI, eRSRR and UI are mapped in a set of primitives which manipulate the MARPTable: p_join, p_leave, p_get_req, p_get_resp, p_set_qos and p_qos_ack. For example the primitives p_get_req(flag, MultIPAddr, SenderIPAddr [, SourceIPAddr]) and p_get_resp(flag, MultIPAddr, SourceIPAddr, QoSSpecMembers) describe request for the entry for a given group (MultIPAddr) and the corresponding answer. The flag indicates whether all the QoS subgroups should be returned or the best effort only. The answer (p_get_resp) depends on the address of the sender (SenderIPAddr) in the request; i.e. only sender relevant (and only for allowed sender) information will be made available. They are mapped into EARTH protocol messages EARTH_request, EARTH_multi as well as defined for eRSRR EARTH_query and EARTH_response. The primitive concerning QoS, p_set_qos(MultIPAddr, SourceIPAddr, prevQoSLevel, newQoSLevel, RecId) allows to set a QoS level of a receiver. The receiver (RecId) is removed from one QoS specific subgroup (prevQoSLevel) and added to another (newQoSLevel) subgroup. The acknowledgment of this primitive is the primitive p_qos_ack(MultIPAddr, SourceIPAddr, prevQoSLevel, newQoSLevel, RecId), with the same parameter list. The EARTH protocol message EARTH_QoS_notify which arrives from the EARTH client (sender) to acknowledge a success or failure of QoS connection setup is mapped into p_set_qos. The messages provided on the QSSI Interface for the QoS support (used by RSVP or by other means for resource reservations), EARTH_RESV(MultIPAddr,SourceIPAddr, prevQoSLevel, newQoSLevel, RecId) and EARTH_RESV_ACK(MultIPAddr,SourceIPAddr, prevQoSLevel, newQoSLevel, RecId), can be mapped into two of above mentioned primitives: p_set_qos for the messages received on QSSI interface, and p_qos_ack for the message sent on the QSSI interface. 5 Discussion We argue that the proposed architecture for the Multicast Integration Server should result in increased efficiency, reduced layer-3 processing, reduction of the amount of identical data passing the switch several times, reduced VC consumption, and finally reduced reservation establishment delay, when compared to existing architectures. All these achievements are facilitated by major key design issues collected below from the above text and commented from a more generalized perspective. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 18] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 RSVP server. Besides the issues bulleted in section 2.1 it should be noted that the separation of data and control paths over ATM seems to be inevitable for any IP control protocol supporting multicast due to the unidirectional nature of ATM pt-to-mpt connections. In the MIS architecture the RSVP has additional benefits arising from the fact that it reuses control VCs being maintained by EARTH clients. To distinguish between EARTH and RSVP control messages we propose a simple dispatching module in the MIS (refer to [5]). Why EARTH not MARS. The current IETF ION proposed standard RFC 2022 [4] does not support QoS and retains the Classical IP over ATM approach to separate the ATM cloud to a number of logically disjoint subnets (clusters) which must consist of members of a single LIS only [4, chapter 8, page 54]. However, the Classical IP over ATM [12, 13 ] is an IP unicast protocol over ATM. Complete mapping of IP multicast service model to the ATM multicast service model requires bypassing of IP routers (shortcuts) in order to take the advantage of connecting of all the ATM endpoints - receivers (whatever LIS they belong) with a single pt-to-mpt VC. The reduction of VC consumption with MIS (due to shortcuts) in comparison with hypothetical MARS (even if supporting the QoS differentiation) could be estimated as O(Q*N), where Q is the number of QoS levels and N is the number of receivers. Another advantage of EARTH (however referring to implementation only) is that it manages the VC establishment via the UNI 3.x signalling in such a way that the multicast data forwarding could be started from the [re-]sender even on non completely established pt-to-mpt VC. This fact brings additional savings to the join/leave/reservation latency, which could be estimated again as O(Q*N). The MIS architecture is open. The MIS architecture is server-based and layered: it defines specific mapping procedures between RSVP and EARTH. The layer-3 RSVP is a consumer protocol with regard to the address resolution and data handling service provided by the layer-2 EARTH protocol. In MIS scenario only QoS assured IP multicast requires limited and strictly specified collaboration between RSVP and EARTH protocols through the two interfaces (QSSI and eRSRR) supported by the EARTH; IP unicast could be supported by RSVP unicast over ATM which is combined with the legacy atmarp. The future development of MARS based IP/ATM networks can use the QSSI defined in this draft for both VC meshes and multicast servers. On the other hand, any other resource reservation protocol can use Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 19] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 EARTH's information in order to get receivers' NSAP addresses for an IP multicast session and to use the QSSI in order to set the desired QoS state for any of these receivers. The MIS is open also for the inclusion of any policy admission control, network management or security modules. Remote capacity admission control. Because of the separation of IP data and IP control paths over ATM the question of regulating arises between the place where the reservations are collected and merged (MIS) and the place where the capacity admission control is applied (sender(s)). This problem is solved via the modification of the original EARTH protocol (the EARTH_qos_notify message was added). Therefore this solution is safe with regard to the "standard" operation of RSVP and provides timely updates for the EARTH data base, which data base could be safely used by other consumer protocols. Pre-configured ATM QoS levels. We believe that the practically feasible number of QoS levels in IP/ATM internets could not be large. Moreover, the QoS levels which could be used by IP/RSVP flows must be supported by the ATM signalling, i.e. these available levels must be known in advance and the mapping from a particular RSVP reservation to the ATM QoS should be done with some robustness in mind. The QH model. Due to the connection oriented nature of ATM the renegotiation of the QoS consumes double resources during the transition phase. The quantized heterogeneity model provides significant savings of resources in this case. Supporting only a (configurable) limited amount of QoS levels (i.e. QoS VC) per session, the MIS architecture (i) prevents wasting of network resources unavoidable with the ``full heterogeneity model'' [10], and (ii) provides more flexibility than the single-QoS ``limited heterogeneity'' model, in full accordance with the receiver-initiated philosophy of RSVP. Scalability. 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. On one hand, some solutions to efficiently face the scalability of the EARTH protocol are proposed in [2]. On the other hand, no scalability matters are due to the RSVP protocol, as the distribution of the RSVP signalling messages is organized on the base of the EARTH control connections. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 20] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Service mappings. The MIS architecture bases on the ongoing work of the ISSLL IETF working-group for what is related to service mappings issues, in particular on what is specified in [3]. Adaptation protocols. By supporting the quantized heterogeneity model, the MIS is capable of augmenting the native capabilities of the ATM link-layer (single QoS per ATM multicast session), thus providing a set of different QoS levels to each IP Multicast session. Statement of non-applicability. Currently, due to the inherent limitations of ATM signalling (no multipoint-to-point capability), only Fixed-Filter style reservations (explicit sender selection, distinct reservations) are supported. However a mapping scheme within the MIS, where a Shared-Explicit or Wildcard-Filter reservation is mapped to several separate layer-2 reservations (i.e. QoS-specific entries in the EARTH server's MARP table) can be realized. Implementation. Two independent implementations of the MIS architecture are being developed at CEFRIEL/Politecnico di Milano and GMD-FOKUS. 6 Security considerations Security and policy mechanisms can be enforced for an entire MLIS, at the MIS. However, specific security considerations should be addressed in a separate document dealing with security in IP over ATM networks, especially with the presence of shortcuts. This memo does not imply any new security issues if compared with RSVP over ATM and IP Multicast over ATM, however it amplifies security concerns, through bypassing inter LIS routers and possibly firewalls. This draft recognizes that MIS (EARTH server) could be configured to allow or not to obtain the NSAP address of specific endpoints/LISs/etc. Security management in EARTH case will mean that it's commonly agreed security management between all LISs delegated to a future security entity within the MIS architecture, e.g. entity managing security of shortcuts. A Glossary In this memo the following terms are used with the following meanings: Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 21] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 MLIS: a [static] association of all IP multicast gateways (Mrouters) and [dynamic] association of all ATM endpoints/IP hosts willing to participate in any IP multicast session over an ATM cloud. Shortcut: an ATM shortcut is a direct ATM connection between a sender and a (set of) receiver(s) in an MLIS, eventually bypassing inter-unicast-LIS routers. MIS: the acronym ``MIS'' is used in general alone to indicate the server of the architecture proposed in this memo. The architecture itself is indicated as ``MIS architecture''. Mrouter: this term is used to indicate border multicast routers which provide layer-3 multicast connectivity between an ATM cloud and the rest of the internet. Forwarder: a synonym for Mrouter. Re-sender: another synonym for Mrouter. MARP: Multicast Address Resolution Protocol. IIS: Internet Integrated Services architecture [9]. EARTH-S: the server of the EAsy multicast Routing THrough ATM clouds protocol. RSVP-S: the server of the RSVP protocol defined and used in the MIS architecture. QSSI: Quality of Service Support Interface, defined in EARTH specifications [2], and recalled in this memo in section 4.1. eRSRR: extended Routing Support for Resource Reservation Interface, defined in section 4.1. TCI: Traffic Control Interface, defined in [1]. LLDAL: Link-Layer Dependent Adaptation Module, used in section 4.1. References [1] L. Zhang, R. Braden, S. Berson, S. Herzog, and S. Jamin. Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification. RFC2205, IETF, September 1997. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 22] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 [2] M. Smirnov. Scalable and Efficient Multiprotocol IP Multicast over ATM. In Proceedings of SPIE VV'97 - Broadband Networking Technologies, Dallas - Texas, Nov 1997. SPIE. [3] M. Garret and M. Borden. Interoperation of Controlled-Load and Guaranteed Services with ATM. Work in progress - Internet Draft, IETF, July 1997. draft-ietf-issll-atm-mapping-03.txt. [4] G. Armitage. Support for Multicast over UNI 3.0/3.1 based ATM Networks. RFC2022, IETF, November 1996. [5] A. Corghi, L. Salgarelli, H. Sanneck, M. Smirnov, and D. Witaszek. Design Experiences with IP Multicast Integrated Services over ATM. Unpublished, July 1997. Available at ftp://ftp.fokus.gmd.de/pub/step/papers/mis-alt.ps.gz. [6] L. Salgarelli, A. Corghi, H. Sanneck, and D. Witaszek. Supporting IP Multicast Integrated Services in ATM Networks. In Proceedings of SPIE VV'97 - Broadband Networking Technologies, Dallas - Texas, Nov 1997. SPIE. [7] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, and R. Kennedy. SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over Ethernet. Work in progress - Internet Draft, IETF, February 1997. draft-yavatkar-sbm-ethernet-03.txt. [8] J. Wroclawski. The Use of RSVP with IETF Integrated Services. RFC2210, IETF, September 1997. [9] D. Clark, R. Braden, and S. Shenker. Integrated Services in the Internet Architecture: an Overview. RFC1633, IETF, June 1994. [10] S. Berson and L. Berger. IP Integrated Services with RSVP over ATM. Work in progress - Internet Draft, IETF, March 1997. draft-ietf-issll-atm-support-03.txt, .ps. [11] D. Zappala. RSRR: A routing interface for RSVP. Internet Draft, IETF, November 1996. draft-ietf-rsvp-routing-01.ps. [12] M. Laubach. Classical IP and ARP over ATM. RFC1577, IETF, January 1994. [13] M. Laubach and J. Halpern. Classical IP and ARP over ATM. Work in progress - Internet Draft, IETF, October 1997. draft-ietf-ion-ipatm-classic2-03.txt. Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 23] INTERNET-DRAFT draft-salgarelli-issll-mis-00.txt 10 November 1997 Authors' Addresses L. Salgarelli and A. Corghi CEFRIEL/Politecnico di Milano via Fucini 2, I-20133 Milano (Italy) Voice: +39-2-23.954.1 Fax: +39-2-23.954.254 e-mail: -salga, corghi"@cefriel.it M. Smirnow, H. Sanneck and D. Witaszek GMD-FOKUS Kaiserin-Augusta-Allee 31, D-10589 Berlin (Germany) Voice: +49-30-34.637.000 Fax: +49-30-34.638.000 e-mail: -smirnov, sanneck, witaszek"@fokus.gmd.de Corghi/Salgarelli/Sanneck/Smirnow/Witaszek Expires 05/98 [Page 24]