Internet Draft Internet Engineering Task Force R. Guerin/S. Blake/S. Herzog INTERNET DRAFT IBM/IBM/IPHighway 21 November 1997 Aggregating RSVP-based QoS Requests draft-guerin-aggreg-rsvp-00.txt 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes issues and approaches related to aggregation of QoS requests, when RSVP [BZB+97] is the protocol used to convey such requests. Aggregation is an important component to provide scalable QoS solutions, especially in the core of the backbone where the sheer number of flows mandates some form of aggregation. However, aggregation needs to be provided without impacting the ability to provide end-to-end QoS guarantees to individual flows. In this document, we review some of the main goals of aggregation and describe possible solutions, that do not preclude support for end-to-end QoS guarantees. Those solutions are targeted at unicast flows as we expect them to represent a large fraction of the flows requesting reservation, and hence to be the main contributors to potential scalability problems with RSVP. Guerin et al. Expires 26 May 1998 [Page i] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Sample Scenario and Requirements for QoS Aggregation 2 3. Data Path Aggregation 4 3.1. Tunnel Based Aggregation . . . . . . . . . . . . . . . . 5 3.2. TOS Field Based Aggregation . . . . . . . . . . . . . . . 5 4. Control Path Aggregation 6 4.1. Tunnel Based Aggregation . . . . . . . . . . . . . . . . 7 4.1.1. Setting of Aggregate Reservations . . . . . . . . 8 4.2. TOS Field Based Aggregation . . . . . . . . . . . . . . . 9 4.2.1. Ingress-Egress Aggregation: Method 1 . . . . . . 10 4.2.2. Ingress-Egress Aggregation: Method 2 . . . . . . 13 4.2.3. Setting of Aggregate Reservations . . . . . . . . 14 5. Conclusion and Recommendations 15 A. Router Alert Options for Concealing ``Individual'' PATH Messages 17 A.1. IPv4 Syntax . . . . . . . . . . . . . . . . . . . . . . . 17 A.2. IPv6 Syntax . . . . . . . . . . . . . . . . . . . . . . . 18 Guerin et al. Expires 26 May 1998 [Page ii] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 1. Introduction As described in [Bra97], there are several facets to the support of QoS in the Internet. The aspect of QoS aggregation with RSVP falls primarily in the areas of ``Control Model'', and to some extent ``Scope'', as they are identified in [Bra97]. Specifically, the focus of QoS aggregation is on both the granularity of QoS guarantees, and their extent, i.e., from where to where. In RSVP, the granularity of a QoS request is determined through filters that specify destination address and port number, as well as source address and port number in some instances (see [BZB+97] for details). This corresponds to a very fine granularity of QoS guarantees, i.e., per flow, and while this provides end-users with accurate control, it can also translate into a substantial overhead for the network. This is particularly true for backbone links, where the sheer number of flows (there are 37,500 64kbps flows on an OC-48 link) can introduce a scalability problem. Similarly, the scope of RSVP QoS requests is end-to-end, i.e., from application to application, and while this does again provide end-users with maximum control, it can also impose substantial overhead. For example, a network administrator may want to reserve a certain amount of bandwidth to interconnect two sites across the network of an ISP. This is not readily feasible under the current RSVP specifications, which require that reservations be setup and managed between all pairs of end-users in the two sites. A possible alternative is to establish an RSVP ``tunnel'' between the two sites, and we discuss this option, but it has the disadvantage of additional encapsulation overhead and processing. As a result, the issue of QoS aggregation in the context of RSVP has two major components. The first, is an extension to RSVP to support ``aggregate'' QoS requests, i.e., on behalf of a set of flows rather than individual flows. For example, the set of flows to which an aggregate request would apply, could correspond to traffic between a given source subnet and a given destination subnet. Support for such aggregate requests is not available from the current RSVP specifications, and would require the definition of new filter specifications. One possible example are the CIDR prefix based filters suggested in [Boy97]. The introduction of such extensions is certainly key to increasing the applicability of RSVP as a generic reservation protocol, but in this document we instead focus on the second and more immediate aspect of QoS aggregation for RSVP. Specifically, we consider the problem of aggregating a large number of individual RSVP requests to improve scalability, e.g., on backbone links, without precluding support for individual QoS guarantees where feasible, e.g., on low speed links and local networks. In other Guerin et al. Expires 26 May 1998 [Page 1] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 words, the focus of QoS aggregation in this document, is to provide the means for ensuring individual end-to-end QoS guarantees, but without requiring that awareness of individual flows be maintained on each and every segment of their path. This is an important issue as the need for maintaining and updating a large number of individual RSVP flow states has been often mentioned as a major obstacle to the widespread deployment of RSVP. The goals of this document are, therefore, to review and address the potential scalability problems that have been identified with the CURRENT RSVP specifications, and propose possible solutions. The rest of this document is structured as follows. In Section 2, we first describe a sample scenario illustrating the constraints and aspects of QoS aggregation with RSVP. In Sections 3 and 4, we identify specific goals when supporting QoS aggregation for RSVP, and propose possible aggregation solutions to achieve them. 2. Sample Scenario and Requirements for QoS Aggregation Consider the network topology of Figure 1. It consists of three separate AS, with the two edge AS (AS1 and AS3) corresponding to local AS and the middle one (AS2) representing a backbone interconnecting the two. For the purpose of our discussion on QoS aggregation, we assume that scalability is of concern only in the backbone AS2, i.e., AS1 and AS3 are capable of maintaining RSVP state information for all the individual flows that originate and terminate in them. Furthermore, and without loss of generality, we focus on RSVP flows between AS1 and AS3 that cross AS2. In that context, QoS aggregation is of concern only for AS2. AS1 AS2 AS3 ________ ________________ _________ / \ / \ / \ / \ / \ / \ | Access | | Backbone | | Access | | Network |----| Network |----| Network | | | | | | | \ / \ / \ / \________/ \________________/ \_________/ Figure 1: Sample Network Configuration Guerin et al. Expires 26 May 1998 [Page 2] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 Aggregation of individual RSVP flows through AS2 must satisfy a number of requirements, which we briefly review. R1 AS2 should not have to maintain awareness of individual RSVP flows between AS1 and AS3. Instead, AS2 should be able to map individual RSVP flows onto few internal service ``classes''. R2 AS2 should ensure that it satisfies the QoS requirements of individual RSVP flows, e.g., the resources allocated to a service class in AS2 should at least be equal to the aggregate resources required by all the individual flows mapped onto it. R3 Isolation between flows should be maintained in AS2, i.e., even when flows are aggregated into a common service class, the excess traffic of one flow should not affect the performance guarantees of another flow. R4 Aggregation in AS2 should not prevent support for individual flow reservations in AS1 and AS3. Requirement R1 is the core scalability requirement expressed by AS2. It basically states, that because QoS support within AS2 is provided through much coarser mechanisms than the control and allocation of resources to individual RSVP flows, of which there could be way too many, it is necessary for individual RSVP flows to be mapped onto one of the internal class-based mechanisms supported by AS2. Coarser class-based mechanisms are usually mandated by the speed of the backbone links, where the time available for making packet forwarding and scheduling decisions is often not sufficient to accommodate per flow operations. In addition to the constraint on forwarding and scheduling decision, there is a similar limitation on the amount of control information that a backbone node is capable of maintaining and updating. Specifically, maintaining path and reservation control blocks for individual flows may not be not practical in AS2. Requirements R2 and R3 specify properties, that the mapping of individual RSVP flows onto the coarser ``classes'' of AS2 has to satisfy. First and foremost, requirement R2 expresses the need for some coupling between the resources (bandwidth and buffer) and level of service (priority) assigned to a class in AS2, and the aggregation of the individual RSVP flows mapped onto that class. For example, this means that the amount of bandwidth assigned to a class should be sufficient to accommodate the traffic of all the RSVP flows mapped onto it. This must remain true even as flows modify their reservations. Furthermore, requirement R2 also points to the fact that services classes in AS2 must be defined so as to ensure they can meet the QoS guarantees of any individual flow mapped onto them. This typically means that flows mapped onto the same service class Guerin et al. Expires 26 May 1998 [Page 3] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 must exhibit some level of homogeneity in their QoS requirements, or that the service class is dimensioned to meet the most stringent QoS requirements of the individual flows mapped onto it. Requirement R3 is a direct result of the aggregation of individual flows. The QoS guarantees provided to an individual RSVP flow are limited to its conformant packets, i.e., packets that comply with the advertised TSpec of the flow. Checking compliance with a flow TSpec is readily achieved when per flow awareness is maintained, but is lost after flows have been aggregated. In particular, violation of an aggregate TSpec (``sum'' of individual TSpec's) can be caused by a single non-conformant flow, but can impact the QoS guarantees experienced by all the flows that have been aggregated. As a result, some mechanism is needed to identify non-conformant packet even after flows have been merged. One possible approach is to use a ``tagging'' capability as suggested in [CW97]. Requirement R4 expresses the important constraint that satisfying scalability in AS2, should not come at the expense of functionality in AS1 and AS3. Specifically, the aggregation of control and data path information in AS2 should be reversible, so that reservations in AS1 and AS3 can default back to individual flows after crossing AS2. In other words, the hiding of individual flow information in AS2 should not prevent reservations at a finer level of granularity in AS1 and AS3, so that end-to-end RSVP reservations can be supported. This means that for RSVP flows, AS2 should essentially behave as a single RSVP ``node''. Reservation of resources within a node are transparent to RSVP, but should not affect end-to-end operation. In the next sections, we qualify how the above requirements translate into specific goals to support aggregation, and also describe possible approaches to satisfy these requirements. 3. Data Path Aggregation On the data path, the main issue is the classification of data packets to determine the level of QoS they are eligible to receive. Performing this classification on the basis of bit patterns that are specific to individual flows, i.e., source and destination addresses and port numbers, may not scale. Specifically, storing all the patterns corresponding to individual flows holding a reservation and extracting the corresponding patterns from all incoming packets, can represent a substantial per packet processing overhead. As a result, the goal of an aggregation solution is to map all the bit patterns used to classify individual flows with reservations onto a much smaller number of patterns. There are several possible approaches to achieve such a mapping. Guerin et al. Expires 26 May 1998 [Page 4] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 3.1. Tunnel Based Aggregation A first solution is to rely on RSVP tunnels. In other words, an RSVP tunnel is created between any two ingress and egress points for which there exists at least one RSVP flow across AS2. At the ingress, packets (data and control) belonging to the corresponding RSVP flows are encapsulated in IP packets with an IP destination address identifying the egress point from AS2. The egress point is then responsible for the reverse decapsulation process before forwarding packets towards their next hop. As a result of encapsulation, routers on the path in AS2 only require a single entry to classify packets from all the associated RSVP flows. The main disadvantages of this solution are the data and processing overheads associated with encapsulation, as well as the need for close synchronization with routing. Specifically, the mapping of individual RSVP flows onto a given egress point from AS2 depends on routing information, and route changes need to be closely monitored to determine if and when they affect this mapping. In addition to these disadvantages, tunnels *alone* do not easily address the above requirement R3 concerning flow isolation. This is because after encapsulation, conformant packets from one flow cannot be distinguished from non-conformant packets of another flow. As a result, it is necessary to discriminate between conformant and non-conformant packets at the ingress point of a tunnel, e.g., send non-conformant packets as regular (non-encapsulated) packets through AS2. While this satisfies requirement R3, it does so at the cost of potentially unnecessary penalization of RSVP flows, e.g., out-of-order delivery, even in the absence of congestion in AS2. 3.2. TOS Field Based Aggregation A number of other approaches for aggregation have been brought forward, [CW97, BV97, Hei97, Kil97], with several [CW97, Hei97, Kil97] proposing the use of fewer bits in the IP header for classification purposes. In particular, it has been suggested to use the TOS octet field [Pos81] to specify different service classes as well as drop precedence. From the point of view of aggregation of RSVP flows, this means that RSVP data packets are assigned a value for the TOS field in their IP header, that is a function of both their service class, e.g., Controlled Load [Wro97a] or Guaranteed Service [SPG97], and whether the packet is conformant or not. Specifically, several (the exact number is tbd and a function of the number of distinct service classes that are deemed necessary) TOS bits are used to specify service classes. Data packets from RSVP flows entering AS2 then have the TOS field in their IP header set Guerin et al. Expires 26 May 1998 [Page 5] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 accordingly to reflect the service class they have requested. As a result, routers in AS2 can classify packets using TOS bit patterns instead of full filters. Conceptually, on a link at a router in AS2, each service class is identified through its assigned TOS bit pattern and mapped onto a separate transmission queue, that has been allocated sufficient resources (bandwidth and buffers) to satisfy the QoS requirements of the aggregation of flows it carries. In addition to the TOS bits identifying the service class to which the data packets of RSVP flows belong to, one more bit from the TOS field is needed to indicate conformance of packets from each flow to their corresponding TSpec. This explicit indication of non-conformant packets is key to enforcing flow isolation (requirement R3) and ensuring that the QoS guarantees of individual flows are met in spite of their aggregation into a common class. For example, as has been suggested, the conformance bit can be used by routers in AS2 to implement a ``drop precedence'' policy to preferentially discard non-conformant packets in case of congestion. In general, ensuring that the aggregate resources allocated to each service class are adequate to satisfy the QoS guarantees of individual RSVP flows, i.e., requirements R2 and R3, requires coupling to the RSVP control path and this aspect is discussed in the next section. However, before addressing this issue, it should be noted that the above approach offers a number of benefits above those afforded by the previous tunneling solution. First, it avoids the overhead of encapsulation. Second, the ingress and egress processing required is minimal, i.e., update of the TOS field in the IP header (note that this could even be performed in the end-stations themselves). Third, it does not require any interactions with routing above and beyond what is normally required by RSVP. In other words, aggregation is supported in a manner that is essentially transparent to RSVP. 4. Control Path Aggregation The aggregation of control information associated with individual RSVP flows is just as important for scalability as its data path counterpart. Specifically, maintaining PATH and RESV states for individual RSVP flows can represent a substantial burden in backbone routers which need to support a large number of flows. The goal of QoS aggregation is then to eliminate or at least minimize the amount of per flow control information that needs to be maintained. As with data path aggregation, this needs to be done while maintaining the QoS guarantees requested by individual flows. In particular, the resources allocated to a set of aggregated flows must reflect the ``sum'' of the reservation requests conveyed in individual RESV Guerin et al. Expires 26 May 1998 [Page 6] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 messages. Making sure this and the several requirements identified earlier (requirement R2, R3, and R4) are met, varies according to the data path aggregation method used. Note that aggregation also offers the opportunity for greater efficiency because of the potential benefits of statistical multiplexing. However, some care must be applied to avoid under-provisioning of resources in the backbone, e.g., aggregation may affect measurement based call admission rules in backbone routers. 4.1. Tunnel Based Aggregation When QoS aggregation is achieved through the use of an RSVP tunnel, all RSVP control messages for individual flows are encapsulated and, therefore, not seen by any of the intermediate routers (in AS2). However, because those messages are carried across the tunnel, after decapsulation at the egress router, they will be forwarded as usual so that reservations for individual RSVP flows can still be established on the rest of the path, i.e., in AS1 and AS3. Note that because individual PATH messages are encapsulated, their ADSPEC is not updated as they cross the backbone. At the egress router of the tunnel, updating the ADSPEC in the PATH messages of individual flows is carried out using the corresponding ADSPEC fields from the PATH messages of the tunnel itself. Specifically, hop count, path latency, service specific quantities such as Guaranteed Service error terms, etc., are all updated as if the ADSPEC values for the tunnel were those of a single ``node'' (AS2 is considered as one node). As far as the tunnel is concerned, its establishment is the responsibility of the ingress and egress routers at its end-points, which generate new RSVP control messages with their address as the source and destination addresses (1). In addition, the traffic specification (TSpec) and reservation levels (FLOWSPEC) specified in these messages need to adequately reflect the requirements of the flows aggregated into the tunnel. In particular, the type of service used for a tunnel should match that of the flows being aggregated on the tunnel, e.g., Controlled Load flows should be aggregated onto a Controlled Load tunnel. ---------------------------- 1. Note that a possible alternative is to use a layer 2, e.g., ATM, tunnel, which would then be setup using the available layer 2 signalling. Guerin et al. Expires 26 May 1998 [Page 7] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 4.1.1. Setting of Aggregate Reservations In the case of a Controlled Load tunnel, the aggregate TSpec used in the PATH messages for the tunnel, needs to be selected so as to accommodate the TSpec's of all the flows it aggregates. A natural selection is to choose the sum of the TSpec's of all the individual flows being aggregated (see [Wro97b] for a discussion on how TSpec's are to be summed). Similarly, the TSpec specified in the FLOWSPEC of the RESV messages for the tunnel should again be chosen to ensure that the aggregated flows receive a level of service consistent with their individual requests. One option is to again select the sum of individual FLOWSPEC's, although as mentioned above the potential benefits of statistical multiplexing may allow a lower reservation level. Irrespective of the aggregate reservation level specified, satisfying the QoS guarantees of individual flows is also predicated on the ``proper'' handling of excess traffic, i.e., packets from each flow that do not conform to their individual TSpec. Specifically, excess traffic MUST NOT be forwarded onto the RSVP tunnel, unless some form of explicit identification of excess traffic is provided. For example, this could be achieved through the use of a bit from the TOS field in the IP header of packets as suggested in Section 3.2. The case of a Guaranteed Service Tunnel is somewhat more involved. There are two issues that need to be addressed. The first is the update of the ADSPEC in the PATH messages of individual flows at the egress router (see [SPG97] for details on the use of ADSPEC). The second is the selection of appropriate TSpec and RSpec for the tunnel, so that the delay bounds of all individual flows can be guaranteed. The handling of these two issues are not independent, and there are many possible solutions. In this document, we outline only one of several alternatives. The update of the ADSPEC can be done as described before, using the ADSPEC values of the tunnel. The determination of appropriate TSpec and RSpec values for the tunnel, essentially follows the method described in [RG97]. Specifically, the TSpec used for the tunnel needs to be at least the ``sum'' of the TSpec's of the individual flows. Similarly, the reserved rate R of the RSpec is determined using eqs. (6) and (7) of [RG97], with the only difference that the individual delay bounds used in eq. (7) are only for the portion of the flows paths that coincide with the tunnel. This partial delay bound for individual flows is readily computed from the TSpec of individual flows, their RSpec, and the error terms for the portion of their path that corresponds to the tunnel. Guerin et al. Expires 26 May 1998 [Page 8] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 It should be pointed out that as mentioned in [RG97], the resulting aggregate reservation rate for the tunnel can be either smaller or bigger than the sum of the individual reservation rates. Another point worth noting concerns the possible use of the slack term, in particular when individual flows specify a non-zero slack and a reservation rate R equal to their token rate r, i.e., they could tolerate a higher delay but cannot ask for a lower rate. In the case of a tunnel, the slack could be used to increase the individual delay bound for that flow used in eq. (7), provided that the SUM of the token rates of individual flows remains smaller than or equal to the aggregate reservation rate. 4.2. TOS Field Based Aggregation The case of TOS based QoS aggregation is different from that of a tunnel because the egress point associated with a particular flow is not identified *a priori* at the ingress router. This has the advantage of eliminating the need for an ingress router to continuously interact with routing to monitor possible changes in egress routers and mapping of individual flows into tunnels. However, this means that some other mechanisms are needed to ensure that the appropriate amount of resources is reserved for RSVP flows between the associated ingress and egress routers. There are many possible approaches that one can follow, and in this document we describe two, which we feel represent reasonable trade-offs between simplicity and minimization of backbone overhead. Other alternatives are clearly possible. In both approaches, as in the tunneling case, a key goal is to avoid or at least minimize awareness and/or processing of individual flows in the backbone. Satisfying this goal has several requirements and implications: - Disable processing of (most) individual RSVP messages in the backbone, while still allowing their identification when they arrive at egress or ingress routers. - Identify transparently, i.e., without relying on interactions with routing, the egress routers corresponding to individual flows entering the backbone at an ingress router. - Reserve the appropriate amount of resources on backbone links to satisfy the requirements of individual flows routed over them. - Properly update RSVP PATH messages of individual flows at egress routers. Guerin et al. Expires 26 May 1998 [Page 9] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 In what follows, we describe two possible approaches to achieving those goals. 4.2.1. Ingress-Egress Aggregation: Method 1 Next, we describe a first approach, and the steps performed at ingress and egress routers to both identify each other and ensure proper aggregation of flows and allocation of resources between them. - For new flows, the ingress router starts forwarding ``individual'' PATH messages carrying a Policy Object containing its IP address. Receipt of those individual PATH messages provides the associated egress routers with the identify of the ingress router for the flow. The individual PATH messages are initially processed by the backbone routers, and reach the egress router with updated ADSPEC information. - Upon receiving an ``individual'' PATH message with a policy object specifying a new ingress router, the egress router logs the association between the flow and the ingress router and forwards the PATH message. - Upon receipt of a RESV message (2) for a flow, the egress router forwards the ``individual'' RESV message with a Policy Object specifying its IP address. The Policy Object will eventually be delivered to the ingress router, and inform it of the identity of the egress router associated with the flow. - Upon receipt of a RESV message identifying a new egress or when the ingress router deems there are sufficient flows to a given egress to consider aggregating them, it starts sending PATH message destined to this egress and representing the aggregation of all flows destined to it. At the same time, the ingress router starts sending the PATH messages corresponding to individual flows, in a format that ``hides'' them from backbone routers (more on this below) but not the egress router. - Upon receipt of a PATH message destined to itself, the egress router sends a RESV message with an aggregate reservation for all the flows it has logged as coming from the associated ingress ---------------------------- 2. Alternatively, the egress router could generate a ``fake'', e.g., near zero reservation, RESV message immediately after receiving the first PATH message. This has the benefit of faster awareness about the egress at the ingress. Guerin et al. Expires 26 May 1998 [Page 10] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 router. At the same time, it starts sending RESV messages for the individual flows directly to the ingress router. This ensures that they will not be processed by backbone routers, and any existing reservations for individual flows in the backbone will time out. Note that to lower the potential for call admission failure, the egress router may want to progressively increase the reservation level in its aggregate RESV message. This may give it a better chance of recapturing bandwidth as it is being released, when reservation states of individual flows time out. - Upon receipt of ``hidden'' PATH messages for individual flows, the egress router changes them back to ``standard'' PATH messages and updates them with the ADSPEC information from the PATH message originated by the associated ingress router before forwarding them downstream. - Upon receipt of RESV messages for individual flows from a known egress router, the ingress router simply forwards them upstream. The above steps ensure that ingress and egress routers become aware of each other without having to directly query routing, and also ultimately removes awareness of individual flows in backbone routers. However, it is still necessary to describe how route changes within the backbone are handled. This is tightly coupled to the approach used to ``hide'' RSVP PATH messages in the backbone, and we therefore describe this next. In the case of tunnels, individual RSVP messages were ``hidden'' on backbone links because they were encapsulated within another IP header. As a result backbone routers would forward them as regular IP packets. Furthermore, because the destination address in the encapsulating IP header was that of the egress (ingress) router, decapsulation would be performed and ensure proper identification and processing of the RSVP messages. Such a solution is not applicable in the case of TOS based aggregation, because of the decoupling from routing, i.e., identity of egress or ingress, if known, cannot be used to ensure delivery of RSVP messages There are several possible options to overcome those problems while avoiding processing of RSVP messages from individual flows in the backbone. Processing of RSVP (PATH) messages from individual flows in the backbone can be avoided simply by hiding the information used to trigger RSVP processing, i.e., turn the router-alert option [Kat97, KAPJ97] off at the ingress router. The problem is then that without the router-alert option on, the egress router will also fail to identify, and therefore intercept and process those PATH messages. Guerin et al. Expires 26 May 1998 [Page 11] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 There are several possible solutions to this problem. One is to use some other bit pattern in the IP header, that can be used by egress routers to identify RSVP PATH messages from individual flows. For example, a TOS bit combination could be assigned to indicate ``aggregated control information.'' Routers responsible for de-aggregating control information, e.g., egress routers, would then intercept such packets, while other routers (backbone routers) would ignore them. Another option is to require that egress routers examine the protocol number of all arriving packets, even when the router alert option is not set. This may, however, impose a significant performance penalty. A third option is to keep the router alert option set, but use a different protocol number inside the backbone. Backbone routers would still intercept RSVP PATH messages from individual flows, but not need to process them any further, i.e., upon identifying the new protocol number they would simply forward the packet on. A last option is to define a *new* router alert option for ``Unaggregated RSVP'' messages, which would be silently ignored by backbone routers, but recognized by access (ingress/egress) routers. This last alternative (see Appendix A for additional details) appears to provide a reasonable trade-off, that ensures the required functionality at egress routers while keeping the backbone overhead reasonable. Assuming that one of the above mechanisms is being used, PATH messages for individual flows are now being automatically delivered directly from ingress routers to the appropriate egress routers. However, note that PATH messages are not being processed at any of the backbone routers they traverse. The main implication for the egress is that the ADSPEC field of the PATH messages has not been updated to reflect the characteristic of the backbone path they have traversed. As a result, they cannot be readily propagated forward by the egress router, unless the information needed to properly update their ADSPEC is *already* available at the egress router. This is one of the motivations for the above choice of initially sending individual PATH messages into the backbone, as this enables the egress to first acquire the necessary information to update the ADSPEC of ``hidden'' PATH messages. However, this approach does not address the problem in case of route changes in the backbone. Route changes in the backbone result in ``hidden'' PATH messages being delivered to a *new* new egress, without being preceded by corresponding ``clear'' PATH messages. As a result, the new egress does not have the necessary information to update the ADSPEC of the ``hidden'' PATH messages it starts receiving. Hence, those messages cannot be propagated forward. In order to address this problem, the ingress router needs to become aware of the route change. The Guerin et al. Expires 26 May 1998 [Page 12] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 simplest approach is to rely on RSVP soft states. Basically, the ingress router will detect that it stops receiving RESV messages from the old egress routers (at least for the flows affected by the route change). It can then use that information as a trigger to start forwarding the PATH messages of those flows again as *regular* RSVP PATH messages. As a result, they will be processed by intermediate backbone routers, and we are back to the initial case described above. 4.2.2. Ingress-Egress Aggregation: Method 2 In this section, we describe a second alternative, which is mostly a variation on the general method described in the previous section. The main motivation for this variation is to avoid *all* processing of individual RSVP flows in the backbone. This is desirable as even the limited processing of individual RSVP flows required from backbone routers by method 1, can represent a substantial processing load when flows are of short duration. In addition, this second method can avoid reliance on Policy Objects. The main difference with the previous method is that the PATH messages from individual flows are not sent directly in the backbone. Instead, they are always forwarded as ``hidden''. The main issue is then to determine how to inform the ingress router of the identity of the egress router associated with each individual flow, without relying on explicit queries to routing. We describe next, the different steps involved in addressing this issue. - Upon receipt of a new PATH message, the ingress router forwards it as ``hidden'' into the backbone. - On receipt of a hidden PATH message for a new flow, the egress router immediately notifies the ingress router of its existence (the identity of the ingress is carried in the PHOP of the PATH message). This notification can take several forms. One possibility is for the egress router to generate a PATH_ERR message (with some appropriate new error code) directly destined to the ingress router. Another possibility is for the egress router to generate a ``fake'' RESV message with near-zero reservation (FLOWSPEC). Note that as discussed earlier, ``hidden'' PATH messages cannot be forwarded until the information needed to update their ADSPEC is available (more on this below). - On receipt of a ``fake'' RESV or a PATH_ERR from a new egress, the ingress proceeds to send a ``regular'' aggregate PATH message to that egress. Guerin et al. Expires 26 May 1998 [Page 13] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 - On receipt of an aggregate PATH message (destined to itself), the egress now has the information necessary to update the ADSPEC of the individual PATH message and can start forwarding it. The main disadvantage here is the latency incurred in forwarding the individual PATH message. However, this latency is typically only incurred by the first flow from a given ingress. The egress can use the ADSPEC from the aggregate PATH message to update and immediately forward the PATH messages of subsequent flows from that ingress. - On receipt of a new RESV message for an individual flow, the egress sends a RESV message associated with the aggregate PATH from the corresponding ingress (or updates an existing RESV). The individual RESV messages are then forwarded directly to the ingress router. As mentioned earlier, the method embodied in the above steps avoids any processing of individual flows in the backbone. The cost is an increased latency in propagating the first PATH message of the first flow from the associated ingress. 4.2.3. Setting of Aggregate Reservations Proper selection of appropriate aggregate reservation levels requires some care, especially for Guaranteed Service flows. For Controlled Load flows, it is only necessary that in backbone routers the queue assigned to Controlled Load traffic, be allocated the proper service rate. Since rate is an additive quantity, aggregate reservations can be based on the sum of the FLOWSPECs of individual flows. The situation is again more complex for Guaranteed Service flows. The main difference with the tunnel-based case, is that on any link in the backbone the overall aggregation of packets/flows with the same TOS value (corresponding to the Guaranteed Service) is not know to either the ingress or egress routers associated with individual RSVP flows whose route through the backbone includes that link. As a result, the egress router cannot use the approach of Section 4.1.1 to determine an appropriate aggregate service rate, that will ensure that all individual delay bounds are met. In order to support aggregated Guaranteed Service flows in this setting, it is necessary to change the ``node model'' used to represent the backbone. Specifically, an approach similar to the one used in the ISSLL drafts to account for ATM networks, can be used. It amounts to representing the backbone as a delay only node. In other words, the backbone only contributes to the D error term of the ADSPEC and not the C term. The main difference with an Guerin et al. Expires 26 May 1998 [Page 14] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 ATM network is that, contrary to ATM switches, individual backbone routers will update the ADSPEC in PATH messages. In order to ensure a behavior consistent with that of a delay-only node, each individual router needs to only update the D error term of the ADSPEC of PATH messages it processes. The implication of this behavior is that the scheduling and call admission support for Guaranteed Service flows in backbone routers, will be based on ensuring a fixed delay upper bound for the TOS queue assigned to Guaranteed Service packets. This delay upper bound will then be the quantity used to update the D error term in the ADSPEC field of PATH messages. 5. Conclusion and Recommendations In this draft we have outlined issues and proposed possible approaches to allow aggregation of individual RSVP flows, without precluding support for individual reservations where available. This can enable delivery of the end-to-end and per flow QoS guarantees supported by RSVP and the Int-Serv Services, while avoiding possible scalability limitations. As a result of this exercise, several requirements emerged to support the different aggregation methods that were discussed. These requirements are summarized below': - Allocation of one bit from the TOS field of the IP header to specify in-profile and out-of-profile packets. - Allocation of one bit pattern from the TOS field that can be mapped to the Controlled Load service, and at least one bit pattern from the TOS field that can be mapped to the Guaranteed Service (two would be preferable to provide some granularity in the delay bounds for Guaranteed Service flows). - Support for a mechanism to selectively ``hide'' RSVP control messages. Specifically, the preferred mechanism is through the introduction of an new Router Alert option, that can be selectively recognized or ignored in routers. References [Boy97] J. Boyle. RSVP extensions for CIDR aggregated data flows, (draft-rsvp-cidr-ext-00.txt). Internet draft (work in progress), Internet Engineering Task Force, February 1997. [Bra97] S. Bradner. Internet protocol quality of service problem statement, (draft-bradner-qos-problem-00.txt). Internet Guerin et al. Expires 26 May 1998 [Page 15] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 draft (work in progress), Internet Engineering Task Force, September 1997. [BV97] S. Berson and S. Vincent. A ``classy'' approach to aggregation for integrated services, (draft-berson-classy-approach-00.txt). Internet draft (work in progress), Internet Engineering Task Force, March 1997. [BZB+97] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource reSerVation Protocol (RSVP) version 1, functional specification. Request for comments, rfc 2205, (proposed standard), Internet Engineering Task Force, September 1997. [CW97] D. Clark and J. Wroclawski. An approach to service allocation in the Internet, (draft-clark-diff-svc-alloc-00.txt). Internet draft (work in progress), Internet Engineering Task Force, July 1997. [Hei97] J. Heinanen. Use of the IPv4 TOS octet to support differential services, (draft-heinanen-diff-tos-octet-00.txt). Internet draft (work in progress), Internet Engineering Task Force, October 1997. [KAPJ97] D. Katz, R. Atkinson, C. Partridge, and A. Jackson. IP router alert option, (draft-ietf-ipngwg-ipv6-router-alert-03.txt). Internet draft (work in progress), Internet Engineering Task Force, July 1997. [Kat97] D. Katz. IP router alert option. Request for comments, rfc 2113, (proposed standard), Internet Engineering Task Force, February 1997. [Kil97] K. Kilkki. Simple integrated media access (SIMA). (draft-kalevi-simple-media-access-01.txt). Internet draft (work in progress), Internet Engineering Task Force, June 1997. [Pos81] J. Postel. Internet protocol. Request for comments, rfc 791, (standard), Internet Engineering Task Force, September 1981. [RG97] S. Rampal and R. Guerin. Flow grouping for reducing reservation requirements for Guaranteed Delay service, (draft-rampal-flow-delay-service-01.txt). Internet draft (work in progress), Internet Engineering Task Force, July 1997. Guerin et al. Expires 26 May 1998 [Page 16] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 [SPG97] S. Shenker, C. Partridge, and R. Guerin. Specification of guaranteed quality of service. Request for comments, rfc 2212, (proposed standard), Internet Engineering Task Force, September 1997. [Wro97a] J. Wroclawski. Specification of the controlled-load network element service. Request for comments, rfc 2211, (proposed standard), Internet Engineering Task Force, September 1997. [Wro97b] J. Wroclawski. The use of RSVP with IETF integrated services. Request for comments, rfc 2210, (proposed standard), Internet Engineering Task Force, September 1997. A. Router Alert Options for Concealing ``Individual'' PATH Messages As discussed in Section 4.2, the scalability of RSVP is improved when using TOS field based aggregation if the PATH messages from individual applications are concealed from the interior routers in the backbone. PATH messages are addressed either to a destination host or multicast group and are transmitted with the IP router alert option as defined in [Kat97] or [KAPJ97]. This allows routers along their transit path to intercept the packets for RSVP processing. To prevent the backbone routers from intercepting and processing the PATH messages from individual applications, while allowing the aggregating egress routers to recognize and intercept them, a new router alert option value may be used. The syntax of the IPv4 router alert option is defined as follows [Kat97]: A.1. IPv4 Syntax The Router Alert option has the following format: +--------+--------+--------+--------+ |10010100|00000100| 2 octet value | +--------+--------+--------+--------+ Type: Copied flag: 1 (all fragments must carry the option) Option class: 0 (control) Option number: 20 (decimal) Length: 4 Guerin et al. Expires 26 May 1998 [Page 17] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 Value: A two octet code with the following values: 0 - Router shall examine packet 1-65535 - Reserved The specification states that ``Unrecognized value fields shall be silently ignored''. The syntax of the IPv6 router alert option is defined as follows [KAPJ97]: A.2. IPv6 Syntax The router alert option has the following format: +--------+--------+--------+--------+ |00| TBD | Len= 2 | Value (2 octets)| +--------+--------+--------+--------+ ``TBD'' is the Hop-by-Hop Option Type number (To be allocated by the IANA). Nodes not recognizing this option type SHOULD skip over this option and continue processing the header. This option MUST NOT change en route. There MUST only be one option of this type, regardless of value, per Hop-by-Hop header. Value: A 2 octet code in network byte order with the following values: 0 Datagram contains ICMPv6 Group Membership message. 1 Datagram contains RSVP message. 2 Datagram contains an Active Networks message \cite{ANEP97}. 3-65535 Reserved to IANA for future use. New value fields must be registered with the IANA. This specification states that ``Unrecognized value fields MUST be silently ignored and the processing of the header continued''. There are two alternatives which will satisfy the requirement to ``hide'' application PATH messages (when necessary) from the backbone routers: Guerin et al. Expires 26 May 1998 [Page 18] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 - Define a 2 octet router alert option value for both IPv4 and IPv6 which signifies that the datagram contains an ``Unaggregated RSVP Message''. The router should silently ignore this router alert option and continue to forward the packet unless specifically configured to recognize and intercept it. - Define a 2 octet router alert option value for both IPv4 and IPv6 which signifies that the router should ``Ignore by Default''. The router should silently ignore this router alert option and continue to forward the packet unless specifically configured to recognize and intercept it. PATH messages from individual applications would be transmitted by the aggregating ingress router using either router alert option value (whichever is defined) whenever it employs TOS field based aggregation to a particular egress router. Aggregated PATH messages to that router would be transmitted with the default router alert option value used for RSVP. The backbone routers would be configured to ignore router alert options using this new option value. The aggregating egress routers would be configured to intercept packets transmitted with the new router alert option value. Authors' Address Roch Guerin IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 Phone: +1 914 784-7038 Fax: +1 914 784-6205 Email: guerin@watson.ibm.com Steven Blake E95/664 IBM Corporation 800 Park Offices Drive Research Triangle Park, NC 27709 Phone: +1-919-254-2030 Fax: +1-919-254-5483 Email: slblake@raleigh.ibm.com Guerin et al. Expires 26 May 1998 [Page 19] Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997 Shai Herzog IPHighway Email: herzog@iphighway.com Guerin et al. Expires 26 May 1998 [Page 20]