[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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
                   <draft-jacquenet-qos-ext-bgp-00.txt>


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]