Network Working Group P. Levis Internet-Draft M. Boucadair Intended status: Informational France Telecom Expires: August 23, 2007 February 19, 2007 Considerations of provider-to-provider agreements for Internet-scale QoS draft-levis-provider-qos-agreement-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 August 23, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo analyzes provider-to-provider QoS agreements suited for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It introduces a new concept denoted by Meta-QoS-Class. This new concept drives and federates the way QoS inter-domain relationships are built. It opens up new perspectives for a QoS-enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. Levis & Boucadair Expires August 23, 2007 [Page 1] Internet-Draft MQC and provider QoS agreements February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Weaknesses of provider-to-provider QoS agreements based on SP chains . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. IP connectivity services . . . . . . . . . . . . . . . . . 5 3.2. Similarity between provider and customer agreements . . . 6 3.3. Liability for service disruption . . . . . . . . . . . . . 6 3.4. SP chain trap leading to glaciation . . . . . . . . . . . 7 4. Provider-to-provider agreements based on Meta-QoS-Class . . . 7 4.1. Single domain covering . . . . . . . . . . . . . . . . . . 7 4.2. Binding l-QCs . . . . . . . . . . . . . . . . . . . . . . 8 4.3. MQC-based Binding process . . . . . . . . . . . . . . . . 10 5. The Internet as MQC planes . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Levis & Boucadair Expires August 23, 2007 [Page 2] Internet-Draft MQC and provider QoS agreements February 2007 1. Introduction Three different areas can be distinguished in IP QoS service offerings. The first area is the single domain where a provider delivers QoS services inside the boundaries of its own network. The second area is multi domains where a small set of providers, with mutual business interests, cooperate to deliver QoS services inside the boundaries of their network aggregate. The third area, which has very seldom been put forward, is the Internet where QoS services can be delivered from almost any source to any destination. Both multi domains and Internet areas deal with inter-domain aspects. However they differ greatly in many ways, such as the number of domains and QoS paths involved, which are much higher and dynamic for the Internet area. Multi domains and Internet areas are therefore likely to differ in their respective solutions. Most of the work on QoS implementation as well as standardization and research, has gone into the single domain area. A number of issues still appear to need further elaboration [RFC2990], before we could have operational deployment of QoS services that include inter-domain aspects. This memo deals only with QoS solutions globally suited for the Internet. Any Internet-wide solutions should apply locally in order to be usable as soon as deployed in a small set of domains. Any Internet-wide solutions should be scalable in order to allow a global deployment to almost all Internet domains, with the ability to establish QoS communications between any two end-users. Any Internet-wide solutions should also maintain a best-effort service that should remain the pre-eminent service as a consequence of the end-to-end argument [E2E]. If there is no path available within the requested QoS to reach a destination, this destination must remain reachable through the best-effort service. This memo does not place any specific requirements on the intra- domain traffic engineering policies and the way they are enforced. A provider may deploy any technique to ensure QoS inside its network. This memo assumes only that QoS capabilities inside a provider's network can be represented as local-QoS-Classes (l-QCs). When crossing a domain, traffic experiences conditions characterized by the values of delay, jitter, and packet loss rate that correspond to the l-QC selected for that traffic within that domain. 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 analyzes provider-to-provider QoS agreements. To avoid a great deal of complexity and scalability issues we assume these Levis & Boucadair Expires August 23, 2007 [Page 3] Internet-Draft MQC and provider QoS agreements February 2007 agreements are negotiated only between two adjacent domains that are directly accessible to each other (immediate neighbors). We also assume, because they exchange traffic, that these neighbors are BGP [RFC4271] peers. This memo defines terminology relevant to inter-domain QoS models and introduces a new concept denoted by Meta-QoS-Class(MQC) that drives and federates the way QoS inter-domain relationships are built. The rationale for the MQC concept relies on a universal and common understanding of QoS-sensitive application needs. Wherever end-users are connected, they experience the same QoS difficulties and are likely to express very similar QoS requirements to their respective providers. Globally confronted with the same customer requirements, providers are likely to design and operate similar network capabilities. Note that this document does not specify any protocols or systems. 2. Terminology (D, J, L) D: one-way transit delay [RFC2679], J: one-way transit delay variation or jitter [RFC3393], and L: packet loss rate [RFC2680]. Domain A network infrastructure composed of one or several Autonomous Systems (AS) managed by a single administrative entity. IP connectivity service IP transfer capability characterized by a (Destination, D, J, L) tuple where Destination is a group of IP addresses and (D, J, L) is the QoS performance to get to Destination. 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]. L-QC binding 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. Levis & Boucadair Expires August 23, 2007 [Page 4] Internet-Draft MQC and provider QoS agreements February 2007 L-QC thread Chain of neighboring bound l-QCs. Meta-QoS-Class (MQC) An MQC provides the boundaries of the QoS parameters values, two l-QCs must respect in order to be bound together. An MQC is used as a label that certifies the support of a set of applications that bear similar network QoS requirements. Service Provider (SP) An entity that provides Internet connectivity. This document assumes that an SP owns and administers an IP network called a domain. Sometimes simply referred to as provider. SP chain The chain of Service Providers whose domains are used to convey packets for a given IP connectivity service. 3. Weaknesses of provider-to-provider QoS agreements based on SP chains This section analyzes provider-to-provider QoS agreements based on guarantees that span several domains. In this approach the basic service element that a provider offers to its neighboring providers is called an IP connectivity service. It uses the notion of SP chains. We first define what an IP connectivity service is, and then we point out several weaknesses of such an approach, especially the SP chain trap problem that leads to the so-called Internet glaciation era. 3.1. IP connectivity services An IP connectivity service is a (Destination, D, J, L) tuple where Destination is a group of IP addresses reachable from the domain of the provider offering the service, and (D, J, L) is the QoS performance to get from this domain to Destination. Destination is typically located in a remote domain. Levis & Boucadair Expires August 23, 2007 [Page 5] Internet-Draft MQC and provider QoS agreements February 2007 Provider- /--------------SP chain---------------\ oriented view /--Agreement--\ +----+ +----+ +----+ +----+ +----+ |SP +-------+SP +----+SP +----+SP +- ... -+SP | |n+1 | |n | |n-1 | |n-2 | |1 | +----+ +----+ +----+ +----+ +----+ Domain- -----> packet flow / oriented Destination view <----------- Guarantee Scope ---------> Figure 1: IP connectivity service In Figure 1 Provider SPn guarantees provider SPn+1 the level of QoS for crossing the whole chain of providers' domains (SPn, SPn-1, SPn-2, ...,SP1). SPi denotes a provider as well as its domain. The top of the figure is the provider-oriented view, the ordered set of providers (SPn, SPn-1, SPn-2, ...,SP1) is called an SP chain. The bottom of the figure is the domain-oriented view. 3.2. Similarity between provider and customer agreements This approach maps end-users' needs directly to provider-to-provider agreements. Providers negotiate agreements to a destination because they know customers are ready to pay for QoS guaranteed transfer to this destination. As far as service scope is concerned, the agreements between providers will resemble the agreements between customers and providers. For instance, in Figure 1, SPn can sell to its own customers the same IP connectivity service it sells to SPn+1. There is no clear distinction between provider-to-provider agreements and customer-to-provider agreements. In order to guarantee a stable service, redundant SP chains should be formed to reach the same destination. When one SP chain becomes unavailable, an alternate SP chain should be selected. In the context of a global QoS Internet that would lead to an enormous number of SP chains along with the associated agreements. 3.3. Liability for service disruption In Figure 1, if SPn+1 sees a disruption in the IP connectivity service, it can turn only against SPn, its legal partner in the agreement. If SPn is not responsible, in the same way, it can only complain to SPn-1, and so on, until the faulty provider is found and eventually requested to pay for the service impairment. The claim is then supposed to move back along the chain until SPn pays SPn+1. The SP chain becomes a liability chain. Levis & Boucadair Expires August 23, 2007 [Page 6] Internet-Draft MQC and provider QoS agreements February 2007 Unfortunately this process is prone to failure in many cases. In the context of QoS solutions suited for the Internet, SP chains are likely to be dynamic and involve a significant number of providers. Providers (that do not all know each other) involved in a same SP chain can be competitors in many fields; therefore, trust relationships are very difficult to build. Many complex and critical issues need to be resolved: How will SPn+1 prove to SPn that QoS level is not the level expected for a scope that can expand well beyond SPn? How long will it take to find the guilty domain? Is SPn ready to pay SPn+1 for something it does not control and is not responsible for? 3.4. SP chain trap leading to glaciation In Figure 1, SPn implicitly guarantees SPn+1 the level of QoS for the crossing of distant domains like SPn-2. As we saw in Section 3.2, SP chains will proliferate. A provider is, in this context, likely to be part of numerous SP chains. It will see the level of QoS it provides guaranteed by many providers it has maybe even never heard of. Any change 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 large number of external (to its domain) agreements that depend on it. This is what is referred to as the "SP chain trap" issue. This solution is not appropriate for worldwide QoS coverage as it would lead to glaciation phenomena, causing a completely petrified QoS infrastructure, where nobody could renegotiate any agreement. 4. Provider-to-provider agreements based on Meta-QoS-Class If a QoS-enabled Internet is deemed desirable, with QoS services available potentially to and from any destination, any solution must resolve the above weaknesses and scalability problems, and find alternate schemes for provider-to-provider agreements. 4.1. Single domain covering Due to the vulnerabilities of the SP chain approach we assume provider-to-provider QoS agreements should be based on guarantees covering a single domain. A provider guarantees its neighbors only the crossing performance of its own domain. In Figure 2, the provider SPn guarantees the provider SPn+1 only the QoS performance of the SPn domain. The remainder of this document will show that this approach, bringing clarity and simplicity into inter-domain Levis & Boucadair Expires August 23, 2007 [Page 7] Internet-Draft MQC and provider QoS agreements February 2007 relationships, is better suited for a global QoS Internet than that based on SP chains. Provider- oriented view /--Agreement--\ +----+ +----+ |SP +-------+SP + |n+1 | |n | +----+ +----+ Domain- -----> packet flow oriented <----> view Guarantee Scope Figure 2: provider-to-provider QoS agreement 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 end-to-end guarantees for communications. There is a clear distinction between provider-to-provider and customer-to-provider QoS agreements. We expect a great deal of difference in dynamicity between the two. Most provider-to-provider agreements should have been negotiated, and should remain stable, before end-users can dynamically request end-to-end guarantees. The number of provider agreements is largely independent of the number of end-user requests and does not increase dramatically as with SP chains. The simple fact that SP chains do not exist makes the AS chain trap problem and the associated glaciation threat vanish. The liability issue is restricted to a one hop distance. A provider is responsible for its own domain only, and is controlled only by all the neighbors with whom it has a direct contract. 4.2. Binding l-QCs When a provider wants to contract with another provider, the main concern is to decide which l-QC(s) in its own domain it will bind to which l-QC(s) in the neighboring downstream domain. The l-QC Binding process becomes the basic inter-domain process. Levis & Boucadair Expires August 23, 2007 [Page 8] Internet-Draft MQC and provider QoS agreements February 2007 Upstream Downstream domain domain l-QC21 -----> l-QC11 l-QC22 -----> l-QC12 l-QC23 -----> l-QC13 l-QC24 -----> Figure 3: l-QC Binding If one l-QC was to be bound to two (or more) l-QCs it would be very difficult for packets to know whether they should jump to one l-QC or the other. This could imply a flow classification at the border of the domains based on granularity as fine as the application flows. For the sake of scalability we assume one l-QC should not be bound to several l-QCs [LEV]. On the contrary, several l-QCs can be bound to the same l-QC, in the way that l-QC23 and l-QC24 are bound to l-QC13 in Figure 3. A provider decides the best match between l-QCs based exclusively on: - What it knows about its own l-QCs; - What it knows about its neighboring l-QCs. It does not use any information related to what is happening more than one domain away. Despite this one hop, short-sighted approach, the consistency and the coherency of the QoS treatment must be ensured on an l-QC thread formed by neighboring bound l-QCs. Packets leaving a domain that applies a given l-QC, should experience similar treatment when crossing external domains up to their final destination. A provider should bind its l-QC with the neighboring l-QC that has the closest performance. The criteria for l-QC binding should be stable along any l-QC thread. For example, two providers should not bind two l-QCs for minimizing the delay whereas further on, on the same thread, two other providers have bound two l-QCs for minimizing errors. Constraints should be put on l-QC QoS performance parameters to confine their values to an acceptable and expected level on an l-QC thread scale. These constraints should depend on domain size, for example restrictions on delay should authorize a bigger value for a national domain than for a regional one. Some rules must therefore be defined to establish in which conditions two l-QCs can be bound Levis & Boucadair Expires August 23, 2007 [Page 9] Internet-Draft MQC and provider QoS agreements February 2007 together. These rules are provided by the notion of Meta-QoS-Class (MQC). 4.3. MQC-based Binding process An MQC provides the limits of the QoS parameters two l-QCs must respect in order to be bound together. A provider goes through several steps to extend its internal l-QCs through the binding process. Firstly, it classifies its own l-QCs based on MQCs. An MQC is used as a label that certifies the support of a set of applications that bear similar network QoS requirements. It is a means to make sure that an l-QC has the appropriate QoS characteristics to convey the traffic of this set of applications. Secondly, 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 benefit from it. Thirdly, it contracts an agreement with its neighbor to send some traffic that will be handled according to the agreed MQCs. The following attributes should be documented in any specification of an MQC. This is not a closed list, other points can be added if needed. o A set of applications (e.g. VoIP) the MQC is particularly suited for. o Boundaries or intervals for each QoS performance attribute (D, J, L), whenever required. An MQC can be focused on a single parameter (e.g. low delay). Several levels can be specified depending on the size of the network provider, for instance a small domain (e.g. regional) needs lower delay than a large domain (e.g. national) to match a given MQC. o Constraints on traffic (e.g. only TCP-friendly). o Constraints on the ratio: network resources for the class / overall traffic using this class (e.g. less resources than peak traffic). Two l-QCs can be bound together if, and only if, they conform to the same MQC. 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 business). A given l-QC can be suitable for several MQCs (even outside the same hierarchy). Several l-QCs in the same domain can be classified as belonging to the same MQC. There is an MQC with no Levis & Boucadair Expires August 23, 2007 [Page 10] Internet-Draft MQC and provider QoS agreements February 2007 specific constraints called the best-effort MQC. The need for standardization is great in respect of inter-domain QoS agreements [RFC3387]. Each provider must have the same understanding of what a given MQC is about. We need a global agreement on a set of MQC standards. The number of classes to be defined must remain very small to avoid overwhelming complexity. We also need a means to certify that the l-QC classification made by a provider conforms to the MQC standards. So the standardization effort should be accompanied by investigations on conformance testing requirements. 5. The Internet as MQC planes 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 according to the same MQC. An MQC plane can have holes and isolated domains because QoS capabilities do not cover all Internet domains. When an l-QC maps to several MQCs, it belongs potentially to several planes. When a provider contracts with another provider based on the use of MQCs, it simply adds a logical link to the corresponding MQC plane. This is basically what current traditional inter-domain agreements mean for the existing Internet. Figure 4a) depicts the physical layout of a fraction of the Internet, comprising four domains with full-mesh connectivity. +----+ +----+ +----+ +----+ |SP +----+SP | |SP +----+SP | |1 | |2 | |1 | |2 | +-+--+ +--+-+ +-+--+ +----+ | \ / | | / | \/ | | / | /\ | | / | / \ | | / +-+--+ +--+-+ +-+--+ +----+ |SP +----+SP | |SP | |SP | |4 | |3 | |4 | |3 | +----+ +----+ +----+ +----+ a) physical configuration b) an MQC plane Figure 4: MQC planes Figure 4 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. Levis & Boucadair Expires August 23, 2007 [Page 11] Internet-Draft MQC and provider QoS agreements February 2007 For a global QoS-based Internet, this solution will work only if MQC- based binding is largely accepted and becomes a current practice. This limitation is due to the nature of the service itself, and not to the use of MQCs. Insofar as we target global services we are bound to provide QoS in as many SP domains as possible. However, any MQC-enabled part of the Internet that forms a connected graph can be used for QoS communications, and be extended. Therefore, incremental deployment is possible, and leads to incremental benefits. For example, in Figure 4 right-hand plane, as soon as SP3 connects to the MQC plane it will be able to benefit from the SP1, SP2 and SP4 QoS capabilities. The Internet as a split of different MQC planes offers an ordered and simplified view of the Internet QoS capabilities. End-users can select the MQC plane that is the closest to their needs, as long as there is a path available for the destination. One of the main outcomes of applying the MQC concept is that it alleviates the complexity and the management burden of inter-domain relationships. Building end-to-end QoS paths for the purpose of QoS guaranteed communications between end-users, is going a step further in the QoS process. The full description of customer-to-provider QoS agreements and the way they are enforced is outside the scope of this memo. However some suggestions can be given. Route path selection within a selected MQC plane can be envisaged in the same way as the traditional routing system used by Internet routers. Thus, we can rely on the BGP protocol, basically one BGP occurrence per MQC plane, for the inter-domain routing process. The resilience of the IP routing system is preserved: if a QoS path breaks somewhere, the routing protocol will make it possible to compute dynamically another QoS path if available, in the proper MQC plane. BGP can also be used to convey QoS-related information via (AFI/ SAFI) [RFC2858], and implement a process where Autonomous Systems add their own QoS values (D, J, L) when they propagate an AS path. Then, the AS path information is coupled with the information on Delay, Jitter and Loss, and the decision whether or not to use the path selected by BGP can be taken based on numerical values. The QoS value of an AS path could also be disconnected from BGP and computed via an off-line process. We can even go a step further in the control of the path: enforcing an explicit routing scheme, making use of RSVP-TE/MPLS-TE requests [RFC3209], before injecting the traffic in an l-QC thread. MQC is a concept that helps to resolve problems [WIP] without prohibiting the use of any particular mechanism or protocol at the data, control, or management planes. Levis & Boucadair Expires August 23, 2007 [Page 12] Internet-Draft MQC and provider QoS agreements February 2007 6. IANA Considerations There are no IANA considerations. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations This document describes a framework and not protocols or systems. Potential risks and attacks will depend directly on the implementation technology. Solutions to implement this proposal must detail security issues in the relevant protocol documentation. Particular attention should be paid to giving access to MQC resources only to authorized traffic. Unauthorized access can lead to denial of service when the network resources get overused [RFC3869]. 8. 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. 9. References 9.1. Normative References [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. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. Levis & Boucadair Expires August 23, 2007 [Page 13] Internet-Draft MQC and provider QoS agreements February 2007 9.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. [LEV] Levis, P., Asgari, H., and P. Trimintzios, "Consideration on Inter-domain QoS and Traffic Engineering issues Through a Utopian Approach", SAPIR-2004 workshop of ICT-2004, (C) Springer-Verlag, August 2004. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [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. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3387] Eder, M., Chaskar, H., and S. Nag, "Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network", RFC 3387, September 2002. [RFC3869] Atkinson, R., Floyd, S., and Internet Architecture Board, "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. Levis & Boucadair Expires August 23, 2007 [Page 14] Internet-Draft MQC and provider QoS agreements February 2007 Authors' Addresses Pierre Levis France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France Email: pierre.levis@orange-ftgroup.com Mohamed Boucadair France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France Email: mohamed.boucadair@orange-ftgroup.com Levis & Boucadair Expires August 23, 2007 [Page 15] Internet-Draft MQC and provider QoS agreements February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Levis & Boucadair Expires August 23, 2007 [Page 16]