PCE Working Group M. Boucadair (Ed.) IETF Internet Draft P. Morand (Ed.) Document: draft-boucadair-pce-interas-01.txt France Telecom R&D Proposed Status: Informational May 2005 Expires: November 2005 A Solution for providing inter-AS MPLS-based QoS tunnels < draft-boucadair-pce-interas-01.txt > Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667 [RFC3667]. 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 become aware will be disclosed, in accordance with RFC 3668 [RFC3668]. 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 November 2005. Abstract This document describes a solution for providing inter-AS MPLS-based Quality of Service (QoS) tunnels. This solution makes use of Path Computation Elements (PCE) as a means to compute inter-domain constraint-based paths. Service considerations and agreements between two IP Network Providers (INP) implementing this solution are also described. Copyright Notice Boucadair (Ed.) Informational - Expires November 2005 [Page 1] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels Copyright (C) The Internet Society. (2005) Table of Contents 1. Contributors................................................2 2. Changes since last version:.................................2 3. Terminology.................................................2 4. Introduction................................................3 4.1. General.....................................................3 4.2. Assumptions.................................................4 4.3. Draft structure.............................................5 5. Conventions used in this document...........................5 6. Inter-AS PCE model..........................................5 7. Inter-provider Service Considerations.......................7 8. Path Computation Element functions..........................8 9. PCE discovery..............................................10 10. PCE to PCE Communication...................................10 11. Routing considerations.....................................11 11.1. Assumptions.................................................11 11.2. Finding inter-domain LSP paths..............................11 12. Communication between PCE and LSR/LER for initiating LSP set-up...............................................13 13. Advanced features..........................................13 13.1. Exclusion of specific ASs from the path.....................13 13.2. Feedback....................................................13 14. Security Considerations....................................14 15. References.................................................14 16. Acknowledgments............................................14 17. Author's Addresses.........................................15 1. Contributors o Hamid Asgari (Thales Research and Technology) o Noel Butler (Thales Research and Technology) o Panagiotis Georgatsos (Algonet) o David Griffin (University College London) o Micheal Howarth (University of Surrey) 2. Changes since last version: The main changes occurred in this version are: o Add new contributor to the draft o Rewording of several sections of the draft 3. Terminology This memo makes use of the following terms: Boucadair (Ed.) Informational - Expires November 2005 [Page 2] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels o Path Computation Element (PCE): an entity that is responsible for computing/finding inter/intra domain MPLS tunnels (LSPs). This entity can simultaneously act as client and a server. Several PCEs can be deployed in a given AS. o Path Computation Client (PCC): a PCE acting as a client. This entity is responsible for issuing path computation requests that fulfill the Service Management constraints for the establishment of inter/intra domain LSPs. o Path Computation Server (PCS): a PCE acting as a server. This entity is responsible for handling path computation requests including neighboring PCC constraints. o High-level service: the service employing a PCE-based system as the underlying infrastructure for creating e.g., inter-domain QoS VPNs. o High-level service customer: the customer that subscribes to a High-level service. o pSLS(provider SLS): A provider level SLS, which is established for specific QoS class between two Internet Network Providers (INP) for exchanging traffic in the Internet with the purpose to expand the geographical span of their offered services. pSLSs are meant to support aggregate traffic and they are assumed to exist prior to any agreements with end customers. o SLS Management: a service level management system, which includes service ordering (i.e for establishing contracts between peer providers) and service invocation (i.e for committing resources before traffic can be admitted) o q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into account QoS information as input for its route selection process. o Domain: within this document it denotes an Autonomous System. 4. Introduction 4.1. General The level of Quality of Service (QoS) guarantees offered by INPs using a pure IP-based traffic engineering (TE) solution, other than overbooking, is not yet satisfactory for all corporate business services, for which strong guarantees must be provided. For this type of customers, hard QoS performance and bandwidth guarantees are considered as the major requirements. Boucadair (Ed.) Informational - Expires November 2005 [Page 3] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels Currently, these requirements can be satisfied within a single domain or across several interconnected domains managed only by a single INP. However, it becomes very challenging when these domains are managed by different INPs. Each INP defines and deploys its own QoS policy within the scope of its domain(s), utilizes its proprietary TE functions, etc. Providing QoS-based services within the scope of the Internet requires the collaboration among INPs in order to offer this type of services. This document aims at proposing a solution that will facilitate the introduction of such services in an Inter-provider environment. Service considerations are also taken into account. 4.2. Assumptions In this document, we assume the following: o An AS can announce a given prefix in several QoS planes; each of these QoS planes being identified across inter-domain links by a unique DiffServ Code Point (DSCP); o Each announcement, except best effort ones, contains values of a set of QoS parameters that characterizes the likely end-to-end QoS to be experienced for reaching a given prefix (we call this end-to-end QoS as aggregated QoS); o The way aggregated QoS values are computed is out of the scope of this document; o Adjacent ASs agree on the DSCP values to use in order to signal a given QoS class at inter-domain links (we call these DSCP values inter-domain DSCPs); o Every AS has the freedom to bind an inter-domain DSCP to a local DSCP within its domain, which identifies its local QoS class for signalling a QoS planes in its domain; o An AS supporting the inter-domain MPLS-based QoS tunnels service, owns a Path Computation Service Identifier(s) (PCSID), which is a routable IP address. This IP address is not necessarily the IP address(es) of the PCE(s) of the domain. These PCSIDs are announced per QoS plane basis, by an inter- domain routing protocol, together with the planeÆs aggregated QoS values; o ASs can discover other ASs supporting the inter-domain MPLS- based QoS tunnels service by receiving inter-domain routing protocol announcements. These announcements provide an AS with Boucadair (Ed.) Informational - Expires November 2005 [Page 4] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels the end-to-end QoS characteristics of the path towards any prefix of the remote AS owning the PCSID. 4.3. Draft structure The structure of this document is as follows: o Section 5 describes the inter-AS PCE model. o Section 6 discusses the service considerations. o Section 7 highlights PCE functions. o Section 8 explains the PCE discovery function. o Section 9 gives an overview of the PCP protocol that is used for communication between PCEs. o Section 10 and 11 describe routing issues. o Finally, section 12 presents some advance features in order to enhance PCE service. 5. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 6. Inter-AS PCE model A Path Computation Element (PCE) is responsible for finding an inter- domain path satisfying a set of constraints (e.g. specific QoS performance guarantees requested by a customer), in order to establish inter-domain constraint-based LSPs. In an inter-provider environment, the computation of this path is necessarily distributed and required communication between PCEs of different domains. Communication between PCE entities is achieved via the PCE Communication Protocol (PCP, [INTERAS-PCP]). Once computed, the path is provided to the RSVP-TE/MPLS machinery of the head-end Label Switching Router (LSR), which can request/establish an inter- domain Label Switching Path (LSP) that will follow the inter-domain path provided by the PCE. +----------------+ | | +----+ AS1 +----+ Boucadair (Ed.) Informational - Expires November 2005 [Page 5] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels ..........|ASBR| |ASBR|.......... BGP Session . +----+ +----+ . . | | . . | +----+ | . . +-----|PCE |-----+ . . +----+ . . ^ ^ . . | | . . | | . +----+ | | +----+ +-----|ASBR|-----+ | | +-----|ASBR|-----+ | +----+ | | | | +----+ | | AS2 +----+ | | +----+ AS3 | | | P | | | | P | | | | C |<---------/ \-------->| C | | | | E |<--------------------->| E | | | +----+ +----+ | | | | | | +----+ | | +----+ | +-----|ASBR|-----+ +-----|ASBR|-----+ +----+ +----+ |. . . . . . . . . . . . . . . . . . . . . . . | ...: Peering links ---: inter-PCE session Figure 1: Inter-AS PCE scenario In the above figure, we assume that each domain operates a set of QoS-classes. Each INP deploys its own local QoS-classes with specific QoS characteristics. QoS-classes in a domain have not necessarily the same QoS characteristics with QoS-classes in the other domains. We also assume that service level QoS-based contracts (pSLSs) have been established between adjacent domains. BGP is running between these adjacent ASs. Each AS learns, the set of destinations its peer domains can reach, together with end-to-end QoS performance characteristics. When a pSLS is established, the domains exchange their respective PCE information (name, IP address, identifiers, authentication information, etc.). In order to create an inter-domain constraint-based LSP, the domain which requests the establishment of the LSP asks its PCE to compute an inter-domain path satisfying a set of constraints, (for example bandwidth guarantee per QoS-Class, maximum end-to-end delay, etc.) The first PCE selects one possible path among the set of alternatives and identifies the next-hop domain. It then verifies that appropriate resources are available in its own domain and sets up administrative pre-reservations in the management system of its domain. Then it Boucadair (Ed.) Informational - Expires November 2005 [Page 6] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels contacts the next hop PCE, requesting a path computation between the next hop AS Border Router (ASBR) and the termination address of the inter-domain LSP. This second PCE performs the same computation as the first one did and the procedure is iteratively repeated up to the last PCE. If a path satisfying all requirements is found, each PCE returns the path received from the responding PCE concatenated with the sub-path it computed. Finally, the originating PCE receives the whole computed path. 7. Inter-provider Service Considerations A pSLS MUST be established between two neighbors in order to grant to the requestor the appropriate rights for requesting and/or establishing inter-domain LSPs (see figure below). Nevertheless, information like destination and number of future LSPs to be established is not known in advance. The pSLS indicates only the upper-boundaries that the upstream AS is allowed to use, in terms of QoS-class identifiers that can be used at the inter-domain for establishing inter-domain LSP and in terms of maximum bandwidth associated to each QoS-class. The pSLS agreement does not reserve any network resources in advance. Resources are only allocated when an inter-domain LSP is set up. The management plane of each downstream domain along the path SHOULD be aware of the existence of those LSPs together with their associated QoS guarantees. +--------High Level Service Agreement--------+ | | v v <----AS1-----> <----AS2-----> <----AS3-----> ' ' ' ' ' ' ' '<-pSLS->' '<- pSLS->' ' ' ' ' ' ' ' +------------+ +------------+ +------------+ | PCE | | PCE | | PCE | | | | | | | | +------+ | | +------+ | | +------+ | | | PCC | | | | PCC | | | | PCC | | | | |<-|--\ | | |<-|--\ | | | | | +--/\--+ | | | +--/\--+ | | | +--/\--+ | | || | |PCP | || | |PCP | || | | || | | | || | | | || | | +--\/--+ | | | +--\/--+ | | | +--\/--+ | | | PCS | | \-----|->| PCS | | \------|->| PCS | | | | | | | | | | | | | | | +------+ | | +------+ | | +------+ | +------------+ +------------+ +------------+ Figure 2: Service Overview Boucadair (Ed.) Informational - Expires November 2005 [Page 7] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels However, it is difficult to establish such a contract in advance especially when the LSP path is not known in advance. Thus, the sequence of operation for establishing an LSP should be: o Compute inter-domain path candidate(s); o Select and request an inter-domain path for this particular LSP using information returned by the PCE, o Establish the LSP once final negotiation terms have been agreed end-to-end between PCEs of adjacent domains. The establishment of this cascade of negotiations can be difficult to achieve and can take some time. In particular, the risk is not negligible that the resources that were available when the PCE performed the path computation are no longer available along the path when the cascaded negotiation terms are agreed, because others LSPs have used the corresponding resources. In order to solve this issue it is necessary that the PCE of each domain makes an administrative reservation of the corresponding resources and indicates the characteristics of the path. This information is registered by the management plane, which triggers in parallel the creation of a provisional contract referencing the technical characteristics of the future LSP. Subsequent path computation requests may be impacted because the management plane removes these resources from the available overall network resources. This provisional contract is valid for a limited time period, which is the minimum of time periods each specified and reported by a domain along the path. If time period expires, the provisional contract can be removed from the management systems, and related administrative network resources have to be informed. It is the responsibility of the management plane of each domain to cooperate in agreeing the exact financial terms and additional clauses of this contract, including its duration. Each domain knows the entry and the exit point of the LSP within its own domain and consequently knows both the upstream and downstream ASs to deal with. This validation procedure SHOULD ideally be automated to speed up the process and could integrate pricing negotiation. The way that the other blocks of the management plane deal with this automation is out the scope of this document. Thus, once the pre-contract is validated, the path computed by the PCE can be provided to the head-end LSP, which effectively sets up the LSP. Note that every ingress point of each domain SHOULD activate some outsourced policy functions that would allow RSVP TE to get an agreement from the management system. 8. Path Computation Element functions Boucadair (Ed.) Informational - Expires November 2005 [Page 8] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels The main function provided by a PCE is to contribute to the overall path computation by computing part of the end-to-end inter-domain path satisfying a set of constraints. The management plane could call other elementary services such as requesting a path computation for informational purposes or canceling a request in progress for instance. The deployment and the maintenance of the LSP connectivity require cooperation of several functional entities from different planes. Within this document, the PCE is only responsible for computing an inter-domain constraint-based path. The implementation of the service (whether it is automated or not) and the creation of inter-domain LSP results from the cooperation of functional blocks, control plane blocks and data plane blocks arenÆt described in this document. The PCE does not itself trigger the establishment of any inter-domain LSP, but provides inter-domain paths, if they are available. Unlike the management plane, it is not aware of business considerations A PCE entity provides an interface used by the service management block to request a path computation. It communicates with other remote PCE thanks to the PCP protocol and requests additional services from other functional blocks as illustrated in the figure below: +---------------------+ | Service Management | +----------o----------+ | | v +----------+ +----------+ +----------+ | PCE |<---------->| PCE |<---------->| PCE | +----------+ +----------+ +----------+ | /----------------+-----------------+----------------\ | | | | +---v---+ +---v---+ +---v---+ +---v---+ | | | | | | | | |BW Mgt | | SLS | |Access | | Intra | | | | Mgt | | & | | & | | | | | |Author | | Inter | | | | | | | | TE | | | | | | | | | +-------+ +-------+ +-------+ +-------+ Figure 3: PCE Interactions The PCE interacts with the dynamic routing processes to retrieve routing information that is used to compute an inter-domain path satisfying the expressed constraints. An interface MUST be made available to the PCE so that it can access routing information. Note that both intra and inter-domain routes MUST be made available to the PCE. Boucadair (Ed.) Informational - Expires November 2005 [Page 9] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels In addition, for access control and authorization purposes, the PCE MUST be provided with access to the list of other PCEs from which it will accept requests. This list is updated each time new pSLSs are negotiated by the INP. 9. PCE discovery Within this document, we assume that during the service negotiation phase the peers exchange the IP addresses of their respective PCE(s). This information is stored in the SLS Management Systems of each INP. As described in [PCE-DISCOVERY], instead of announcing all potential tail-end addresses in BGP, only an identifier is announced via BGP. It is called the Path Computation Service Identifier (PCSID). This particular BGP announcement is identified by a well-known community value (to be defined by IANA) and is represented by a routable IP address, which can be different from the real IP address of the PCE. As a consequence, this particular route SHOULD NOT be installed in the Forwarding Information Base (FIB) since this PCSID is not necessarily the IP address of the PCE. BGP announcements of PCSID will ease to discover the set of remote ASs supporting the inter-AS MPLS-based QoS tunnels service and associated end-to-end QoS-related information for reaching them. In order to compute a path towards a specific domain supporting this inter-AS MPLS-based QoS tunnels service, the local PCE chooses a route that serves the PCSID of that domain and extracts from the AS_PATH attribute the AS number of the next hop ASBR. Then, the local PCE queries its SLS Management system and gets back the PCE's IP address of the next neighboring PCE to contact. Finally, the local PCE forms and forwards a path computation request to the next PCE. The process is iteratively repeated until the request reaches the PCE of the target AS identified by its PCSID. 10. PCE to PCE Communication A PCE can act as a client (Path Computation Client, PCC) or a server (Path Computation Server, PCS). The PCC is responsible for issuing Path Computation requests. The PCS is responsible for handling requests received from PCCs. The PCP (Path Computation Protocol) is a simple query and response protocol that is used for communication between PCE entities, i.e., PCC and PCS. +------------+ +------------+ | PCE | | PCE | Boucadair (Ed.) Informational - Expires November 2005 [Page 10] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels | | | | | +------+ | | +------+ | | | PCC | | | | PCC | | | | |<-|-------\ | | | | | +--/\--+ | | | +--/\--+ | | || | |PCP | || | | || | | | || | | +--\/--+ | | | +--\/--+ | | | PCS | | \---------------|->| PCS | | | | | | | | | | | +------+ | | +------+ | +------------+ +------------+ Figure 4: PCC to PCS communication The main characteristics of the PCP protocol are: o The protocol employs a client/server model in which a PCE can both act as a client and/or a server at the same time. A PCE Client (PCC) sends requests, cancellation and receives responses. o The protocol uses TCP as its transport protocol, providing the reliable exchange of messages between PCEs. o In its first version, PCP does not provide any message level security for authentication, message replay protection, and integrity. However, PCP can reuse existing protocols for security such as IPSEC [RFC2401] or TLS [RFC2246] to authenticate and secure the channel between two PCE. o The current PCP protocol provides the service for supporting only a basic path computation function. In particular it does not support the service for additional path computation constraints, or provide enhanced reporting features in the case of path computation failure. 11. Routing considerations 11.1. Assumptions We assume in this document that PCE addresses are only announced in a few QoS-Class planes. Addresses of LSR/LER interfaces could be announced in the best effort plane. This reduces the number of BGP announcements to one announcement per PCE per AS. By setting a well- known community value, we specify announcements that serve PCEs. These are not regarded as routes and are not stored in the FIBs. 11.2. Finding inter-domain LSP paths Boucadair (Ed.) Informational - Expires November 2005 [Page 11] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels In order to find an inter-domain path, the PCE MUST be provided with a set of attributes including the information describing head-end and tail-end of the LSP and the performance requirements for the LSP. The aforementioned information MUST include the loopback IP address of its LSR, and the IP Address of the PCE of its domain (notation is IPADDRESS@PCSID). This information MUST also include the performance guarantees required for the inter-domain constraint-based LSP. This information MAY encompasses the requested QoS-class(es) so that the set of collaborating PCE can compute a path that will cross a set of domain satisfying the expressed constraints. It can also contain, per QoS-class, additional QoS performance guarantees that the PCE must take into account. These performance guarantees include guaranteed end-to-end delay, jitter, loss rate and/or bandwidth. Note that these parameters can differ depending on the type of requested QoS-class, and they MAY not all be present in the LSP set-up request. If included in the path computation request they MUST be taken into account by the PCE. If the PCE doesn't recognize a given QoS parameter, the PCE MUST stop its computation and MUST return an error (PCP Error Message). When computing a path, a PCE interacts with other blocks of the management plane. In particular, it checks the availability of the resources within the boundaries of its domain. If the resources are available, and the sub-path (path between the ingress point of its domain and a potential ingress point of a given domain) conforms to the path constraints requested, it MUST inform the management plane of a pre-reservation concerning this path. This information can then be taken into account when processing other path computation requests. Once this operation succeeds, the request is propagated to the next domain PCE, which has been selected by the PCE of this domain. Note that the performance guarantees requested MUST be updated before forwarding it to the next domain by taking into account the performance figures already observed along the computed sub-path plus the performance figures within its own domain. Therefore, PCE MUST be aware of the above performance figures of the QoS-classes. The requesting PCE MUST use the QoS-class identifier they agreed during the pSLS negotiation phase in order to signal a given QoS- class. If an end-to-end LSP has to be re-engineered because the associated constraints have changed in terms of QoS-class requested, bandwidth, delay, etc., a new end-to-end path needs to be computed. In order to improve its chances of finding a valid path, the requestor can specify that the path for which the request is issued will replace a previously established LSP. For doing so, the requestor can indicate the reference of the path corresponding to this LSP. A PCE can release, during the path computation process, the resources Boucadair (Ed.) Informational - Expires November 2005 [Page 12] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels corresponding to the former LSP, if the new path follows part of the former path. This reference is stored in the management plane of each domain and is generated by the initial requestor. This reference is globally unique. The ability to address such additional constraints can be interesting in the case of backup LSPs, so that the PCE can compute a path along a different route. These considerations are out of scope of this document. 12. Communication between PCE and LSR/LER for initiating LSP set-up Communication between PCE and an LER/LSR could be achieved thanks to the use of Common Open Policy Service protocol (COPS, [RFC2748]). An RSVP client-type could be used in order to convey configuration data resulting from the computation operation executed by a PCE. Specification of RSVP configuration data is out of scope of this document. 13. Advanced features 13.1. Exclusion of specific ASs from the path If a PCE in the chain wants to exclude particular AS(s) from the path, additional constraints (that can be expressed using the AS number of the excluded domain/s) MUST be added to the request message body and MUST be propagated downstream. 13.2. Feedback When computing a path, the PCEs can fail to find a path for a number of reasons. These failures, in normal operations, will be mainly due to the lack of resources, or not meeting the requested QoS requirements. In such a situation, a path, which would have been the optimal path, would not be established. Identifying the domain/s where the path computation failed, together with the reasons, would be of a real added value for providers in order to improve their efficiency. A proposal for achieving this is to rely on the Path Computation Protocol, which could be improved to return all the path alternatives which were tried but have failed. In doing so, the requesting provider would be aware of the reasons of the failure and possibly interact with that AS where the path computation failed and aborted. The AS (where the path computation failed), faces with multiple requests, from external domains, could consider a possible Boucadair (Ed.) Informational - Expires November 2005 [Page 13] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels modification of some of its peering agreements based on business objectives. 14. Security Considerations This document does not change the underlying security issues in the PCP and BGP protocols specifications. It is recommended that a security protocol like IPSec or TLS to be activated in order to protect PCP sessions. 15. References [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004 [RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP MD5 Signature Option", RFC 2385, August 1998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [INTERAS-PCP] Boucadair M., Morand P., "Inter PCE Communication Protocol", draft-boucadair-pcp-interas-01.txt, May 2005 [PCE-DISCOVERY] Boucadair M., Morand P., "PCE discovery via Border Gateway Protocol", draft-boucadair-pce-discovery-01.txt, Work in progress, May 2005 [RFC2401] Atkinson R., "Security Architecture for the Internet Protocol", RFC 2401, August 1998 [RFC2246] Dierks T., Allen C., "The TLS Protocol", RFC 2246, January 1999 [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. 16. Acknowledgments The authors would also like to thank all the partners of the MESCAL (Management of End-to-End Quality of Service Across the Internet At Large, http://www.mescal.org) project for the fruitful discussions. Boucadair (Ed.) Informational - Expires November 2005 [Page 14] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels 17. Author's Addresses Mohamed Boucadair France Telecom R & D 42, rue des Coutures BP 6243 14066 Caen Cedex 4 France Phone: +33 2 31 75 92 31 Email: mohamed.boucadair@francetelecom.com Pierrick Morand France Telecom R & D 42, rue des Coutures BP 6243 14066 Caen Cedex 4 France Email: pierick.morand@francetelecom.com 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, Boucadair (Ed.) Informational - Expires November 2005 [Page 15] Internet Draft A Solution for May 2005 providing inter-AS MPLS-based QoS tunnels 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. Boucadair (Ed.) Informational - Expires November 2005 [Page 16]