PADS BOF Ruediger Geib Internet Draft Deutsche Telekom T-Systems Document: draft-geib-sig-guarandif-00.txt Expires: August 2003 February 2003 On demand services with throughput guarantees over DiffServ networks draft-geib-sig-guarandif-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract On demand Internet services with guaranteed throughput are the major driver behind QoS signaling architectures. Guaranteeing throughput between two defined points of a DiffServ network requires a combination of flow information and Per Hop Behaviour. Handling aggregates instead of flows as specified by the DiffServ architecture is the most reasonable attempt to do so. This document describes an architecture using DiffServ mechanisms to provide on demand throughput guarantees between two points of a DiffServ network. Geib Informative [Page 1] Throuhput Guarantees over DiffServ February 2003 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction...................................................2 1.1 DiffServ based throughput guarantees........................2 1.2 Example.....................................................3 2. Signaling architecture.........................................5 2.1 On path signaling architecture..............................6 2.2 Off path signaling architecture.............................6 3. Security.......................................................6 4. Conclusions....................................................7 Author's Address..................................................7 Full Copyright Statement..........................................7 1. Introduction On demand Internet services with guaranteed throughput are the major driver behind QoS signaling architectures. IntServ/RSVP is a first solution to the issue. Per flow state maintenance kept backbone providers from deployment. The DiffServ architecture enables differentiated treatment of packets without per flow state maintenance. Aggregated RSVP offers a reduction of per flow state maintenace in backbones. Yet, on demand services with throughput guarantees aren't generally available. The NSIS WG will specify new signaling mechanisms which will ease deployment of advanced on demand services. The NSIS charter limits the resulting standards to on path signaling and service management. In some cases, considerable additional signaling and state management requirements may result from this requirements. This document describes an architecture providing low service related signaling requirements while attaining on demand services with throughput guarantees over a DiffServ network. 1.1 DiffServ based throughput guarantees Guaranteeing throughput of a communication service requires control of the resources made available to the transmitted information and control of admission of sources to the network providing the throughput guarantee. Assignment of resources for IP packets requires a non-ambiguous identification of these packets. The most secure way in doing so is applied by IntServ/RSVP: the well known 5 tuple of addresses, port numbers and application. DiffServ reduced the amount of code-space to be checked per packet to a single byte, resulting in reduced processor requirements of routers assigning QoS resources to packets. The DiffServ architecture however supports a one point Geib Informative [Page 2] Throuhput Guarantees over DiffServ February 2003 throughput guarantee only: it is valid at the point where the marked traffic enters another DiffServ domain. A carrier willing to guarantee a certain throughput for traffic entering his network at a known origin edge router and leaving his network at a known destination router would have to assign resources based on DiffServ Code point in combination with at least the destination IP address. This would add processing requirements and require changes in DiffServ router implementations. Adding the two bits reserved for experimentation, DiffServ allows 256 choices of codepoints. Once a DiffServ Code Point identifies a differentiated packet treatment as well as the destination of that packet, a point to point throughput guarantee is possible without changing current router implementations of DiffServ. The only thing changed is the interpretation of the DiffServ Code Point. Clearly, scaleability of such a solution is severly limited. Still, the benefits make a close consideration of a service architecture worth being done: - Destination based on demand resource assignment is required at the origin edge router only. Hence DSCPs identifying traffic class and destination on an access link are re-written to a single DSCP identifying the traffic class within the carrier network. - Within the carrier network resources are pre-provisioned. Admission control ensures that new senders are only admitted if the required network resources still are available. Admission control is performed for all links passed by guaranteed throughput traffic from origin to destination edge router. - providing the throughput service in an on demand mode only reduces the probability of inactive reservations consuming one of the rare DSCPs. - The service operated as described is restricted to a single carrier network. In principle, the same method may be applied in a cascaded mode, i.e. at customer to local provider interface and again at local provider to carrier interface. - A signaling mechanism must be used to indicate applicable DSCPs to a sender network and to allow admission control along the links between origin edge node and destination edge node of the network providing the throughput guarantee. 1.2 Example Figure gives an example. Source nodes S1-4 request throughput guarantees for their traffic to destination nodes D1 and D2 from the carrier network represented by Source edge routers SER1-2, Core router C1 and destination edge routers D1-2. The throughput guarantee expands from Sn-Dn. Geib Informative [Page 3] Throuhput Guarantees over DiffServ February 2003 +----+ +----+ | S1 |-----\ /--------| D1 | +----+ \+----+ / +----+ |SER1| / +----+ /+----+\ / | S2 |-----/ \ / +----+ +----+ +----+/ | C1 |-------|DER1| +----+ +----+ +----+\ | S3 |-----\ / \ +----+ \+----+/ \ |SER2| \ +----+ /+----+ \ +----+ | S4 |-----/ \--------| D2 | +----+ +----+ Not assuming any specific signaling architecture, the resulting resources and admission control decisions may look as follows: S1-SER1: Available Bandwidth for service 10, Ressource assignment to D1 4, Session ID D1a, DSCP41 Ressource assignment to D2 2, Session ID D2a, DSCP42 S2-SER1: Available Bandwidth for service 10, Ressource assignment to D2 3, Session ID D2b, DSCP43 S3-SER2: Available Bandwidth for service 10, Ressource assignment to D1 2, Session ID D1b, DSCP61 Ressource assignment to D2 3, Session ID D2c, DSCP62 S1-SER1: Available Bandwidth for service 10, Ressource assignment to D1 2, Session ID D1c, DSCP69 SER1-C1: Available Bandwidth for service 100, Sum of Reservations 9, Session IDs D1a + D2a + D2b, DSCP4 SER1-C1: Available Bandwidth for service 100, Sum of Reservations 7, Session IDs D1b + D1c + D2c, DSCP4 C1-DER1: Available Bandwidth for service 100, Sum of Reservations 16, sum of all sessions, DSCP4 DER1-D1: Available Bandwidth for service 10, Sum of Reservations 8, Session IDs D1a + D1b + D1c, DSCP4 DER1-D2: Available Bandwidth for service 10, Sum of Reservations 8, Session IDs D2a + D2b + D2c, DSCP4 "Resource assignment to" is short for resource assignment for traffic from source x to destination y. Dedicated resources are assigned at the edge only. The edge routers remark all traffic to one and the same DSCP. Network internal nodes only monitor the consumption of their available resources for the service. They don't assign any resources to any specific edge to edge traffic. The destination IP address of the individual sessions must be made available to all nodes involved in admission control. It too must Geib Informative [Page 4] Throuhput Guarantees over DiffServ February 2003 be communicated by service related signaling signaling. It was ommitted for the sake of simplicity in the above example. The remainder of this document discusses different signaling architectures applicable to support such a service. 2. Signaling architecture The signaling architecture supporting this service must enable an exchange of information between carrier and origin customer network on one hand and within the carrier network on the other hand. The destination customer network should be involved in the communication too. The following general features must be supported by the signaling architecture: - Admission control along all carrrier network links passed by the traffic desiring a throughput guarantee. - Checking and assignment of DSCP availablity for the traffic flow. (If locally no active reservation to the same destination is existing.) - Configuration of resources at the origin edge router. - Maintenance of reservation state. - Marking a previously locally assigned DSCP as available once a reservation is released. - Removal of state in the orgin edge router once the reservation is released. - Removal of state from the admission control after release of a reservation. Note that only basic requirements are listed here. Accounting, involvement of the destination customer network and others are omitted in this version of the draft. Two carrier network signaling architectures may be used to provide the service specified above: on path signaling as designed by NSIS and so called off path signaling. The latter here is interpreted as centralised service management along the AS path only. The usefulness of both is briefly analysed in the following. The signaling messages and procedures themselves probably don't differ significantly between both signaling architectures. Compatibility therefore should be a minor issue. It is assumed that only edge routers assign per DSCP resources. Packets are remarked to a single and same DSCP once they enter the first intra-carrier network link. Intermediate nodes and the destination edge router only perform admission control based on the session identifier and the destination of this session. Geib Informative [Page 5] Throuhput Guarantees over DiffServ February 2003 2.1 On path signaling architecture In an on path signaling architecture, all carrier network elements passed by the traffic desiring a throughput guarantee must be involved in the signaling. The edge router assigns a DSCP and the resources available for this DSCP. Interior routers of the carrier network only need to control admission to the pre-provisioned per link resources. Still, they all must support the signaling protocol and maintain per link and session reservation state. Assuming the signaling protocol to be conforming with NSIS, the service is limited to the IP layer. If the carrier network is based on MPLS, admission control by intermediate MPLS switches is impossible. To ensure fast reaction on route changes, existing reservations must be frequently refreshed. 2.2 Off path signaling architecture Ideally, also the customer network supports off path signaling. Discovery of the network providers centralised service management system would be greatly simplified. The customer network management unit signaling for service would directly transmit this information to the centralised carrier service management system. No router or MPLS switch in the carrier network must support any new signaling mechanism. In a general case, the customer isn't aware of the signaling architecture of the carrier. The edge routers of the carrier network must at least identify the signaling packets, store their origing address and session ID and forward them to the centralised service management system. Further state maintenace is not required. Interior routers or MPLS switches still aren't involved into signaling. As mentioned above, MPLS switches aren't involved into signaling. Off path signaling enables interworking with MPLS domains. To perform per link admission control within the carrier domain, the carriers centralised service management system must be aware of the actual network topology and routing table. Therefore, it must be listening passively to route-announcements. It will adjust admission control decisions as soon as route changes occur. The refresh mechanism isn't required to track route changes. Refreshes therefore are required less frequently. The signaling processing is reduced significantly. 3. Security In general, security aspects and threats of NSIS and DiffServ apply. It may be worth noting that off path signaling requires discovery of peer signaling units prior to signaling for service while this isn't necessarily the case for on path signaling. Especially the first Geib Informative [Page 6] Throuhput Guarantees over DiffServ February 2003 message of a new client may provide no means of authentication in the on path case. Hence it may be more difficult to protect an on path signaling system from DoS attacks than an off path signaling system. Further, validation and administration of DSCPs at edge routers will require further attention. Compromising security must be prevented also if a carrier signaling system breaks or if the access link fails. A later issue of this draft will address the subject in more detail 4. Conclusions A lightweight architecture supporting point to point throughput guarantees across DiffServ networks was described. No changes in router DiffServ implementation are required. Scalability issues demand the service to be available on demand only. Further, the service is restricted to single DiffServ networks (ASes). A brief analysis comparing on path signaling for this service with off path signaling was made. In the off path case, no or only minimum signaling support is required by routers. Off path signaling enables interworking of IP and MPLS networks. While the off path approach currently isn't followed by the NSIS WG, the signaling protocol developed there should be applicable also in the off path signaling architecture described here. Author's Address Ruediger Geib T-Systems Nova Am Kavalleriesand 3 64295 Darmstadt Germany Email: Ruediger.Geib@t-systems.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Geib Informative [Page 7] Throuhput Guarantees over DiffServ February 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires: August 2003