Internet Draft TE Working Group Andreas Kirstaedter Internet Draft Siemens Expiration Date: January 2001 Achim Autenrieth Munich University of Technology July 2000 An Extended QoS Architecture Supporting Differentiated Resilience Requirements of IP Services <draft-kirstaedter-extqosarch-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 This document proposes an extension of the Quality of Service (QoS) architecture to support differentiated resilience requirements of IP services. Several architectures offering Quality of Service in IP-based networks are defined by the IETF community. The two most important of them are the Integrated Services (IntServ) model with the Resource Reservation Protocol (RSVP) as the recommended signaling protocol and the Differentiated Services (DiffServ) model. Recently, Multiprotocol Label Switching (MPLS) emerged introducing extended traffic engineering methods into IP and therefore also may support QoS. Due to the growing commercial importance of the Internet and the transport of mission-critical services, survivability became a main service requirement in addition to the traditional QoS. <draft-kirstaedter-extqosarch-00.txt> July 2000 The current QoS architectures, however, don't include the concept of network survivability so far. The extension presented in this document proposes an integrated approach to provide end-to-end QoS and resilience. Table of Contents 1.0 Introduction...................................................3 1.1 Overview .....................................................3 1.2 Motivation and Background ....................................3 2.0 Quality of Service and Network Survivability...................4 2.1 Quality of Service ...........................................5 2.2 Network Survivability ........................................5 3.0 Services and Applications......................................6 3.1 QoS and Resilience Requirements of IP Services ...............6 3.2 Service Examples .............................................6 3.2.1 High traditional QoS and high resilience .................7 3.2.2 High traditional QoS and low resilience ..................7 3.2.3 Low traditional QoS and high resilience ..................7 3.2.3 Low traditional QoS and low resilience ...................8 3.3 Extended QoS Definition ......................................8 4.0 Resilience Differentiated QoS Architecture.....................8 4.1 Basic concept ................................................8 4.2 Service classification .......................................9 4.3 Resource and Bandwidth Management ...........................10 4.4 Signaling ...................................................10 4.5 Packet Classification .......................................10 4.6 Packet Marking ..............................................10 4.7 Traffic conditioning ........................................11 4.8 Router Requirements .........................................11 5.0 Application to QoS Models.....................................11 5.1 Application to Integrated Services / RSVP ...................11 5.1.1 Extension to the Signaling Protocol .....................11 5.1.2 Setup of Flow ...........................................12 5.2 Differentiated Services .....................................12 5.2.1 Signaling of Resilience Requirements ....................12 5.2.2 DSCPs for Resilience PHB ................................12 5.2.3 Traffic Conditioning ....................................14 5.3 Provisioning of RD-QoS over multiple domains ................14 6.0 MPLS Support of RD-QoS........................................14 7.0 Conclusion....................................................15 8.0 Security Considerations.......................................15 9.0 References....................................................15 10.0 Authors' Addresses...........................................17 Kirstaedter, Autenrieth Expires: Jan. 2001 2 <draft-kirstaedter-extqosarch-00.txt> July 2000 1.0 Introduction 1.1 Overview This document presents an extension of the existing QoS architectures to support differentiated resilience requirements of IP services. After the motivation and the objective of this approach we postulate the generic requirements for survivable QoS services and present the basic concepts of the extended QoS architecture. Next, we discuss how the survivability requirements may be mapped to the IntServ and DiffServ architectures. Finally, the combination of the extended QoS architecture with MPLS is addressed. 1.2 Motivation and Background With the explosive growth of the Internet it became the most important international information infrastructure with a growing commercial importance. Mission-critical and high-priority traffic as well as real-time, connection-oriented services are now transported over the Internet. With QoS architectures firmly established, network survivability is becoming a key research issue in the Internet community. This resulted in several Internet drafts covering the resilience aspects of traffic engineering (e.g., [TE-FRMWRK], [TE-NW-SURV]) or proposing recovery strategies using MPLS (e.g. [MPLS-RCVRY-FRMWRK]). In [TE-FRMWRK] the network survivability is identified as a key requirement of traffic engineered networks. Several survivability options are defined and guidelines are given to support these requirements in MPLS-based networks. Recovery at the IP layer generally allows to differentiate between users / applications requiring services with a high level of survivability and those requiring only low-priority best-effort services that could tolerate an extended period of degraded quality of service. A resilience differentiated approach could protect only that traffic requiring a high level of service availability, which allows more cost-effective network design and traffic engineering. Moreover, intermediate L2 technologies like ATM or SONET will gradually disappear as the protocol layer stack is simplified to avoid having the same functionality present in multiple layers. From current discussions it seems most likely that the future physical transport network will be based on DWDM with a lightweight layer 2 protocol (like GbE/10GbE or Packet-over-SONET (POS)). However, it must be considered that these `lean' transport technologies often don't offer survivability mechanisms. Even if such mechanisms are present (e.g. DWDM ring protection), ISPs often may use unprotected links only (e.g., dark fiber) for economical reasons. Therefore it is reasonable for an ISP to provide the required network survivability using only resilience mechanisms in the IP layer. That way, also the network operation and management Kirstaedter, Autenrieth Expires: Jan. 2001 3 <draft-kirstaedter-extqosarch-00.txt> July 2000 complexity could be reduced, since all traffic engineering aspects (including resilience) are managed in the IP layer only. ISPs can offer unprotected and protected services (the latter at higher cost) with a single administrative platform, including user authentication and billing. This is a major advantage since it reduces the operational cost of the network and increases service flexibility. Depending on the amount of money a customer is willing to pay he receives a customized level of resilience. Customers who accept lower network resilience may be offered low-cost network services. Customers demanding high network resilience have to charge therefor. An open issue is, however, how to identify services with high resilience requirements involving fast recovery mechanisms. This leads to the problem how to establish a service with high end-to-end survivability. Existing QoS architectures so far don't allow the signaling of resilience requirements. In this document an extension of the currently discussed QoS architectures is proposed, which allows an integrated handling of QoS and resilience requirements. The objective of the proposed architecture is to extend the existing QoS architectures and QoS models to include the signaling of resilience requirements of IP services. 2.0 Quality of Service and Network Survivability The Internet was developed as a robust network with a good reachability of individual hosts and reliable services even with unreliable network elements (like routers or links). The only service quality offered was best effort. With the tremendous growth of the Internet, additional services with new requirements were developed. Real-time services like video- conferencing or IP telephony have a connection-oriented character and require high Quality of Service (QoS) with hard delay, delay jitter and bandwidth constraints. The Internet became an e-commerce platform with a fast growing commercial importance. Many companies use e-commerce for their business-to-business trade, others offer their services to the customers via Internet. A new kind of online companies emerged, which sell their products exclusively via the Internet. For these commercial customers the availability of the Internet access and the connectivity to the customers is critical for their business. Network outages result in direct loss of revenue and, moreover, loss of reputation. According to Forrester Research, the annual loss of a large e-commerce site in case of a best-effort availability of only 99% can be estimated to 3.7 million dollar [PASSMORE99]. Such e- commerce companies require a _non-stop_ Internet availability of up to 99.999%. Kirstaedter, Autenrieth Expires: Jan. 2001 4 <draft-kirstaedter-extqosarch-00.txt> July 2000 The following subsections briefly introduce the efforts of the IETF related to the provisioning of Quality of Service and Network Survivability. 2.1 Quality of Service To support the Quality of Service requirements of real-time, connection-oriented services, two QoS models were defined by the IETF: the Integrated Services (IntServ) architecture with RSVP as a reservation protocol, and the Differentiated Services (DiffServ) architecture. * In the IntServ model, the QoS requirements of the services are signaled on a per-flow basis through the network and the required network resources are reserved using RSVP. * The DiffServ model provides QoS to aggregated traffic on a per-hop basis. At the QoS domain boundary the traffic is classified into service classes, and the service classes are then conditioned at each router according to their negotiated service level requirements. Even though the reliability of a service is an important attribute of the service quality, no resilience attribute is currently defined for the QoS architectures. Network survivability is treated independently of the QoS architectures. 2.2 Network Survivability Network survivability refers to the ability of a network to maintain a determined level of service in the event of an expected set of failures such as link failures (e.g. fiber or cable cut) or node failures (e.g. line card failure, router power loss). Network resilience refers to the resources, protocols and processes present in the network to improve network survivability. In practice, both terms are often used with the same meaning. Several frameworks and proposals related to IP resilience are currently discussed in the IETF, mainly in the Traffic Engineering Working Group and the MPLS Working Group. It is generally possible to reach the survivability requirements of IP services with resilience mechanisms present at different protocol layers, e.g. SONET/SDH, ATM, WDM and MPLS [TE-NW-SURV]. Moreover, these resilience mechanisms may even be in operation in multiple layers at the same time. The key requirements of network survivability beside others are the time scale of the recovery operation, the resource efficiency, the recovery granularity and the QoS granularity [TE-NW-SURV]. While recovery at lower layers has advantages in the time scale of the recovery operation, recovery at higher layers generally allows a Kirstaedter, Autenrieth Expires: Jan. 2001 5 <draft-kirstaedter-extqosarch-00.txt> July 2000 better resource efficiency, recovery granularity and QoS granularity. For a detailed description of the generic network survivability objectives and resilience parameters see [TE-NW-SURV]. 3.0 Services and Applications 3.1 QoS and Resilience Requirements of IP Services A first approach to IP resilience could be to provide survivability mechanisms for services which require high QoS. However, some IP applications require high service availability but low traditional QoS. On the other hand, some QoS services may well tolerate low network resilience. The provisioning of an alternative and disjoint path for a certain service with resilience requirements results in additional management entries and/or an increased virtual load in the network if bandwidth has to be statically reserved on the alternative path. Thus resilience should only be provided if needed by the application. This requires a signaling method between the application and the network. At a closer look, it becomes obvious that resilience requirements of single applications are orthogonal to their _classical_ quality-of- service requirements (bandwidth, delay, delay jitter). In the following subsections the resilience and QoS requirements of some service examples are discussed. 3.2 Service Examples The following table illustrates the resilience and traditional QoS requirements of different services: +-----------------------------------------------+ | Service requires resilience | +-----------------------+-----------------------+ | yes | no | +-----------+-----+-----------------------+-----------------------+ | | | | | | | | mission-critical VoIP | standard VoIP and | | Service | yes | and multimedia | multimedia services | | requires | | services | | |traditional+-----+-----------------------+-----------------------+ | QoS | | database transactions,| | | | | mission-critical | e-mail, FTP, | | | no | control terminals, | standard WWW | | | |e-commerce applications| | +-----------+-----+-----------------------+-----------------------+ Kirstaedter, Autenrieth Expires: Jan. 2001 6 <draft-kirstaedter-extqosarch-00.txt> July 2000 The QoS and resilience requirements of selected services are discussed below. 3.2.1 High traditional QoS and high resilience * Mission critical voice-over-IP Sessions covering financial matters and discussions between business executives don't go along well with interruptions. They require both quality-of-service and resilience. Therefore, business customers won't base their voice communication infrastructure on IP networks without a service level agreement assuring a high service availability. * Mission critical multimedia communication Real-time multimedia services, e.g. a business video conference are severely affected even by short network outages. These application require both QoS and resilience. 3.2.2 High traditional QoS and low resilience * Standard VoIP and multimedia-over-IP applications Quality-of-service may be required depending on the user preferences but resilience might not be necessary as far as it goes along with additional cost and network failures are expected to have very low probabilities. The services can be defined as low-priority QoS traffic 3.2.3 Low traditional QoS and high resilience * Remote database transactions Delay jitter and bandwidth fluctuations are less critical for remote database transactions but the database is commonly locked during a transaction in order to avoid consistency problems. If due to a link or node failure the current transaction is interrupted other transactions will stay locked-out until a time-out occurs. Thus the number of possible transactions per time interval is reduced as will be the turnover in a commercial application. It has to be mentioned that any failure along the complete path between the database and the current customer will lead to this problem; it is not limited to failures on the access link to the network of the database host. * Critical control terminals Remote control terminals of mission critical processes are often connected to the controlled system over an IP network. The transported data has often low QoS requirements, but a service outage over an extended period of time may result in a breakdown of the process and possible safety problems. * E-commerce applications often require only the exchange of a few data packets with no QoS requirements at all. Service outages however directly result in loss of revenue and loss of reputation. E-commerce customers will therefore request network and service Kirstaedter, Autenrieth Expires: Jan. 2001 7 <draft-kirstaedter-extqosarch-00.txt> July 2000 availability guarantees from ISPs. This is especially true to a Web- based stock exchange access of private users. * Application Service Provisioning (ASPs) is an example for a business concept which relies on the flexible provisioning of services with high resilience and low traditional QoS 3.2.3 Low traditional QoS and low resilience The classical best-effort services like e-mail, FTP or WWW have no QoS or resilience requirements and tolerate service degradation. In case of failures such services may even be discarded to maintain the QoS and availability requirements of high-priority services. It must be noted that such low-priority traffic may be discarded even if it is not directly affected by the network failure, since the resources previously used for the low-priority traffic may be needed for the backup route of the high-priority. 3.3 Extended QoS Definition The observation of orthogonality of QoS and resilience brings us to the concept of postulating an extended quality-of-service: the combination of the commonly discussed quality-of-service in terms of bandwidth and delay together with the resilience requirements of the application. Thus the correct way for signaling the resilience requirements is to include the corresponding signaling into the quality-of-service signaling between the application and the network. Corresponding to the different quality-of-service approaches (IntServ, DiffServ) this could either be done on a per flow or on a per packet basis. This document proposes an architecture to support resilience requirements and QoS requirements of IP services in an integrated way. The extended QoS architecture that can differentiate the resilience requirements of IP services will be referred to as `Resilience Differentiated QoS' (RD-QoS) Architecture 4.0 Resilience Differentiated QoS Architecture In order to support the RD-QoS Architecture, the network must handle several key requirements and provide necessary functional components. In this section we first present the basic concept and then discuss the key requirements and components of the RD-QoS architecture in general. In the next section these functional components are mapped to the IntServ and DiffServ architectures. 4.1 Basic concept The RD-QoS architecture extends the existing QoS architectures to support differentiated resilience requirements of IP services. The Kirstaedter, Autenrieth Expires: Jan. 2001 8 <draft-kirstaedter-extqosarch-00.txt> July 2000 resilience requirements are included in the quality-of-service signaling between the application and the network. Packets belonging to a certain resilience class are accordingly marked at the network boundary. Additionally, the network must take care that the required QoS level can be maintained in case of a network failure with a minimum of service outage time. This requires a careful bandwidth and resource management which reserves enough spare resources to allow a service continuity for a given set of expected failures. The bandwidth management may either reserve dedicated resources on two physically disjoint paths through the network, or keep a shared pool of spare resources, which can be shared by multiple services in the event of failures. Under normal conditions (i.e. without any network failure present), traffic is handled by the QoS architecture according to the negotiated service level agreement without the RD-QoS extension. In the event of a failure however, the traffic conditioning takes the resilience requirement of the service class into consideration. Packets of low-priority services with no resilience requirements may be discarded while services with negotiated resilience requirements may be remarked and their queuing and dropping preferences modified. 4.2 Service classification The packets are classified according to their resilience requirements in addition to the common QoS parameters. Depending of the level of resilience required, several resilience classes are possible. A possible set of resilience classes is given below. o High resilience requirements Resources should be exclusively reserved on an alternative path. For a 1+1 protection, packets are forwarded on both the working and the alternative path simultaneously. In case of a failure on the working path, the downstream side simply selects packets from the alternative path. In case of 1:1 protection the packets are forwarded on the alternative path only in case of a failure. This requires a recovery signaling to handle uni-directional failures. o Medium resilience requirements Spare resources may be shared between multiple flows. The bandwidth management has to assure that enough spare resources are available for a given set of expected failures. In case of a network failure , packets are forwarded after a rerouting and reservation of spare resources. o Low resilience requirement No resources are reserved in advance (neither exclusively nor shared). In case of a failure, packets may be forwarded after a rerouting and reservation phase, if enough resources are available. Kirstaedter, Autenrieth Expires: Jan. 2001 9 <draft-kirstaedter-extqosarch-00.txt> July 2000 o No resilience requirements In case of a network failure in the administrative domain, packets may be discarded/dropped (even if the traffic is not directly affected by the network failure but rather by a re-routing of other traffic having high resilience requirements). 4.3 Resource and Bandwidth Management To support QoS, the available resources of the nodes of a QoS domain are allocated to certain flows or traffic aggregates. For the RD-QoS architecture a second set of resource allocation metrics must be provided. This second set reassigns the available resources according to the negotiated resilience requirements of the services in addition to their classical QoS metrics. If a new service is established (by a Service Level Agreement) or a new flow is set up (by the Admission Control), the Resource Management must assure that enough spare resources are available in the network to maintain the negotiated QoS level in case of a network failure. One possible solution is to reserve the required resources on two physically disjoint paths. A second possibility is to calculate the overall required network resources for all failure scenarios in an expected set of failures. If the resource requirements can be met by the network, the new service can be established. 4.4 Signaling Depending on the QoS architecture used, the signaling may be along a full end-to-end route or from the application to the network boundary. In either case the signaling includes a resilience attribute identifying the resilience requirements of the service. 4.5 Packet Classification To be able to enforce a specific QoS policy, packets must be classified into a specific flow or service class. The packets classification in the RD-QoS architectures is only extended in the way that additional services with resilience requirements are to be identified. 4.6 Packet Marking Packets belonging to a specific resilience flow or service class will be marked accordingly. Depending on the QoS architecture the marking may be done using the flow label or the IP TOS-byte. Kirstaedter, Autenrieth Expires: Jan. 2001 10 <draft-kirstaedter-extqosarch-00.txt> July 2000 In the event of a network failure, packets belonging to a specific resilience class may be remarked to assure correct forwarding by routers which didn't detect the network failure or which don't support RD-QoS. 4.7 Traffic conditioning In the event of a failure, the traffic conditioning takes the resilience requirement of the service class into consideration. Packets with no resilience requirements may be dropped to free network resources for services with resilience requirements. This includes also packets of services which were not directly affected by the network failure. Depending on the negotiated level or resilience, packets may be remarked, and their scheduling and drop precedence redefined. 4.8 Router Requirements An additional requirement for a router supporting the RD-QoS architecture is the ability to detect network failures such as link and node failures. The failure detection should be fast and reliable. Different options for the failure detection are possible (e.g. [FLIP]), but are out of scope of this document. 5.0 Application to QoS Models The proposed way for signaling the resilience requirements of IP services is to include the corresponding signaling into the quality- of-service signaling between the application and the network. Corresponding to the different quality-of-service approaches (IntServ, DiffServ) this could either be done on a per flow or on a per packet basis. 5.1 Application to Integrated Services / RSVP In the IntServ architecture [RFC1633] resources are reserved by the RSVP [RFC2205] for every QoS flow on every router along a path from sender to receiver. In the RD-QoS architecture, the signaling is extended to reserve spare resources in the network to provide survivability against network failures. 5.1.1 Extension to the Signaling Protocol The RSVP message formats are extended in the sense that the end user's terminal is able to signal a resilience requirement to the network in addition to the bandwidth requirement. The proposed way to do this is to include the resilience requirement in the Rspec [RFC2210] of RSVP. The three IntServ classes _ Guaranteed, Controlled Load and Best-Effort _ are combined with resilience classes. Kirstaedter, Autenrieth Expires: Jan. 2001 11 <draft-kirstaedter-extqosarch-00.txt> July 2000 5.1.2 Setup of Flow When a RD-QoS flow is set up, the network (additionally) reserves an alternative and disjoint explicit route for the flow with resilience requirements. In case of a link or node failure, the network switches the flow to the alternative route. Note: If no purely QoS-oriented RSVP path had been identified in advance the network has to consider the path the packets would take under non-failure circumstances before the disjoint path can be identified. This could be achieved by observing the flow of RSVP messages. 5.2 Differentiated Services The Differentiated Services (DS) architecture [RFC2475] realizes IP QoS by the prioritization of different services on a hop-by-hop basis. Packets are classified and conditioned at the network boundary and assigned to a behavior aggregate. The behavior aggregate is identified by bit-patterns in the DS field, so called DS codepoints (DSCP). The DS-Field is located in the IPv4 TOS octet or IPpv6 Traffic Class octet. A specific DSCP selects a corresponding Per-Hop-Behavior (PHB) for the packet. An Expedited Forwarding (EF) PHB [RFC2598] as well as a group of Assured Forwarding (AF) PHBs [RFC2597] are already defined in RFCs with corresponding codepoints. The possible DSCPs are defined in [RFC2474]. In the following subsections only those aspects of the DiffServ architecture are discussed, which are affected by the RD-QoS Architecture. 5.2.1 Signaling of Resilience Requirements The Network Management or a special resource control establishes a set of pre-defined routes in advance using QoS routing. In addition, the corresponding bandwidth is reserved according to the estimated or negotiated (by service level agreements) amount of traffic having resilience requirements. The packets with resilience requirements then are marked either by the application or the edge device when they enter the DiffServ network. In the case of a failure of either a link or a network element the network then only switches those packets to an alternative path that have the resilience bit combination set in their headers. 5.2.2 DSCPs for Resilience PHB The marking of the packets is done using DSCP values. Several different options are possible for the definition of the DSCP: * Use of DSCP-Bit 5 as a Resilience Identifier Kirstaedter, Autenrieth Expires: Jan. 2001 12 <draft-kirstaedter-extqosarch-00.txt> July 2000 The DSCP-Bit 5 distinguishes, whether a codepoint belongs to Pool 1 (Standards Actions) or to either Pool 2 or 3 (experimental or local use) [RFC2474]. The DSCP Bit 5 could be used as a resilience marker to distinguish between services with negotiated resilience guarantees and services without. Codepoint Space Traffic Conditioning --------------- ------------------------------ xxxxx0 without resilience constraints xxxxx1 with resilience constraints The advantage of this option is that no specific bit-patterns are used to define resilience requirements. A single bit distinguishes between services requiring resilience and those without resilience requirements. Additionally, DSCPs for resilience are only located within experimental or local use pool. This allows a correct traffic conditioning of the service classes in domains not supporting resilience differentiation. This is the recommended method to define Resilience PHB. * Resilience PHB for existing behavior aggregate definitions A second option is to define resilience DSCP and resilience PHBs for already defined behavior aggregates. So far, 14 PHBs are defined: the EF PHB, the AF PHB with 4 traffic priority classes with 3 drop preferences each, and a Default PHB. For these 14 defined PHBs, resilience PHBs could be defined with specific codepoints. These codepoints could be taken from the pool of recommended codepoints or from experimental and local use codepoints. The Resilience PHBs have the same traffic conditioning characteristics as their corresponding standardized PHBs, but define additionally the traffic conditioning characteristics in case of network failures. * Special PHBs for resilience behavior aggregates It is also possible to define specific PHBs for behavior aggregates (BA) requiring resilience. These BAs are independent from and parallel to other behavior aggregates. Such resilience PHBs may be defined locally in DiffServ domains. Therefore, the DSCP for these BA should be taken from the pool 2 or pool 3. This approach allows the highest flexibility, since no resilience PHBs must be standardized. It allows individual ISP to offer resilience guarantees to their customers independent of neighboring domains. The drawback of this approach is that end-to-end resilience over multiple domains is very difficult to achieve. For this objective, universally defined resilience PHBs are preferable. Kirstaedter, Autenrieth Expires: Jan. 2001 13 <draft-kirstaedter-extqosarch-00.txt> July 2000 5.2.3 Traffic Conditioning In case of link or node failures, the traffic conditioner considers flows for which no resilience requirements were signaled to be out- of-profile. These flows are either directly dropped at the boundary router, or they are assigned a very low drop precedence. For flows with resilience requirements the required spare resources were reserved in advance. This maintains the same level of service quality in the presence network failures. Depending on the required level of resilience, the packets may be remarked and the traffic profile modified. This influence the way the traffic is shaped and when packets are dropped. 5.3 Provisioning of RD-QoS over multiple domains One objective of the RD-QoS architecture is the end-to-end provisioning of resilient services over multiple domains. For this aim, a mapping between resilience classes of different domains is needed. If both domains use the same underlying QoS architecture (e.g., DiffServ), the mapping is simple for standard resilience classes with well defined characteristics. If both domains use different resilience classes and / or different QoS architectures, the mapping of resilience classes requires careful planning. A detailed investigation of the provisioning of RD-QoS over multiple administrative domains is currently under investigation. 6.0 MPLS Support of RD-QoS With Multi-Protocol Label Switching (MPLS) [MPLS-ARCH] a Label Switched Path (LSP) is established be edge routers using MPLS signaling protocols. Since MPLS is path-oriented and allows a explicit route definition, various recovery mechanisms are possible increasing the network survivability [MPLS-RCVRY-FRMWRK]. The combination of MPLS and DiffServ [MPLS-DIFF] or RSVP [RSVP-MPLS-TE] with the RD-QoS extension allows the provisioning of end-to-end QoS and resilience over multiple administrative domains. The extended quality-of-service definition including resilience attributes allows the mapping of RD-QoS classes to MPLS LSPs with different protection levels according to the resilience requirements. In case of RD-QoS with DiffServ for example, the BA of services with resilience requirements can be assigned to a LSP with a defined protection path. A detailed mapping of RD-QoS classes to MPLS recovery schemes is currently under investigation. Kirstaedter, Autenrieth Expires: Jan. 2001 14 <draft-kirstaedter-extqosarch-00.txt> July 2000 7.0 Conclusion This document proposed the extension of the Quality of Service definition to include survivability options. It presented the motivations for this extension and defined its objectives. The basic concept and functional components were defined. The application of the extended QoS definition to IntServ/RSVP, DiffServ and MPLS was described. 8.0 Security Considerations This document does not introduce new security issues. 9.0 References [TE-FRMWRK] Daniel Awduche, Angela Chiu, Anwar Elwalid, Indra Widjaja, Xipeng Xiao, "A Framework for Internet Traffic Engineering", Work in Progress, Internet Draft, <draft-ietf-tewg-framework-01.txt>, May 2000. [TE-NW-SURV] K. Owens, M. Oommen, "Network Survivability Considerations for Traffic Engineered IP Networks", Work in Progress, Internet Draft, <draft-owens-te-network-survivability-00.txt>, March 2000. [MPLS-RCVRY-FRMWRK] V. Makam, V. Sharma, K. Owens, C. Huang, et al, "A Framework for MPLS-based Recovery", Work in Progress, Internet Draft, <draft-makam-mpls-recovery-frmwrk-00.txt>, March 2000. [RFC1633] R. Braden, D. Clark and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2205] R. Braden (Ed.), L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 FunctionalSpecification", RFC 2205, September 1997. [RFC2210] J. Wroclawski, "The Use of RSVP with Integrated Services", RFC 2210, September 1997. [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. Kirstaedter, Autenrieth Expires: Jan. 2001 15 <draft-kirstaedter-extqosarch-00.txt> July 2000 [RFC2475] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC2598] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. [LABOVITZ99] C. Labovitz, A. Ahuja, F. Jahanian, "Experimental Study of Internet Stability and Wided-Area Backbone Failures", Proceedings of the Twenty-Ninth Annual International Symposium on Fault-Tolerant Computing, June 1999 [PASSMORE99] David Passmore, "Scaling Large E-Commerce Infrastructures ", Packet Magazine Archives, Cisco Systems, 3rd Quarter 1999. (http://www.cisco.com/warp/public/784/packet/july99/1.html) [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999 [MPLS-ARCH] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label Switching Architecture", Work in Progress, Internet Draft, <draft-ietf-mpls-arch-06.txt>, August 1999. [MPLS-DIFF] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated Services", Work in Progress, Internet Draft, <draft-ietf-mpls-diff-ext-06.txt>, July 2000. [RSVP-MPLS-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Work in Progress, Internet Draft, <draft-ietf-mpls-rsvp-lsp-tunnel-06.txt>, July 2000 [FLIP] H.Sandick, M.Squire, B.Cain, I. Duncan, B.Haberman, "Fast LIveness Protocol (FLIP)", Work in Progress, Internet Draft,, February 2000 Kirstaedter, Autenrieth Expires: Jan. 2001 16 <draft-kirstaedter-extqosarch-00.txt> July 2000 10.0 Authors' Addresses Andreas Kirstaedter Siemens AG Otto-Hahn-Ring 6 81730 Munich, Germany Phone: +49 89 636 47484 Email: andreas.kirstaedter@mchp.siemens.de Achim Autenrieth Munich University of Technology Arcisstr. 21 80290 Munich, Germany Phone: +49 89 289 23504 Email: autenrieth@ei.tum.de Kirstaedter, Autenrieth Expires: Jan. 2001 17