Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case

Transcription

1 Roberto Cocca, Stefano Salsano Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case INFOCOM Department Report University of Rome La Sapienza Abstract In principle, the interaction of RSVP and ATM should allow to benefit at the IP level from some features of the ATM layer. The most interesting one is the native support of endto-end Quality of Service provided by the ATM, both for unicast and multicast case. On the other hand, there are issues that must be clarified to define a correct interworking: for example, the needed IP/ATM address resolution mechanism or the fact that the RSVP protocol and the multicast routing protocol (e.g. PIM-SM) are soft state, while the ATM is hard-state. This paper tries to extend to the multicast case a solution to exploit ATM shortcut VCs supporting the QoS in the Internet Integrated Service model. Special care has been taken to maintain compatibility with traditional RSVP hosts and routers using PIM-SM routing protocol. Table of contents 1. Introduction Proposal in the unicast case Extension to the multicast case References...11

2 R. Cocca, S. Salsano: Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case 2 1. Introduction The best-effort service model, on which Internet is still largely based, combined with efficient transport layer protocol (i.e. TCP), is perfectly suited for a large class of applications, referred to as elastic, which can adapt (even dynamically) to different performances offered by the network, in terms of data throughput and end-to-end-delay. Web browsing and electronic mail represent a typical example of elastic applications. Real time applications, like video and audio conferencing, typically require stricter guarantees on throughput and delay. The idea of extending Internet capabilities to provide support to real-time applications has led the Internet community to develop the Internet Integrated Service (IIS) architecture [1] and a signaling protocol called Resource Reservation Protocol (RSVP) [2] has been defined. On the other hand, it is widely accepted that the ATM technology offers potential advantages both for its capability in terms of aggregate switching throughput and for its native ability to support QoS in both point-to-point and point-to-multipoint VCs. In fact, ATM is currently used as an efficient network technology for transport/switching in the backbone networks. A key point for the future of ATM is the integration with IP technology. Current IP/ATM interworking solutions (LANE, CLIP, MPOA) do not natively support QoS. They focus on using ATM technology under the classical best-effort IP model. That is why a new solution has been studied. 2. Proposal in the unicast case The proposed solution [3], [4] avoids the use of IP/ATM address resolution mechanisms by a simple enrichment to the RSVP protocol. The basic idea consists in adding new informational elements to the RSVP PATH and RESV messages in order to carry the information for allowing the establishment of ATM shortcut VCs between the ATM node closest to the source and the one closest to the destination. In this way the processing load in the routers is reduced, increasing the network throughput and partially solving the RSVP scalability issue. 3. Extension to the multicast case Study for extending the proposal to the multicast case has been carried on, highlighting issues which where not present in the unicast case. Multicast transmissions are becoming more and more important since the traffic-load in the Internet is growing every day. In 1992 an interconnected set of subnetworks with routers capable of forwarding multicast

3 R. Cocca, S. Salsano: Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case 3 packets were selected for experimenting with multicast. This multicast testbed was called Multicast Backbone (Mbone): islands of multicast-capable networks were connected to each other by virtual links called tunnels, in order to cross non-multicast-capable portions of the Internet. The only multicast routing protocol used in the Mbone in early phases was DVMRP [5], which is a dense-mode protocol, more efficient in situations where multicast group members are densely distributed over the network. By the increase of the availability of multicast routing software features on the routers used in the Internet, the usage of native multicast is now replacing the need for using tunnels. PIM-SP [6] is now substituting DVMRP. This protocol behaves better when group members are sparsely distributed: an explicit willing to join a group must be shown, while in the dense-mode protocol every router is part of the distribution tree unless it prunes itself. Different intra-domain scenarios, with an increasing level of generality, have been defined as a feasibility study on multicast extension of our unicast proposal.. We assume that the reader is already familiar with the PIM-SM multicast routing protocol. Some acronyms meaning is below recalled, in order to simplify the comprehension of the following scenario description: RP stands for Rendezvous Point: it is the router where every router which wants to receive multicast messages from a certain group needs to send a Join/Prune message; DR stands fo Designated Router, which is the selected router to get a membership indication from IGMP for a new group and send Join/Prune messages toward the groupspecific Rendezvous Point; the RP-tree is the shared, RP-centered, distribution tree that reaches all group members. When a data source first sends to a group, its DR unicasts Register messages to the RP with the source data packets encapsulated within; then the RP aforwards the source decapsulated data packets down the RP-centered distribution tree toward group members. If the data rate is higher than a fixed threshold, the source data packets will travel unencapsulated to the RP: we define RP*-tree the RP-tree characterized by this feature. The SP-tree is the shortest path distribution tree, in general not RP-centered. 3.1 The simplest scenario The first scenario, which has been considered, is obviously the one with the major number of constraints, so some hypotheses are considered! In Figure 1 the architecture of the reference scenario is depicted. We assume that a set of RSVP and PIM-SM capable routers are connected by an underlying ATM network. Classical IP over ATM is being run, therefore

4 R. Cocca, S. Salsano: Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case 4 the packets will follow an hop by hop path. In this scenario, the goal is to determine the longest possible ATM shortcut, which directly connects the Ingress and several Egress Routers, according to the location of the different destinations which joined the multicast group. It is supposed to operate within a single domain (intradomain solution). For simplicity we initially assume that all the destinations can receive either best effort service (not taking advantage of the underlying ATM network), or the same level of Quality of Service (QoS). In case of best effort service no additional ATM connections will be used, while in case of QoS request a dedicated multicast ATM VC will be setup. + DR0 RP R1 longest shortcut + ATM public network DR1 R2 DR2 Figure 1: The reference scenario The destinations of a specific group which ask for QoS will be served by an ATM multicast tree, while the others will be served by an IP shared tree. It should be clarified what kind of tree it is! When a data source first sends to a group, its DR unicasts Register messages to the RP with the source data packets encapsulated within. Normally, only if the data rate is high, the RP start to switch from the RP-tree to a RP*-tree. In our proposal we decided to set the threshold for initiating the switch by the RP to the RP*-tree very low, in order to have IP packets travelling towards the RP unencapsulated: this is necessary for being able to capture IP and ATM addresses when needed! On the other hand, we assume that routers with local receivers will never switch to the SP-tree, because we take advantage of the ATM shortcut

5 R. Cocca, S. Salsano: Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case 5 multicast VC for the data delivered with QoS: to realize this policy it is enough to set the threshold for initiating the switch by the RP to the SP-tree very high Joining a specific group We assume that an IP RP*-tree towards some destinations has been built using PIM- SM and the packets from the source travel unencapsulated to the RP; we also assume that a new destination wants to join the group G. The list of the actions to be performed is given: - the host, which wants to join group G, informs its DR by means of IGMP: this router creates a new entry for this multicast group and start sending periodic Join/Prune messages to the RP (obviously, all the intermediate routers along the path will add a new entry (*,G) in their multicast forwarding tables for the new group and forward the Join/Prune message to the next router according to their routing table). As soon as the RPtree is completed, due to the very low threshold the RP switches to the RP*-tree. At the end of these operations the host is a leaf of the RP*-tree and belongs to the specified multicast group. - The Ingress Router, while sending an RSVP PATH message towards the next hop internal to the ATM network, inserts its own IP address using a new RSVP class called ATM_FHOP_IP_ADDRESS (FHOP stands for First Hop). - This information is stored in the PATH state information in each of the subsequent Integrated Services over ATM (ISoA) routers in the core network. These routers forward the information unmodified. Therefore also the Egress Router receives and stores the IP address of the Ingress Router. - This considered leaf of the RP*-tree starts receiving enriched RSVP PATH messages and can behave in two different ways, according to its needs: a. If this host does not want to ask for QoS (because it is not RSVP capable or because it actually does not need QoS) it will not answer at all to such messages, which will continue to reach this host as long as it will remain member of the group; b. If this host wants to ask for QoS it will reply to the RSVP PATH message with a RSVP RESV message, whose destination address is the IP address of the first (the closest to the source) ISoA router crossed by the PATH message (Ingress Router).

6 R. Cocca, S. Salsano: Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case 6 When receiving a RSVP RESV message, a generic router checks if an ATM_FHOP_IP_ADDRESS information is stored in the relevant PATH state. In this case, the RSVP RESV message is forwarded using as IP destination the stored IP address. According to the RSVP message processing rules, such a message will not be interpreted by the intermediate routers, which will simply forward it up to the Ingress Router. In addition to the other info (e.g. Rspec), a newly defined class is added in this enriched RSVP RESV message by the first ISoA router it crosses (Egress Router) in order to carry the Egress Router ATM address for establishing the shortcut. This new class has been called ATM_LHOP_ATM_ADDRESS (LHOP stands for Last Hop). - The Ingress Router will receive a RSVP RESV message containing the ATM address of the Egress Router and, as usual, the traffic specification for the reservation. Therefore, all the information (traffic specs and ATM address) needed to setup a QoS shortcut VC is available and the Ingress Router can send the ATM SETUP. We are now analyzing the multicast case, so the Ingress Router will receive as many RESV messages as the number of the hosts which decided to join the multicast group G asking for QoS after the reception of a specific PATH message. Such a router will setup an ATM multicast VC or, if already established, will add to this VC some branches (with ADD PARTY messages) in order to deliver data also to the new members of the group. The RSVP PATH Refresh messages will be sent through this ATM multicast tree as well. The Reservation will be referred to all the data coming from the IP source. It has to be clarified that every source needs a specific ATM multicast tree, so different trees can originate from the same Ingress Router. Further, the RSVP Reservation must be done without specifying any destination port or sender port, but must refer to the couple (S,G), in order to allow parallel flows from the same source towards the same destinations to use the same tree. - At this point when the source will sends data, all the destinations (i.e. the leaves of the ATM multicast tree) will start receiving such data, beyond the RSVP PATH Refresh messages. On the other hand, destinations which did not ask for QoS will anyway receive data through the IP RP*-tree, beyond the RSVP PATH Refresh messages, for a while. In fact, the DR of each host which joins the group continues sending periodic Join/Prune messages towards the RP of the group, but it prunes itself for this specific source, removing the (S,G) state in each of the crossed routers. It means that ATM destinations which asked for QoS will receive for a while couples of the same PATH messages and eventual data, but this is already considered in the classical PIM-SM

7 R. Cocca, S. Salsano: Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case 7 specifications, in fact when a router with directly connected members switches from shared tree to shortest path tree it receives twice the same data until it prunes itself from the shared RP-tree Leaving a specific group or quitting QoS Two situations have to be considered: 1. a host which previously asked for QoS and now still wants to join the same group, but the best effort service is enough; 2. the deletion of a host which asked for QoS from a specific group. In the first case, the destination host sends a RSVP RESV TEAR message having for destination address the Ingress Router IP address (stored in the Egress Router state). The intermediate routers will simply forward such a message without any processing, while the Ingress Router will remove from the ATM multicast tree the destination whose IP address is specified in the source address of the RESV TEAR message. As it is the root of the tree to prune branches the ATM 3.1 version can be used (the 4.0 version is not necessary). In the accidental case where the destination host should not be able to send the RESV TEAR message (e.g. a software crash), the Ingress Router will not receive RESV messages anymore (RSVP is a soft-state protocol) and, after a time-out expiration, will tear down the correspondent party of the ATM tree. Its DR will stop sending Join/Prune messages for a specific source (S,G), but will continue sending wildcard Join/Prune messages, creating (*,G) entries in each of the crossed router between the DR and the RP, so the destination will be now again part of the IP RP*-tree, but not of the ATM multicast QoS VC anymore. In the second case the destination host will stop sending IGMP join messages for the group G to its DR, so it will not receive anymore RSVP PATH messages. It means that it will not send RESV messages as well and the Ingress Router, after the expiration of a time-out, will tear down the specific branch of the ATM multicast VC. This time the DR will stop sending Join/Prune messages to the correspondent RP, so the destination host will not be a leaf of the RP*-tree. In the trivial case where a leaf of the IP RP-tree, which asked to join the group G receiving data with best-effort modality, wants to leave that group everything works exactly like in the classical PIM-SM protocol;

8 R. Cocca, S. Salsano: Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case Removing some constrains Case 1: the routers closest to the destinations are just IS router, but not ATM capable. In principle, nothing changes, because in our proposal the joining of a new host to the group G is done by means of the usual PIM-SM messages and they travel in IP network. So, when a new host wants to join or to leave a group, it does not care if its DR router is an ISoA one and proceeds exactly in the same way. It is worth noting that if this new leaf of the IP RP*-tree asks for QoS, the RSVP RESV message it sends in reply of the PATH message will not contain the ATM address of the DR (which is not ATM capable), but the one of the ATM network Egress Router. This ISoA router could be located at a considerable distance from the destination host, as the current assumption is that the ATM network is just a core network and the considered host is connected to it by means of simple IS routers. Case 2: the routers closest to the source are just IS router, but not ATM capable. As the case 1, in principle nothing changes until the RP*-tree is adjusted for delivering packets also to the new host. It should be clear that this time the RSVP PATH message would not carry the IP address of the source DR, but the IP address of the ATM network Ingress Router. If one or more RSVP RESV messages reach the Ingress Router (because one or more new hosts joined the group and asked for QoS), such an ISoA router will merge all the receipt RESV messages according to the RSVP protocol rules and will forward the resulting RESV message to the previous node and then hop by hop to the source, in order to reserve resources along the entire path from the source to the destinations. The overall tree will be constituted by an IP section connected to an ATM section. The previous two cases can happen simultaneously in a network whose core nodes are ATM capable, while the router closest to the source and to the destinations are just IS routers. More complex scenarios are being analyzed: in particular a scenario where multiple ATM islands are interconnected by means of IP networks. In this paper we assumed that the destination hosts never switch from a shared RP-tree to a shortest path tree (SP-tree): an open issue is the feasibility for the RP-tree leaves to switch to the SP-tree in order to reduce the traffic load in some intermediate routers and especially in the RP. With this modification the main constrain of supposing most of the nodes ATMcapable and asking for QoS could be removed, taking advantages of all the PIM-SM multicast routing protocol features.

9 R. Cocca, S. Salsano: Interaction of RSVP with ATM for the support of shortcut QoS VCs: extension to the multicast case 9 4. References [1] R. Braden, D. Clark and S. Shenker, integrated Services in the Internet Architecture: an overview, IETF RFC 1633 [2] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, Resource Reservation Protocol: Version 1 Functional Specification, RFC 2205, September 1997 [3] R. Cocca, M. Listanti and S. Salsano, Interaction of RSVP with ATM for the support of shortcut QoS Virtual Channels, ICATM, Colmar, June 1999 [4] R. Cocca, M. Listanti and S. Salsano, Internet Integrated Service over ATM: a solution for shortcut QoS Virtual Channels, IEEE Communication Magazine, December 1999 [5] T. Pusateri, Distance Vector Multicast Routing Protocol, <draft-ietf-idmr-dvmrp v3-08>, August 1999 [6] L.Wei, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu and P. Sharma, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification, <draft-ietf-pim-v2-sm-00.txt>, October 1999