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

Versions: 00 01 02 03 04 05                                             
Internet Engineering Task Force                             C. Jacquenet
INTERNET-DRAFT                                      France Telecom R & D
Document: draft-jacquenet-qos-nlri-00.txt
Category: informational
Expires: January 2001

   Providing Quality of Service Indication by the BGP-4 Protocol: the
                           QOS_NLRI attribute

   1. Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 ([RFC-2026]).

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   2. Abstract

   For almost the last decade, value-added IP service offerings have
   been massively deployed over the Internet, thus yielding a dramatic
   development of the specification effort, as far as quality of
   service (QOS) in IP networks is concerned. Nevertheless, providing
   end-to-end quality of service by crossing administrative domains
   still remains an issue, mainly because:

   - quality of service policies may dramatically differ from one
   service provider to another;
   - the enforcement of a specific quality of service 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.

   As far as IP routing is concerned, the BGP-4 protocol (Border
   Gateway Protocol, version 4,[RFC-1771]) has been systematically
   activated between autonomous systems for the purpose of exchanging
   routing information related to the reachability of IP destination
   prefixes. From this standpoint, the BGP-4 protocol appears to be one
   of the key components for the enforcement of a global quality of
   service policy, by allowing BGP peers to indicate each other if (1)
                        The QOS_NLRI attribute               July 2000

   they have the ability to announce QOS-related information when
   transmitting UPDATE messages and (2) they have the ability to
   process such a QOS-related information when conveyed in an UPDATE
   The purpose of this draft consists in proposing an additional BGP4
   attribute, named the QOS_NLRI attribute, which aims at providing
   QOS-related information related to the NLRI information conveyed in
   a BGP UPDATE message.

   3. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC 2119 ([RFC-

   4. Introduction

   Providing end-to-end quality of service is probably one of the most
   important challenges of the Internet, not only because of the
   massive development of value-added IP service offerings, but also
   because of the various QOS policies that are currently deployed and
   enforced within an autonomous system, and which may well differ from
   one AS to another.

   Activate the BGP-4 protocol for exchanging reachability information
   between autonomous systems has been a must for many years, and, from
   this standpoint, the BGP-4 protocol appears to be a key component in
   the deployment of end-to-end QOS policies.

   Exchanging QOS-related information as well as reachability
   information in a given BGP UPDATE message might be helpful in
   enforcing an end-to-end QOS policy.

   This draft aims at specifying a new BGP-4 attribute, the QOS_NLRI
   attribute which will convey QOS-related information associated to
   the (possibly withdrawn) routes described in the NLRI (Network Layer
   Reachability Information) field of a BGP UPDATE message.

   5. The QOS_NLRI attribute (Type Code XY*)

   *: "XY" is subject to the IANA considerations section of this draft.

   This is an optional transitive attribute which can be used for the
   following purposes:

   (a) to advertise a QOS route to a peer. A QOS route is a route which
   meets one or a set of QOS requirements to reach a given (set of)
   destination prefixes. Such QOS requirements can be expressed in
   terms of minimum transit delay to reach a destination, maximum
   available bandwidth along the path to reach a destination, the
   identification of the traffic which is expected to use this specific
   route (identification means for such traffic include DSCP (DiffServ
   Code Point, [RFC-2475]) marking), etc., and they can be provided as
                        The QOS_NLRI attribute               July 2000

   an input for the route calculation process embedded in the BGP peers
   thanks to the activation of a signaling protocol, such as RSVP
   (Resource ReSerVation Protocol, [RFC-2205]);

   (b) to provide QOS information along with the NLRI information in a
   single BGP UPDATE message. It is assumed that this QOS information
   will be related to the route (or set of routes) described in the
   NLRI field of the BGP UPDATE message.
   The QOS_NLRI attribute is encoded as follows:

         | QOS Information Code (1 octet)                         |
         | QOS Information Sub-code (1 octet)                     |
         | QOS Information Value (2 octets)                        |
         | QOS Information Origin (1 octet)                        |
         | Network Address of Next Hop (1 octet)                  |
         | Network Layer Reachability Information (variable)       |

   The use and meaning of these fields are as follows:

   - QOS Information Code:

   This field carries the type of the QOS information. The following
   types have been identified so far:

   (0) Reserved
   (1) Bandwidth
   (2) Delay
   (3) Jitter
   (4) DSCP

   - QOS Information Sub-code:

   This field carries the sub-type of the QOS information. The
   following sub-types have been identified so far:

   (0) None (i.e. no sub-type, or sub-type unavailable, or unknown sub-
   (1) Reserved bandwidth
   (2) Available bandwidth
   (3) Minimum transit delay
   (4) Maximum transit delay
   (5) Average transit delay
   (6) AF (Assured Forwarding, [RFC-2597]) type

   The instantiation of this sub-code field MUST be compatible with the
   value conveyed in the QOS Information code field, as stated in the
                        The QOS_NLRI attribute               July 2000

   following table (the rows represent the QOS Information Code
   possible values, the columns represent the QOS Information Sub-code
   values identified so far, while the "X" sign indicates
         |    |  0 |  1 |  2 |  3 |  4 |  5 |  6 |
         |  0 |    |    |    |    |    |    |    |
         |  1 |    |    |    |  X |  X |  X |  X |
         |  2 |    |  X |  X |    |    |    |  X |
         |  3 |    |  X |  X |  X |  X |  X |  X |
         |  4 |    |  X |  X |  X |  X |  X |    |

   - QOS Information value:

   This field indicates the value of the QOS information. The
   corresponding units obviously depend on the instantiation of the QOS
   Information Code. Namely, if:

   (a) QOS Information Code field is "0", no unit specified,
   (b) QOS Information Code field is "1", unit is bits per second
   (c) QOS Information Code field is "2", unit is milliseconds,
   (d) QOS Information Code field is "3", unit is milliseconds,
   (e) QOS Information Code field is "4", no unit specified.

   - Network Address of Next Hop:

   A variable length field that contains the Network Address of the
   next router on the path to the destination prefix.

   - Network Layer Reachability Information:

   A variable length field that lists NLRI for the feasible routes that
   are being advertised in this attribute.

   The next hop information carried in the QOS_NLRI path attribute
   defines the Network Layer address of the border router that should
   be used as the next hop to the destinations listed in the QOS_NLRI
   attribute in the UPDATE message.  When advertising a QOS_NLRI
   attribute to an external peer, a router may use one of its own
   interface addresses in the next hop component of the attribute,
   provided the external peer to which the route is being advertised
   shares a common subnet with the next hop address.  This is known as
   a "first party" next hop.

   A BGP speaker can advertise to an external peer an interface of any
   internal peer router in the next hop component, provided the
   external peer to which the route is being advertised shares a common
                        The QOS_NLRI attribute               July 2000

   subnet with the next hop address.  This is known as a "third party"
   next hop information.

   A BGP speaker can advertise any external peer router in the next hop
   component, provided that the Network Layer address of this border
   router was learned from an external peer, and the external peer to
   which the route is being advertised shares a common subnet with the
   next hop address.  This is a second form of "third party" next hop
   Normally the next hop information is chosen such that the shortest
   available path will be taken.  A BGP speaker must be able to support
   disabling advertisement of third party next hop information to
   handle imperfectly bridged media or for reasons of policy.

   A BGP speaker must never advertise an address of a peer to that peer
   as a next hop, for a route that the speaker is originating.  A BGP
   speaker must never install a route with itself as the next hop.
   When a BGP speaker advertises the route to an internal peer, the
   advertising speaker should not modify the next hop information
   associated with the route.  When a BGP speaker receives the route
   via an internal link, it may forward packets to the next hop address
   if the address contained in the attribute is on a common subnet with
   the local and remote BGP speakers.

   A BGP UPDATE message that carries the QOS_NLRI MUST also carry the
   ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP
   exchanges). Moreover, in IBGP exchanges such a message MUST also
   carry the LOCAL_PREF attribute. If such a message is received from
   an external peer, the local system shall check whether the leftmost
   AS in the AS_PATH attribute is equal to the autonomous system number
   of the peer than sent the message. If that is not the case, the
   local system shall send the NOTIFICATION message with Error Code
   UPDATE Message Error, and the Error Subcode set to Malformed

   An UPDATE message that carries no NLRI, other than the one encoded
   in the QOS_NLRI attribute, should not carry the NEXT_HOP attribute.
   If such a message contains the NEXT_HOP attribute, the BGP speaker
   that receives the message should ignore this attribute.

   6. Use of Capabilities Advertisement with BGP-4

   A BGP speaker that uses the QOS_NLRI attribute SHOULD use the
   Capabilities Advertisement procedures, as defined in [RFC-2842], so
   that it might be able to determine if it can use such an attribute
   with a particular peer.

   The fields in the Capabilities Optional Parameter are defined as

   - The Capability Code field is set to N (127 < N < 256, when
   considering the "Private Use" range, as specified in [RFC-2434]),
   while the Capability Length field is set to "1".
                        The QOS_NLRI attribute               July 2000

   - The Capability Value field is a one-octet field, encoded the same
   way as the QOS Information Code field of the QOS_NLRI attribute.

   7. IANA Considerations

   Section 5 of this draft documents an optional transitive BGP-4
   attribute named "QOS_NLRI" whose type value will be assigned by
   IANA. To be completed.

   8. Security considerations

   This additional BGP-4 attribute specification does not change the
   underlying security issues inherent in the existing BGP-4 protocol
   specification [RFC-2385].
   9. References

   [RFC-1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.
   [RFC-2026] Bradner, S., "The Internet Standards Process --
              Revision 3", BCP 9, RFC 2026, October 1996.
   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997
   [RFC-2205] R. braden et al., "Resource ReSerVation Protocol
              (RSVP) - Version 1 Functional Specification", RFC
              2205, September 1997.
   [RFC-2385] A. Heffernan, "Protection of BGP sessions via the
              TCP MD5 Signature   Option", RFC 2385, August 1998.
   [RFC-2434] T. Narten, H. Alvestrand, "Guidelines for Writing
              an IANA Considerations Section in RFCs", RFC 2434,
              October 1998.
   [RFC-2475] S. Blake et al., "An Architecture for
              Differentiated Services", RFC 2475, December 1998.
   [RFC-2597] J. Heinanen et al., " Assured Forwarding PHB
              Group", RFC 2597, June 1999.
   [RFC-2842] R. Chandra, J. Scudder, "Capabilities Advertisement
              with BGP-4", RFC 2842, May 2000.

   10. Author's address

   Christian Jacquenet
   France Telecom R & D
   42, rue des Coutures
   BP 6243
   14066 Caen cedex 04
   Phone : + 33 2 31 75 94 28
   Fax   : + 33 2 31 73 56 26
   Email : christian.jacquenet@francetelecom.fr

   11. Full copyright statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.
                        The QOS_NLRI attribute               July 2000

   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

   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