TEWG Working Group M. Boucadair(Ed.) Internet Draft France Telecom R&D Document: draft-mescal-interas-00.txt June 2003 Category: Standards Track Contribution to the inter-AS requirements draft 1. Introduction This text is a contribution to the TEWG inter-AS requirements draft. 2. 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 [1]. 3. Contributors o Richard Egan (Thales Research and Technology) o Panagiotis Georgatsos (Algonet) o David Griffin (University College London) o Pierre Levis (France Telecom) o Pierrick Morand (France Telecom) o Yoann Noisette (France Telecom) o Christian Jacquenet (France Telecom) o Panos Trimintzios (University of Surrey) 4. Terminology o QoS Reachability: is a QoS route, i.e. a route whose characteristics (bandwidth, one-way transit delay, etc.) complies with the QoS requirements that MAY have been depicted in a given SLS template, or simply expressed by the customer by any means appropriate. o An inter-AS TE solution/system: is a means of enforcing inter- domain TE policies across multiple ASes. 5. Assumptions Boucadair et al. Standards Track - Expires December 2003 [Page 1] Internet Draft Contribution to June 2003 draft-ietf-tewg-interas-mpls-te-req-00.txt It is clear, that a given provider cannot have direct service contracts with all Internet actors; neither can it constrain Internet reachability to the boundaries of its domain. nor dictate the levels of services offered by other providers. Inevitably then, solutions to inter-AS settlements should rely on agreements between providers based on what is available, deployed and provisioned in the different domains. The domain granularity assumed by this document is the AS and/or set of ASes managed by the same administrative authority. In the rest of this document when referring to interactions between ASes it may be implied to be between different providers. An inter-AS solution will be applicable even to cases where the ASes are under the same administration, i.e. provider. It is envisaged that an approach, which handles the inter-provider case, should be directly applicable to the intra-provider inter-AS (if and only if these ASes are adjacent), since the technical context is the same and in addition the latter lacks all the administrative constraints of the former. Finally, the following general assumptions/constraints are made in order to build solutions that remain in adequacy with the reality of the Internet: o Networks should be ready (i.e. traffic engineered) to convey inter-domain QoS traffic before SLA agreements are negotiated (this is analogous to the case of inter-domain routing when destination prefixes must be configured within an AS before routes are announced to peers). o The solution must not make any assumptions on the applications that will use the QoS capabilities, allowing in for the support of unanticipated applications. 6. Provider Requirements This section presents the set of provider requirements that an inter- AS traffic engineering solution should address to ensure end-to-end QoS delivery. 6.1. Extend the geographical scope of its QoS services This requirement means the ability for a provider to furnish a level of inter-domain QoS equivalent to the one it can offer to its customers for intra-domain traffic. An inter-AS TE solution should ensure that QoS capabilities (resources, bandwidth) are adequately available outside of the domain of a given provider so that he can provide a level of quality that will comply with the contents of the (technical) agreements it has defined with its customers. Boucadair et al. Standards Track - Expires December 2003 [Page 2] Internet Draft Contribution to June 2003 draft-ietf-tewg-interas-mpls-te-req-00.txt More specifically, the intent is to enable a provider to propagate the information related to the QoS it supports, mainly in terms of classes of service within its own domain. This requirement breaks down into the following two non-exclusive cases, regarding how the expandability of the QoS span of a provider is defined: o Limited expandability: The provider is able to offer QoS reachability only to a specific set of destination prefixes outside of its domain. In this case, different QoS levels may apply to different prefixes. That is, a particular QoS level may only be experienced when reaching a specific destination prefix. o Unlimited expandability: The provider is able to offer QoS reachability to any destination prefix in the Internet, much like as today reachability is offered in the Internet at a best- effort level. The offered QoS levels then apply to the entire set of destination prefixes. 6.2. Verify the fulfillment of the contract Providers should have the ability to check that what is provided conforms to what has been agreed contractually. The routes computed by the inter-AS TE solution MUST be compliant with the QoS parameters that have been negotiated between an provider and its customers. A (set of) monitoring tool(s) should be available to check the conformance of the measured QoS against what has been agreed. 6.3. Accounting, charging and billing An inter-AS TE solution SHOULD provide the appropriate information for the support of the following capabilities: o Accounting: Technical process of collecting usage records from network nodes such as sender, receiver or router. o Charging: Transforming the usage records into monetary units and associating them with the user's identity. o Billing: Collecting charging records, summarizing their charging content, and delivering a bill to a customer including an optional list of detailed charges per user, per service. 6.4. Scalability Boucadair et al. Standards Track - Expires December 2003 [Page 3] Internet Draft Contribution to June 2003 draft-ietf-tewg-interas-mpls-te-req-00.txt The performance level of an inter-AS TE solution should be unaffected whatever the scale of deployment, which could be expressed in terms of number of participating domains (and routers), whatever the number of service contracts to be dynamically negotiated and invoked. System performance should also be independent of the volume of QoS-related information that will be propagated across domains, without affecting the overall stability and (access) availability of the IP networks themselves. 6.5. Manageability By manageability, we mean the ability for the inter-AS TE solution to be managed easily. There are two main issues related to network configuration, which must be tackled by an inter-AS TE solution: o The base configuration, which is intrinsic to the solution, must be tolerable and automation must be provided. o The configuration information that relates to the enforcement of a newly established inter-provider agreement/contract must not be too heavy, nor make the system unstable. 6.6. Resilience This requirement means the ability for the system to recover from a failure by automatically repairing itself without the need for restarting the service provided by the system. Applied to the context of an inter-AS TE, in case of failure (e.g. link rupture, router breakdown), the system must be able to compute and select (at least) another path with equivalent QoS characteristics, as far as the impacted destination prefixes are concerned. This operation must ensure that all flows are automatically redirected correctly by minimizing traffic disruption risks as well as avoiding routing loops. 6.7. Ease of deployment The deployment of the inter-domain TE solution should allow for a smooth migration in the case where the network devices that will participate in the enforcement of a set of inter-domain TE policies will have to be upgraded to support the required capabilities. 6.8. Backwards compatibility Boucadair et al. Standards Track - Expires December 2003 [Page 4] Internet Draft Contribution to June 2003 draft-ietf-tewg-interas-mpls-te-req-00.txt This requirement aims at evaluating the risk and impact of deploying an inter-domain TE solution on the infrastructure already in place. Proposed inter-AS TE solutions are likely to introduce modifications on the existing infrastructures to a greater or lesser degree. An inter-AS TE approach should provide adequate guarantees as far as the backward compatibility issue is concerned, not only for allowing a smooth migration, but also to prevent existing infrastructures from being unusable and unstable. Among other criteria, the following requirements MUST be addressed by the inter-domain TE solution: o The impact on the intra-domain routing policies must be minimal. o The impact on the inter-domain (BGP) routing policies must be minimal. o An inter-AS TE solution must not introduce any instability neither on the network itself, nor on the already deployed and offered services. 7. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Boucadair et al. Standards Track - Expires December 2003 [Page 5]