idnits 2.17.1 draft-jacquenet-qos-ext-bgp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 8471 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '12' is mentioned on line 237, but not defined ** Obsolete normative reference: RFC 1771 (ref. '2') (Obsoleted by RFC 4271) == Outdated reference: A later version (-03) exists of draft-tequila-sls-00 ** Obsolete normative reference: RFC 2679 (ref. '7') (Obsoleted by RFC 7679) == Outdated reference: A later version (-09) exists of draft-ietf-ippm-ipdv-06 -- No information found for draft-ietf-diffserv-2839bis - is the name correct? == Outdated reference: A later version (-05) exists of draft-jacquenet-qos-nlri-02 ** Obsolete normative reference: RFC 2385 (ref. '11') (Obsoleted by RFC 5925) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jacquenet 3 Internet Draft France Telecom R&D 4 Document: draft-jacquenet-qos-ext-bgp-00.txt February 2001 5 Category: Informational 7 Quality of Service Extensions to the BGP4 Protocol: motivation and 8 framework 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This draft aims at proposing both a motivation and a framework for 33 specifying Quality of Service (QoS) extensions to the Border Gateway 34 Protocol version 4 (BGP4, [2]). 36 1. Introduction 38 For almost the last decade, the deployment of value-added IP service 39 offerings over the Internet has raised among the service providers a 40 collection of concerns, as far as the quality associated to the 41 actual provisioning of such services is concerned. These issues have 42 been expressed in terms of (the check-list is not exhaustive): 44 - As far as the actual processing of the IP traffic is concerned, how 45 should the routers of an IP network behave whenever congestion is 46 experienced? 48 - How should a QoS policy be enforced to accurately reflect the fact 49 that some traffics deserve a better treatment than others, 50 according to the different levels of quality customers may 51 subscribe to? 53 - How should the switching and transmission resources of an IP 54 network be designed so that they actively participate in honoring 55 the commitments of a service provider towards its customers, as far 56 as the perception of the actual quality of the service by the end- 57 users is concerned? 59 - When considering the deployment of IP services worldwide, how an 60 end-to-end QoS policy could be enforced when considering that 61 multiple domains will be crossed by the traffic that characterizes 62 these QoS-based service offerings? 64 These questions yielded a dramatic development of the specification 65 effort ([3], [4]), as far as quality of service in IP networks is 66 concerned. 68 Nevertheless, providing end-to-end quality of service for the IP 69 traffic that crosses administrative domains still remains an issue, 70 mainly because: 72 - QoS policies may dramatically differ from one service provider to 73 another, 74 - The actual enforcement of a specific QoS policy may also differ 75 from one domain to another, although the definition of a set of 76 basic and common quality of service indicators may be shared 77 between the service providers. 79 This draft aims at providing an argumentation for the specification 80 and the development of QoS extensions to the BGP4 protocol, so that 81 it may participate in addressing the above-mentioned inter-domain 82 issues. 84 As such, this draft is organized according to the following sections: 86 - Section 3 aims at providing elaboration on the issues that may be 87 partially addressed by the use of the BGP4 protocol, as far as the 88 enforcement of an end-to-end QoS policy is concerned, 90 - Section 4 aims at describing what could be the framework related to 91 the definition and the specification of QoS extensions to the BGP4 92 protocol. 94 2. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC-2119 [5]. 100 3. Quality of service issues in deploying cross-domain IP services and 101 motivation for adding QoS extensions to the BGP4 protocol 103 The basic provisioning of an access to the Internet implies for 104 services providers that they establish BGP4 peering relationships 105 between themselves, so that their respective customers get the full 106 IP connectivity (i.e. communicate with the "outside" IP world). The 107 perceived quality of this kind of service by customers is often 108 qualified in terms of the variation of the response time that is 109 associated to a HTTP (HyperText Transfer Protocol) request or the 110 retrieval of a given file via the File Transfer Protocol (FTP) 111 related to the access to the Internet has yielded the promotion of a 112 spectrum of levels of service, often compared to the Olympic medal 113 taxonomy, so that gold customers are supposed to benefit from harder 114 guarantees than the bronze customers, in terms of packet loss rate 115 for example. 117 While this kind of QoS policy can be enforced by means of mechanisms 118 like those being specified in [6], and that will be activated on the 119 routers that are managed by a given service provider, there is 120 obviously no guarantees (for the customers) that other service 121 providers will enforce this QoS policy the same way, so that the 122 commitments both the customer and the service provider have 123 contractually agreed upon rely on local agreement considerations, 124 i.e. the configuration information that is processed by the routers 125 of a given domain only. 127 Furthermore, value-added IP service offerings like IP VPNs (IP 128 Virtual Private Networks) that may be deployed across several domains 129 (whatever the underlying technology) often imply the negotiation and 130 the invocation of QoS requirements (like the contractual definition 131 of a one-way metric delay, the inter-packet delay variation, etc.) 132 between the customer and the provider, although the latter is 133 generally unable to honor such commitments whenever they imply the 134 crossing of several domains. 136 According to these two examples, the QoS issues related to the 137 deployment of IP services over multiple domains can be summarized as 138 follows: 140 For the purpose of enforcing an end-to-end QoS policy (assuming 141 that "end-to-end" means that the corresponding IP traffic will 142 have to cross several domains), there is a strong need of service 143 providers to exchange (if not agree on the meaning of) QoS- 144 related information. 146 The QoS-related information can consist of (but is obviously not 147 limited to): 149 (1) Packet rate, i.e. the number of IP datagrams that can be 150 transmitted (or have been lost) per unit of time, 151 (2) One-way delay, as defined in [7], 152 (3) Inter-packet delay variation, as defined in [8], 153 (4) PHB Identifier, as defined in [9]. 155 It is assumed that these QoS metrics are systematically associated to 156 the routes that lead to the destination prefix indicated in the 157 header of the IP datagrams, so that service providers can fully 158 benefit from the meaning of such information, possibly yielding the 159 refinement of routing policies, for example. 161 This draft therefore assumes that IP routers could gracefully and 162 actively participate in the exchange of such information, since they 163 are one of the key components of the IP networks that support such 164 QoS-based IP service offerings. 166 4. A proposed framework for adding QoS extensions capabilities to the 167 BGP4 protocol 169 According to the above section, the use of the BGP4 protocol to 170 convey this QoS-related information between domains appears to be one 171 of the most natural choices, simply because of the systematic 172 activation of this routing protocol for the purpose of exchanging 173 reachability information between domains. 175 From this standpoint, the proposed framework of the corresponding 176 specification effort focuses on the use of the BGP4 attribute 177 machinery that has proven its great flexibility, and this proposal is 178 primarily reflected in the companion document [10] of this draft. 180 5. Security Considerations 182 The need for exchanging QoS-related information between domains 183 thanks to the use of the BGP4 protocol yields security concerns that 184 are related to the preservation of the confidentiality of this 185 information. Although this draft does not explicitly change the 186 underlying security issues inherent in the existing BGP-4 protocol 187 specification [11], the upcoming versions of this document will 188 provide additional elaboration on this issue. 190 6. References 192 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 193 9, RFC 2026, October 1996. 195 [2] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 196 1771, March 1995. 198 [3] Nichols K., Blake S., Baker F., Black D., "Definition of the 199 Differentiated Services Field (DS Field) in the IPv4 and IPv6 200 Headers", RFC 2474, December 1998. 202 [4] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G., 203 Egan R., Griffin D., Georgatsos P., Georgiadis L., 204 "Specification of a Service Level Specification (SLS) Template", 205 draft-tequila-sls-00.txt, Work in Progress, November 2000. Check 206 http://www.ist-tequila.org for additional information. 208 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 209 Levels", BCP 14, RFC 2119, March 1997 211 [6] Bernet Y. et al., "An Informal Management Model for Diffserv 212 Routers", draft-ietf-diffserv-model-06.txt, Work in Progress, 213 February 2001. 215 [7] Almes G., Kalidindi S., "A One-Way-Delay Metric for IPPM", RFC 216 2679, September 1999. 218 [8] Demichelis C., Chimento P., "IP Packet Delay Variation Metric 219 for IPPM", draft-ietf-ippm-ipdv-06.txt, Work in Progress, 220 February 2001. 222 [9] Black D., Brim S., Carpenter B., Le Faucheur F., "Per Hop 223 Behavior Identification Codes", draft-ietf-diffserv-2839bis- 224 01.txt, Work in Progress, February 2001. 226 [10] Jacquenet C., "Providing Quality of Service Indication by the 227 BGP-4 Protocol: the QOS_NLRI attribute", draft-jacquenet-qos- 228 nlri-02.txt, Work in Progress, February 2001. 230 [11] Heffernan A., "Protection of BGP sessions via the TCP MD5 231 Signature Option", RFC 2385, August 1998. 233 7. Acknowledgments 235 Part of this work is funded by the European Commission, within the 236 context of the TEQUILA (Traffic Engineering for Quality of Service in 237 the Internet At Large Scale, [12]) project, which is itself part of 238 the IST (Information Society Technologies) research program. 240 8. Author's Addresses 242 Christian Jacquenet 243 France Telecom R & D 244 DMI/SIR 245 42, rue des Coutures 246 BP6243 247 14066 Caen Cedex 04 248 France 249 Phone: +33 2 31 75 94 28 250 Email: christian.jacquenet@francetelecom.fr 252 9. Full Copyright Statement 254 "Copyright (C) The Internet Society (2001). All Rights Reserved. 256 This document and translations of it may be copied and furnished to 257 others, and derivative works that comment on or otherwise explain it 258 or assist its implementation may be prepared, copied, published and 259 distributed, in whole or in part, without restriction of any kind, 260 provided that the above copyright notice and this paragraph are 261 included on all such copies and derivative works. However, this 262 document itself may not be modified in any way, such as by removing 263 the copyright notice or references to the Internet Society or other 264 Internet organizations, except as needed for the purpose of 265 developing Internet standards in which case the procedures for 266 copyrights defined in the Internet Standards process must be 267 followed, or as required to translate it into languages other than 268 English. 270 The limited permissions granted above are perpetual and will not be 271 revoked by the Internet Society or its successors or assigns. 273 This document and the information contained herein is provided on an 274 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 275 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 276 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 277 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 278 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.