Network Working Group M. Boucadair (Ed.) IETF Internet Draft P. Morand (Ed.) Document: draft-boucadair-pce-interas-00.txt France Telecom R&D Proposed Status: Informational October 2004 Expires: April 2005 A Solution for providing inter-AS MPLS-based QoS tunnels < draft-boucadair-pce-interas-00.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 April 2005. Abstract This draft 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 Service Providers implementing this solution are also described. Copyright Notice Copyright (C) The Internet Society. (2004) Boucadair (Ed.) Informational - Expires April 2005 [Page 1] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels Table of Contents 1. Contributors................................................2 2. Terminology.................................................2 3. Introduction................................................3 3.1. General.....................................................3 3.2. Assumptions.................................................4 3.3. Draft structure.............................................4 4. Conventions used in this document...........................5 5. Inter-AS PCE model..........................................5 6. Inter-provider Service Considerations.......................6 7. Path Computation Element functions..........................8 8. PCE discovery...............................................9 9. PCE to PCE Communication...................................10 10. Routing considerations.....................................11 10.1. Assumptions.................................................11 10.2. Finding inter-domain LSP paths..............................11 11. Communication between PCE and LSR/LER......................13 12. Advanced features..........................................13 12.1. Exclude specific ASs in the path computation................13 12.2. Feedback....................................................13 13. Security Considerations....................................14 14. References.................................................14 15. Acknowledgments............................................14 16. Author's Addresses.........................................15 1. Contributors o Hamid Asgari (Thales Research and Technology) o Panagiotis Georgatsos (Algonet) o David Griffin (University College London) o Micheal Howarth (University of Surrey) 2. Terminology This memo makes use of the following terms: o Path Computation Element (PCE): an entity that is responsible for computing/finding inter/intra domain 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. Boucadair (Ed.) Informational - Expires April 2005 [Page 2] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels 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: is the service using a PCE-based system as an underlying infrastructure (an inter-domain QoS VPNs service for instance) o High-level service customer: is a customer that subscribes to a High-level service. o pSLS: A provider SLS is an SLS established between two Internet Network Providers (INP) with the purpose of extending the geographical span of their service offers. o SLS Management: this includes service ordering (i.e establishing contracts between peers) and invocation (i.e 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 draft it denotes an Autonomous system. 3. Introduction 3.1. General The level of Quality of Service (QoS) guarantees reached with a pure IP-based traffic engineering (TE) solution, other than overbooking, is not satisfactory for all corporate business services for which strong guarantees must be provided. For this category of customers, guaranteed QoS performances and bandwidth reservation are considered as critical requirements. These requirements can be satisfied within a single domain or across several interconnected domains managed by a single IP Network Provider (INP). However, it becomes more difficult to satisfy these requirements when distinct INP manage these domains. Each INP has the right to define and deploy its own QoS policy within the scope of its domain(s), its proprietary TE functions and etc. Offering a QoS-based service within the scope of the Internet requires the collaboration of many INPs in order to offer this category of services. This draft aims at proposing a solution that will ease the introduction of such services in an Inter-provider environment. Service considerations are also taken into account. Boucadair (Ed.) Informational - Expires April 2005 [Page 3] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels 3.2. Assumptions Within this draft, we assume the following: o An AS can announce a given prefix in several QoS plans; each of these QoS plans being identified by a unique Diffserv Code Point (DSCP) value per inter-domain link. o Each non-best effort announcement contains a set of QoS parameters values that characterizes the end-to-end QoS that will be experienced to reach a given prefix (we refer to 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 per inter-domain link (we will refer to this DSCP values as inter-domain DSCP). o Every AS has the freedom to bind an inter-domain DSCP value to a local DSCP value, which identifies its local QoS class. 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 on a per DSCP plan basis, by an inter-domain routing protocol, together with their aggregated QoS values. o Remote ASs can discover ASs supporting the inter-domain MPLS- based QoS tunnels service by learning inter-domain routing protocol announcements that serve PCSIDs. These announcements provide the local AS with the end-to-end QoS characteristics of the path towards any prefix of the remote AS owning the PCSID. 3.3. Draft structure The structure of this draft is as follows: o Section 5 describes the inter-AS PCE model, o Section 6 argues about service considerations, o Section 7 highlights PCE functions, o Section 8 is about PCE discovery function, Boucadair (Ed.) Informational - Expires April 2005 [Page 4] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels o Section 9 gives an overview of the PCP protocol that is used for communication between PCEs, o Section 10 and 11 are dedicated to routing issues, o And finally section 12 presents some advance features in order to enhance PCE service. 4. 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]. 5. Inter-AS PCE model The Path Computation Element (PCE) is responsible for finding an inter-domain path satisfying a set of constraints (like QoS performance guarantees) 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 from 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 +----+ ..........|ASBR| |ASBR|.......... BGP Session . +----+ +----+ . . | | . . | +----+ | . . +-----|PCE |-----+ . . +----+ . . ^ ^ . . | | . . | | . +----+ | | +----+ +-----|ASBR|-----+ | | +-----|ASBR|-----+ | +----+ | | | | +----+ | | AS2 +----+ | | +----+ AS3 | | | P | | | | P | | | | C |<---------/ \-------->| C | | | | E |<--------------------->| E | | Boucadair (Ed.) Informational - Expires April 2005 [Page 5] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels | +----+ +----+ | | | | | | +----+ | | +----+ | +-----|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, which are not necessarily the same than in the other domains. Each INP deploys its own local QoS-classes (i.e. DSCP value, QoS parameters, queuing techniquesą). We also assume that pSLSs have been established between adjacent domains allowing the parties to exchange some amount of IP traffic requesting per inter-domain QoS- class (this traffic MUST be identified by the agreed inter-domain DSCP value). BGP is running between these adjacent ASs. Each AS learns, the set of destinations its peer domains can reach, together with aggregated QoS performance characteristics. When a pSLS is established, the domains exchange their respective PCE information (name, IP address, identifiers, authentication informationą) so that they can communicate. 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 expressed in term of QoS-Class availability along the path together with optional constraints such as: an associated bandwidth guarantee per QoS-Class and/or a maximum end-to-end delay. 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 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. When the last result reaches the originating PCE the whole path is available. 6. Inter-provider Service Considerations Boucadair (Ed.) Informational - Expires April 2005 [Page 6] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels 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 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 an inter-domain path, o Negotiate inter-domain contracts along the path for this particular LSP using information returned by the path computation, o Establish the LSP once final contractual terms have been end-to- end agreed. Boucadair (Ed.) Informational - Expires April 2005 [Page 7] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels The establishment of this cascade of contracts 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 contracts 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, which is the minimum date reported by each domain along the path. If the date exceeds the provisional contract (or pre-contract) can be removed from the management systems, and related administrative network resources have to be relaxed. 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 draft. 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 each ingress point of each domain SHOULD activate some outsourced policy functions that would allow RSVP TE to get an agreement from the management system. 7. Path Computation Element functions The basic elementary service the PCE provides is to compute (more precisely to contribute to compute since the overall computation is distributed) an 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 service described above require cooperation of several functional blocks. Within this draft, the PCE is only responsible for computing an inter-domain constraint- based path. The implementation of the service (whether it is Boucadair (Ed.) Informational - Expires April 2005 [Page 8] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels 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 draft. The PCE does not itself trigger the establishment of any inter-domain LSP, but provides inter-domain paths, when those are available. In particular, it is un-aware of business considerations but the management plane is aware of that. A PCE entity provides an interface for the higher-level functional blocks so that they can ask for 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 liaisons The PCE interacts with the intra- and inter-domain Traffic Engineering blocks to retrieve routing information that is used to compute an inter-domain path satisfying expressed constraints. An interface MUST be made available for the PCE so that it can access to this information. Note that both intra and inter-domain routes MUST be made available to the PCE. 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 pSLSes are negotiated by the INP. 8. PCE discovery Boucadair (Ed.) Informational - Expires April 2005 [Page 9] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels Within this draft, 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 needs to be 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 be 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 together with their associated end-to-end QoS capabilities 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 this next PCE. The process is iteratively repeated until the request reaches the PCE of the target AS identified by its PCSID. 9. 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 requests. The PCS is responsible for handling requests received from PCCs. PCP is a simple query and response protocol that can be used between PCE entities for computing inter-domain QoS constrained paths. +------------+ +------------+ | PCE | | PCE | | | | | | +------+ | | +------+ | | | PCC | | | | PCC | | | | |<-|-------\ | | | | | +--/\--+ | | | +--/\--+ | | || | |PCP | || | | || | | | || | | +--\/--+ | | | +--\/--+ | | | PCS | | \---------------|->| PCS | | Boucadair (Ed.) Informational - Expires April 2005 [Page 10] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels | | | | | | | | | +------+ | | +------+ | +------------+ +------------+ Figure 4: PCE to PCE 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 for reliable exchange of messages between PCE. Therefore, no additional mechanisms are necessary for reliable communication between two PCE. o In this first version, PCP does not specify new authentication mechanisms, replay protection, and message integrity. 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 PCP protocol described below supports only a basic path computation service. In particular it doesn't support additional path computation constraints, nor enhanced reporting features in case of path computation failure. 10. Routing considerations 10.1. Assumptions We assume within this draft that PCSID are announced by BGP in several QoS-Class planes. Addresses of LSR/LER interfaces are supposed to be announced in the best effort plane. In this case, we decrease the number of BGP announcements which is reduced to one announcement per AS. By setting a well-known community value, we identify announcements that deserve ASs supporting the inter-AS MPLS- based QoS tunnels service. These routes aren't stored in the FIBs. 10.2. Finding inter-domain LSP paths In order to find an inter-domain path, the PCE MUST be provided with the head-end and tail-end characteristics of the LSP terminations. Each termination description MUST include the loopback IP address of the LSP end-point and the PCSID of the domain owning the corresponding resources (notation is IPADDRESS@PCSID). Boucadair (Ed.) Informational - Expires April 2005 [Page 11] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels This information MUST also include the performance guarantees required for the inter-domain constraint-based LSP. This information MAY encompasses the requested QoS-classes 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 the PCE must take into account. These performance guarantees may enclose guaranteed end-to-end delay, jitter, loss rate and/or bandwidth. Note that these parameters can differ depending on the QoS-classes and MAY not all be present in a given request. If included in the path computation request they MUST be taken into account by the PCE. If the PCE doesn't understand a given QoS parameter, the PCE MUST stop its computation and MUST return an appropriate error (PCP Error Message). When computing a path, a PCE interacts with other blocks from the management plane. In particular it checks the availability of the resources within the boundaries of its own domain. If the resources are available and the sub-path (path between the ingress point of the domain and a potential ingress point of a neighboring domain) conforms to the path constraints requested, the PCE MUST inform the management plane issuing a pre-reservation concerning this path so that other path computation requests can take this information into account. Once achieved, the request is propagated to the PCE of the next domain, which has been selected by the PCE. Note that the performance guarantees requested MUST be updated in order to reflect the performance guarantees already experienced along the path already computed. For example: in case of end-to-end delay, the end-to-end delay that will be included in the request MUST be computed in such a way it reflects the delay requested between the ingress point of the next domain up to the tail-end termination of the LSP. In order to achieve this computation the PCE MUST be aware of the performance guarantees of the QoS-classes deployed within its own domain. 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ą 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 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 Boucadair (Ed.) Informational - Expires April 2005 [Page 12] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels domain and is generated by the initial requestor. This reference is globally unique. The ability to indicate such additional constraints can be interesting in the case of backup LSPs so that the PCE can compute a path using distinct resources. These considerations are out of scope of this draft. 11. Communication between PCE and LSR/LER 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. 12. Advanced features 12.1. Exclude specific ASs in the path computation If a PCE in the chain wants to exclude particular AS(s) from the path computation, additional constraints (that can be expressed using the AS number of the excluded domains) MUST be added to the request message body and MUST be propagated downstream. 12.2. Feedback When computing a path, the PCE can fail for intra-domain and/or inter-domain reasons. Those failures, in normal operations, should be mainly due to the lack of resources. In such a situation, a path, which would have been the optimal path, would not be established. Identification of the domain where the path computation failed, together with the associated reasons, would be of a real added value for providers in order to improve the service they offer, thanks to an appropriate remote pSLS (re) negotiation request. A proposal for achieving that is to rely on the Path Computation Protocol, which could be improved to return all the path alternatives which were tried but which failed. Doing so, the requesting provider would be aware of the reasons of the failure and possibly interact with the remote failing AS. The remote AS, confronted to multiple requests, from external domain, could consider a possible modification of some of its peering agreements based on objective business incitements. Boucadair (Ed.) Informational - Expires April 2005 [Page 13] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels 13. Security Considerations This draft 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. 14. 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-AS PCE Communication Protocol", draft-boucadair-pcp-interas-00.txt, October 2004 [PCE-DISCOVERY] Boucadair M., Morand P., "PCE discovery via Border Gateway Protocol", draft-boucadair-pce-discovery-00.txt, Work in progress [INTERAS-PCP] Boucadair M., Morand P., "Inter-AS PCE Communication Protocol", draft-boucadair-pcp-interas-00.txt, October 2004 [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. 15. 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 April 2005 [Page 14] Internet Draft A Solution for October 2004 providing inter-AS MPLS-based QoS tunnels 16. 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 April 2005 [Page 15] Internet Draft A Solution for October 2004 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 (2004). 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 April 2005 [Page 16]