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,
<Lastname> 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]