Network Working Group P. Levis Internet-Draft M. Boucadair Expires: January 1, 2006 France Telecom June 30, 2005 The Meta-QoS-Class concept draft-levis-meta-qos-class-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 1, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a framework for inter-domain Quality of Service (QoS). It makes use of a new concept denoted by Meta-QoS- Class. This new concept guides and simplifies QoS agreements between providers and opens up new perspectives for a global QoS-enabled Internet. Levis & Boucadair Expires January 1, 2006 [Page 1] Internet-Draft The Meta-QoS-Class concept June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Binding l-QCs as a fundamental inter-domain QoS process . . 5 5. Provider to provider agreements analysis . . . . . . . . . . 5 5.1 About traps and glaciation . . . . . . . . . . . . . . . . 5 5.2 Recommendations for provider agreements . . . . . . . . . 6 5.3 Edge to edge guarantees . . . . . . . . . . . . . . . . . 7 5.4 The need for MQC . . . . . . . . . . . . . . . . . . . . . 7 6. The Meta QoS Class concept . . . . . . . . . . . . . . . . . 8 6.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2 Template . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3 Binding process . . . . . . . . . . . . . . . . . . . . . 8 6.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . 9 6.5 Common understanding . . . . . . . . . . . . . . . . . . . 10 7. New perspectives for a gobal QoS-enabled Internet . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1 Normative References . . . . . . . . . . . . . . . . . . 12 11.2 Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14 Levis & Boucadair Expires January 1, 2006 [Page 2] Internet-Draft The Meta-QoS-Class concept June 2005 1. Introduction Inter-domain Quality of Service (QoS) is seen as one of the future challenges for the Internet community [RFC3869]. At a first stage, most of the effort has been put into intra-domain specific problems. A number of issues still appear to need further elaboration [RFC2990], before it is conceivable to have an operational deployment of QoS services including inter-domain aspects. As pointed in [WIP], concepts should always be created in relation to specific problems. This memo focuses on inter-domain QoS and proposes some mechanisms to ease extending intra-domain QoS capabilities. It introduces a new concept denoted by Meta-QoS-Class (MQC). This concept is based on a very simple assumption: for two adjacent domains, each specifically engineered to convey traffic for a given application, the quality of the transportation across the two networks as a whole is likely to be satisfactory for the application, even if the two networks are managed by two different entities. Basically this is how the Plain Old Telephone Service (POTS) works. Finally, this memo explains how MQC could be used to promote a global QoS-enabled Internet. Note that this document doesn't specify any protocols or systems. 2. Terminology Service Provider An entity that provides Internet connectivity. Sometimes simply referred to as provider or SP. This document assumes that a provider owns and administers an IP network called a domain. Domain A network infrastructure composed of one or several Autonomous Systems. Local-QoS-Class (l-QC) A QoS transfer capability across a single domain, characterized by a set of QoS performance parameters denoted by (D, J, L). From a Diffserv [RFC2475] perspective, an l-QC is an occurrence of a Per Domain Behavior (PDB) [RFC3086]. It is then signalized by one or several Differentiated Services Code Point (DSCP)[RFC2474]. (D, J, L) D: one-way transit delay [RFC2679], J: one-way transit delay variation or jitter [RFC3393], and L: packet loss rate [RFC2680]. Levis & Boucadair Expires January 1, 2006 [Page 3] Internet-Draft The Meta-QoS-Class concept June 2005 Inter-domain QoS Refers to the level of network QoS guarantees for communications that span several domains. Service scope Network boundaries demarcating the guarantees of a service. 3. Assumptions This memo considers the Internet subset composed of all domains with Diffserv-like capabilities. These capabilities can differ from one provider to another by the number of deployed l-QCs, by their respective QoS characteristics, and also by the way they have been implemented and engineered. This memo does not put any specific requirements on the intra-domain traffic engineering policies and the way they are enforced. When crossing a domain, a traffic requesting a particular QoS treatment experiences conditions constrained by the values of the (D, J, L) tuple corresponding to the l-QC applied by the provider. A provider negotiates QoS agreements only with its BGP peers [RFC1771]. Potentially, all SPs that are directly accessible without the need to cross a third party domain (immediate neighbors). This is referenced as the cascaded model, see (Figure 1). The opposite approach is the centralized model, see (Figure 2), where agreements can be reached directly with any remote providers. /-Agreement-\/-Agreement-\/-Agreement-\ | || || | +--v-+ +-vv-+ +-vv-+ +-v--+ |SP +-------+SP +-------+SP |-------+SP | |4 | |3 | |2 | |1 | +--- + +----+ +----+ +----+ Figure 1: Cascaded model There is a great deal of complexity and scalability issues related to the centralized approach, which represents a radical shift from current Internet business model. Therefore, the only realistic way forward seems to be the cascaded approach. This is the approach adopted in the remainder of this document. Levis & Boucadair Expires January 1, 2006 [Page 4] Internet-Draft The Meta-QoS-Class concept June 2005 /---------------------------Agreement-\ /--------------Agreement-\ | /-Agreement-\ | | | | | | +--v-+ +-v--+ +-v--+ +-v--+ |SP +-------+SP +-------+SP |-------+SP | |4 | |3 | |2 | |1 | +--- + +----+ +----+ +----+ Figure 2: Centralized model 4. Binding l-QCs as a fundamental inter-domain QoS process Inter-domain QoS can be approached from many points of view. For providers it is a matter of extending their service scopes, beyond the boundaries of their own domains. They want to benefit from the Internet QoS infrastructure formed by all QoS-enabled domains. On a low level (with regard to protocol layering) extending the service scopes means extending the l-QCs. Packets leaving a domain that applied a given l-QC (signaled by a given DSCP if Diffserv is used), should experience similar treatment when crossing external domains up to their final destination. By definition, two l-QCs from two neighboring domains are bound together once the two providers have agreed to transfer traffic from one l-QC to the other. Binding l-QC appears as a fundamental process, it should ensure the consistency of inter-domain QoS treatments. A provider needs to find the best match between its deployed l-QCs and the neighbor's l-QCs. One potential difficulty is that providers are, in general, very reluctant to communicate on how their networks are engineered. They consider this kind of information as private and confidential. L-Qc binding should operate with minimal exchange of information. 5. Provider to provider agreements analysis 5.1 About traps and glaciation In order to identify relevant criteria to bind adjacent l-QCs, this section analyzes provider to provider agreements based on chains of domains. Provider SPn offers IP connectivity services to its customers that are part of its BGP neighbors. An IP connectivity service is a set of (Destination, D, J, L) where Destination is a group of IP Levis & Boucadair Expires January 1, 2006 [Page 5] Internet-Draft The Meta-QoS-Class concept June 2005 addresses reachable via SPn, and (D, J, L) is the QoS performance to get from SPn to Destination. SPn guarantees the level of QoS for the crossing of the whole chain of providers (SPn, SPn-1, SPn-2, ..., SP1) from its own domain to the domain where Destination is located, see (Figure 3). That means SPn implicitly guarantees the level of QoS for the crossing of distant domains like SPn-2. In the same way, SPn-2 is likely to be part of numerous SP chains and to see its level of QoS guaranteed by many providers it has maybe even never heard of. /-Agreement-\ SP SP Destination Customer Provider / +----+ +----+ +----+ +----+ +----+ |SP +-------+SP +----+SP +----+SP +- ... -+SP | |n+1 | |n | |n-1 | |n-2 | |1 | +----+ +----+ +----+ +----+ +----+ -----> packet flow <----------- Guarantee Scope -----------> Figure 3: Provider to provider agreement Any modification in a given agreement is likely to have an impact on numerous external agreements that make use of it. A provider sees the degree of freedom to renegotiate, or terminate, one of its own agreements, being restricted by the number of external (to its domain) agreements that depend on it. This is referenced as the SP chain trap issue. Within the scope of global Internet services, each provider would find itself being part of a large number of SP chains. This solution is not appropriate for a worldwide QoS coverage as it would lead to glaciation phenomena, ending up with a completely petrified QoS infrastructure, where nobody could renegotiate any agreement. If a QoS-enabled Internet is deemed desirable, with QoS services available potentially to and from any destination, as we are used to with the current Internet, any solution must resolve this problem and find alternate schemes for provider to provider agreements. 5.2 Recommendations for provider agreements These recommendations are based on two assumptions. First, to avoid forming SP chain traps, provider to provider agreements should not cover several domains. Second, since it is very hard to know about agreements more than one domain hop, and that these agreements can change, it is almost impossible to have an accurate visibility of their evolution. Levis & Boucadair Expires January 1, 2006 [Page 6] Internet-Draft The Meta-QoS-Class concept June 2005 Therefore, a provider should take the decision to bind one of its l-QCs to one of its neighbor l-QCs based exclusively on: - What it knows about its own l-QCs; - What it knows about its neighbor l-QCs. Agreements are then based on guarantees covering a single domain. For any n, SPn should guarantee SPn+1 only the crossing performance of SPn. 5.3 Edge to edge guarantees It is very important to note that the proposition to limit guarantees to only one domain hop applies exclusively to provider to provider agreements. It does not in any way preclude edge to edge guarantees for a user communication. <-------------Edge to Edge-------------> +----+ +----+ +----+ +----+ |SP +----+SP +----+SP |----+SP | (User A)--|4 | |3 | |2 | |1 |--(User B) +----+ +----+ +----+ +----+ <--PtoP--><--PtoP--><--PtoP--><--PtoP--> <-- -->: guarantee scope Figure 4: User communication guarantees Any QoS inter-domain solution, either based on MQC or on a completely different approach, is valid as long as each provider claiming to offer some QoS performance actually delivers the expected level of guarantee. In Figure 4, edge to edge guarantee between users A et B is ensured by concatenation of local provider to provider (PtoP) agreements. 5.4 The need for MQC For its binding process, a provider will not use any information related to what is happening more than one domain away. It will try to find the best match between its l-QCs and its neighbor l-QCs. That is to say, it will bind its l-QC with the neighbor l-QC that has the closest performance. However, at the scale of a communication, if there is systematically a slight difference between each upstream and downstream l-QC, there can be a significant difference between the first and the last l-QC. There must be a means to ensure the consistency and the coherency of a QoS treatment when traversing a given path. Levis & Boucadair Expires January 1, 2006 [Page 7] Internet-Draft The Meta-QoS-Class concept June 2005 A solution is to have a classification tool that defines two l-QCs as being able to be bound together if, and only if, they are classified in the same category. Each category is called a Meta-QoS-Class (MQC). Two l-QCs can be bound together if, and only if, they belong to the same MQC. 6. The Meta QoS Class concept 6.1 Definition An MQC can be loosely defined as a label associated with a set of applications that bear similar network QoS requirements. It can be put on any l-QC suited to convey packets from this type of applications. It is a means to certify that this l-QC is suitable for the traffic of this application. 6.2 Template The following attributes should be documented in any specification of an MQC. o A list of services (e.g. VoIP) the MQC is particularly suited for. o Boundaries for each QoS performance attribute (D, J, L), whenever required. Several levels can be specified depending on the size of the network provider (regional, national, etc.). o Constraints on traffic (e.g. only TCP-friendly). o Constraints on the ratio: network resources for the class to overall traffic using this class (e.g. less resource than peak traffic). 6.3 Binding process A provider goes through several steps to extend its internal l-QCs. First, it classifies its own l-QCs based on MQCs. Second, it learns about available MQCs advertised by its neighbors. To advertise an MQC, a provider must have at least one compliant l-QC and should be ready to reach agreements to let neighbor traffic benefits from it. Third, it contracts an agreement with its neighbor to send some traffic that will be handled accordingly to the agreed MQCs. The latter stage is the binding process. Note that when a provider contracts an agreement with a neighbor, it may well not know to what downstream l-QCs its own l-QCs are going to Levis & Boucadair Expires January 1, 2006 [Page 8] Internet-Draft The Meta-QoS-Class concept June 2005 be bound. It only knows that when it sends a packet requesting a given MQC treatment (for example, owing to an agreed DSCP marking) the packet will be handled in the downstream domain by an l-QC compliant with the treatment associated with this MQC. 6.4 Properties An MQC typically bears properties relevant to the crossing of one and only one domain. However this notion can be extended, in a straightforward manner, to the crossing of several domains, as long as the set of consecutive domains is considered as a single virtual domain. MQC should not be confused with PDB concept defined in Diffserv architecture. The two notions share the common characteristic of specifying some QoS performance values. But the two concepts differ in their purposes. The objective for the definition of a PDB is to help implementation of l-QCs within a single administrative network. The objective for an MQC is to help agreement negotiation between providers, and therefore the process of binding two adjacent l-QCs. The MQC concept is very flexible with regard to new unanticipated applications. According to the end-to-end principle [E2E], a new unanticipated application should have little impact on existing l-QCs, because the l-QCs should have been designed and engineered, to the extent possible, to gracefully allow any new application to benefit from the existing QoS infrastructure. However, this issue does not concern the MQCs as such, because an MQC is an abstract concept that has no physical existence. It is only the problem of l-QCs design and engineering. Therefore, a new unanticipated application could simply drive a new MQC and a new classification process for the l-QCs. A hierarchy of MQCs can be defined for a given type of service (e.g. VoIP with different qualities: VoIP for residential and VoIP for enterprise). A given l-QC can be suitable for several MQCs (even outside the same hierarchy). Several l-QCs in a given domain can be classified as belonging to the same MQC. MQC is a concept. MQC does not prohibit the use of any particular mechanism or protocol at the data, control, or management plane. For example, Diffserv, Intserv, traffic shaping, traffic engineering, admission control, and so forth, are completely legitimate. MQC simply drives and federates the way QoS inter-domain relationships are built. Levis & Boucadair Expires January 1, 2006 [Page 9] Internet-Draft The Meta-QoS-Class concept June 2005 6.5 Common understanding The need for standardization is strong as far as inter-domain QoS is concerned [RFC2990]. Each provider must have the same understanding of what a given MQC is about. A global agreement on a set of MQC standards is needed. The number of classes to be defined must remain very small to avoid an overwhelming complexity. There must be also a means to certify that the l-QC classification made by a provider conforms to the MQC standards. So the standardization effort should go along with some investigations on conformance testing requirements. 7. New perspectives for a gobal QoS-enabled Internet The MQC concept opens up new perspectives for a QoS enabled Internet that keeps, as much as possible, the openness characteristics of the existing best-effort Internet. This is certainly not the only domain of application to explore, but it is sufficiently important to deserve some special considerations. The resulting QoS Internet can be viewed as a set of parallel Internets or MQC planes. Each plane consists of all the l-QCs bound accordingly to the same MQC. When an l-QC maps to several MQCs, it potentially belongs to several planes. Users can select the MQC plane that is the closest to their needs, as long as there is a path available for the destination. The best effort service can be considered as relevant to the so- called best-effort MQC. It is of primary importance to maintain a best-effort route available when no QoS route is known. Best-effort delivery must survive QoS and must remain the main Internet transport service. When a provider contracts with another provider based on the use of MQCs, it simply adds a logical link to the corresponding MQC plane, basically like what current traditional inter-domain agreement means for the existing Internet. As soon as a new domain joins an MQC plane, it can reach all domains and networks within this plane. Figure 5 a) depicts the physical layout of a fraction of the Internet, comprising four domains with full-mesh connectivity. Levis & Boucadair Expires January 1, 2006 [Page 10] Internet-Draft The Meta-QoS-Class concept June 2005 +----+ +----+ +----+ +----+ |SP +----+SP | |SP +----+SP | |1 | |2 | |1 | |2 | +-+--+ +--+-+ +-+--+ +----+ | \ / | | / | \/ | | / | /\ | | / | / \ | | / +-+--+ +--+-+ +-+--+ +----+ |SP +----+SP | |SP | |SP | |4 | |3 | |4 | |3 | +----+ +----+ +----+ +----+ a) physical configuration b) an MQC plane Figure 5: MQC planes Figure 5 b) depicts how these four domains are involved in a given MQC plane. SP1, SP2 and SP4 have at least one compliant l-QC (SP3 maybe has or not) for this MQC. A bi-directional agreement exists between SP1 and SP2, SP1 and SP4, SP2 and SP4. Route path selection within a selected MQC plane can be envisaged as the traditional routing system used by the Internet routers: do your best to find one path, which is as good as possible. Thus, we can rely on a BGP-like protocol, for instance the proposal detailed in [q-BGP], for the inter-domain routing process. The resilience feature of the IP routing system is preserved: if a QoS path breaks somewhere, the routing protocol will make it possible to dynamically compute another QoS path if available, in the proper MQC plane. 8. IANA Considerations There are no IANA considerations. Note to RFC Editor: this section may be removed on publication as an RFC. 9. Security Considerations This document describes a framework and not protocols or systems. Potential risks and attacks will directly depend on the implementation technology. Solutions to implement this proposal must detail security issues in the relevant protocol documentation. Particular attention should be paid on giving access to MQC resources only to authorized traffic. Unauthorized access can lead to denial of service when the network resources get overused. Levis & Boucadair Expires January 1, 2006 [Page 11] Internet-Draft The Meta-QoS-Class concept June 2005 10. Acknowledgements Part of this work is funded by the European Commission, within the context of the MESCAL (Management of End-to-End Quality of Service Across the Internet At Large) project (http://www.mescal.org). The authors would like to thank all the other partners for the fruitful discussions. 11. References 11.1 Normative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 11.2 Informative References [E2E] Saltzer, J H., Reed, D P., and D D. Clark, "End-To-End Arguments in System Design", ACM Transactions in Computer Systems, Vol 2, Number 4, pp 277-288, November 1984. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000. [RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001. [RFC3869] Atkinson, R., Floyd, S., and Internet Architecture Board, Levis & Boucadair Expires January 1, 2006 [Page 12] Internet-Draft The Meta-QoS-Class concept June 2005 "IAB Concerns and Recommendations Regarding Internet Research and Evolution", RFC 3869, August 2004. [WIP] Deleuze, G. and F. Guattari, "What Is Philosophy?", Columbia University Press ISBN: 0231079893, April 1996. [q-BGP] Boucadair, M., "QoS-Enhanced Border Gateway Protocol", draft-boucadair-qos-bgp-spec-00.txt, Work in Progress, June 2005. Authors' Addresses Pierre Levis France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France Email: pierre.levis@francetelecom.com Mohamed Boucadair France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France Email: mohamed.boucadair@francetelecom.com Levis & Boucadair Expires January 1, 2006 [Page 13] Internet-Draft The Meta-QoS-Class concept June 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Levis & Boucadair Expires January 1, 2006 [Page 14]