Network Working Group C. Jacquenet Internet Draft France Telecom R&D Document: draft-jacquenet-qos-ext-bgp-00.txt February 2001 Category: Informational Quality of Service Extensions to the BGP4 Protocol: motivation and framework Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This draft aims at proposing both a motivation and a framework for specifying Quality of Service (QoS) extensions to the Border Gateway Protocol version 4 (BGP4, [2]). 1. Introduction For almost the last decade, the deployment of value-added IP service offerings over the Internet has raised among the service providers a collection of concerns, as far as the quality associated to the actual provisioning of such services is concerned. These issues have been expressed in terms of (the check-list is not exhaustive): - As far as the actual processing of the IP traffic is concerned, how should the routers of an IP network behave whenever congestion is experienced? - How should a QoS policy be enforced to accurately reflect the fact that some traffics deserve a better treatment than others, Category - Expiration [Page 1] Internet Draft QoS extensions to the BGP4 protocol February 2001 according to the different levels of quality customers may subscribe to? - How should the switching and transmission resources of an IP network be designed so that they actively participate in honoring the commitments of a service provider towards its customers, as far as the perception of the actual quality of the service by the end- users is concerned? - When considering the deployment of IP services worldwide, how an end-to-end QoS policy could be enforced when considering that multiple domains will be crossed by the traffic that characterizes these QoS-based service offerings? These questions yielded a dramatic development of the specification effort ([3], [4]), as far as quality of service in IP networks is concerned. Nevertheless, providing end-to-end quality of service for the IP traffic that crosses administrative domains still remains an issue, mainly because: - QoS policies may dramatically differ from one service provider to another, - The actual enforcement of a specific QoS policy may also differ from one domain to another, although the definition of a set of basic and common quality of service indicators may be shared between the service providers. This draft aims at providing an argumentation for the specification and the development of QoS extensions to the BGP4 protocol, so that it may participate in addressing the above-mentioned inter-domain issues. As such, this draft is organized according to the following sections: - Section 3 aims at providing elaboration on the issues that may be partially addressed by the use of the BGP4 protocol, as far as the enforcement of an end-to-end QoS policy is concerned, - Section 4 aims at describing what could be the framework related to the definition and the specification of QoS extensions to the BGP4 protocol. 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 [5]. Jacquenet Informational - Expires August 2001 [Page 2] Internet Draft QoS extensions to the BGP4 protocol February 2001 3. Quality of service issues in deploying cross-domain IP services and motivation for adding QoS extensions to the BGP4 protocol The basic provisioning of an access to the Internet implies for services providers that they establish BGP4 peering relationships between themselves, so that their respective customers get the full IP connectivity (i.e. communicate with the "outside" IP world). The perceived quality of this kind of service by customers is often qualified in terms of the variation of the response time that is associated to a HTTP (HyperText Transfer Protocol) request or the retrieval of a given file via the File Transfer Protocol (FTP) related to the access to the Internet has yielded the promotion of a spectrum of levels of service, often compared to the Olympic medal taxonomy, so that gold customers are supposed to benefit from harder guarantees than the bronze customers, in terms of packet loss rate for example. While this kind of QoS policy can be enforced by means of mechanisms like those being specified in [6], and that will be activated on the routers that are managed by a given service provider, there is obviously no guarantees (for the customers) that other service providers will enforce this QoS policy the same way, so that the commitments both the customer and the service provider have contractually agreed upon rely on local agreement considerations, i.e. the configuration information that is processed by the routers of a given domain only. Furthermore, value-added IP service offerings like IP VPNs (IP Virtual Private Networks) that may be deployed across several domains (whatever the underlying technology) often imply the negotiation and the invocation of QoS requirements (like the contractual definition of a one-way metric delay, the inter-packet delay variation, etc.) between the customer and the provider, although the latter is generally unable to honor such commitments whenever they imply the crossing of several domains. According to these two examples, the QoS issues related to the deployment of IP services over multiple domains can be summarized as follows: For the purpose of enforcing an end-to-end QoS policy (assuming that "end-to-end" means that the corresponding IP traffic will have to cross several domains), there is a strong need of service providers to exchange (if not agree on the meaning of) QoS- related information. The QoS-related information can consist of (but is obviously not limited to): (1) Packet rate, i.e. the number of IP datagrams that can be transmitted (or have been lost) per unit of time, (2) One-way delay, as defined in [7], Jacquenet Informational - Expires August 2001 [Page 3] Internet Draft QoS extensions to the BGP4 protocol February 2001 (3) Inter-packet delay variation, as defined in [8], (4) PHB Identifier, as defined in [9]. It is assumed that these QoS metrics are systematically associated to the routes that lead to the destination prefix indicated in the header of the IP datagrams, so that service providers can fully benefit from the meaning of such information, possibly yielding the refinement of routing policies, for example. This draft therefore assumes that IP routers could gracefully and actively participate in the exchange of such information, since they are one of the key components of the IP networks that support such QoS-based IP service offerings. 4. A proposed framework for adding QoS extensions capabilities to the BGP4 protocol According to the above section, the use of the BGP4 protocol to convey this QoS-related information between domains appears to be one of the most natural choices, simply because of the systematic activation of this routing protocol for the purpose of exchanging reachability information between domains. From this standpoint, the proposed framework of the corresponding specification effort focuses on the use of the BGP4 attribute machinery that has proven its great flexibility, and this proposal is primarily reflected in the companion document [10] of this draft. 5. Security Considerations The need for exchanging QoS-related information between domains thanks to the use of the BGP4 protocol yields security concerns that are related to the preservation of the confidentiality of this information. Although this draft does not explicitly change the underlying security issues inherent in the existing BGP-4 protocol specification [11], the upcoming versions of this document will provide additional elaboration on this issue. 6. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. Jacquenet Informational - Expires August 2001 [Page 4] Internet Draft QoS extensions to the BGP4 protocol February 2001 [3] Nichols K., Blake S., Baker F., Black D., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [4] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G., Egan R., Griffin D., Georgatsos P., Georgiadis L., "Specification of a Service Level Specification (SLS) Template", draft-tequila-sls-00.txt, Work in Progress, November 2000. Check http://www.ist-tequila.org for additional information. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [6] Bernet Y. et al., "An Informal Management Model for Diffserv Routers", draft-ietf-diffserv-model-06.txt, Work in Progress, February 2001. [7] Almes G., Kalidindi S., "A One-Way-Delay Metric for IPPM", RFC 2679, September 1999. [8] Demichelis C., Chimento P., "IP Packet Delay Variation Metric for IPPM", draft-ietf-ippm-ipdv-06.txt, Work in Progress, February 2001. [9] Black D., Brim S., Carpenter B., Le Faucheur F., "Per Hop Behavior Identification Codes", draft-ietf-diffserv-2839bis- 01.txt, Work in Progress, February 2001. [10] Jacquenet C., "Providing Quality of Service Indication by the BGP-4 Protocol: the QOS_NLRI attribute", draft-jacquenet-qos- nlri-02.txt, Work in Progress, February 2001. [11] Heffernan A., "Protection of BGP sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 7. Acknowledgments Part of this work is funded by the European Commission, within the context of the TEQUILA (Traffic Engineering for Quality of Service in the Internet At Large Scale, [12]) project, which is itself part of the IST (Information Society Technologies) research program. 8. Author's Addresses Christian Jacquenet France Telecom R & D DMI/SIR 42, rue des Coutures BP6243 14066 Caen Cedex 04 Jacquenet Informational - Expires August 2001 [Page 5] Internet Draft QoS extensions to the BGP4 protocol February 2001 France Phone: +33 2 31 75 94 28 Email: christian.jacquenet@francetelecom.fr 9. Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Jacquenet Informational - Expires August 2001 [Page 6]