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

Versions: 00 01 02 03 04 05                                             
               Network Working Group                                       C. Jacquenet
               Internet Draft                                        France Telecom R&D
               Document: draft-jacquenet-qos-nlri-01.txt                  November 2000
               Category: Experimental
               Expires: May 2001
                  Providing Quality of Service Indication by the BGP-4 Protocol: the
                                          QOS_NLRI attribute
               Status of this Memo
                  This document is an Internet-Draft and is in full conformance with
                  all provisions of Section 10 of RFC 2026 [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
                  The list of Internet-Draft Shadow Directories can be accessed at
                  This draft specifies an additional BGP4 (Border Gateway Protocol,
                  version 4, [2]) attribute, named the "QOS_NLRI" attribute, which aims
                  at providing QoS (Quality of Service)-related information associated
                  to the NLRI information conveyed in a BGP UPDATE message.
               1. 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
                  (Autonomous System) to another.
                  For almost the last decade, value-added IP service offerings have
                  been deployed over the Internet, thus yielding a dramatic development
                  of the specification effort, as far as quality of service in IP
               Jacquenet           Experimental - Expires May 2001            [Page 1]

               Internet Draft        The QOS_NLRI BGP4 attribute             Nov. 2000
                  networks is concerned. Nevertheless, providing end-to-end quality of
                  service by crossing administrative domains still remains an issue,
                  mainly because:
                  - QoS policies may dramatically differ from one service provider to
                  - The 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.
                  Activate the BGP4 protocol for exchanging reachability information
                  between autonomous systems has been a must for many years, and, from
                  this standpoint, the BGP4 protocol is one of the key components for
                  the enforcement of end-to-end QoS policies.
                  Therefore, exchanging QoS-related information as well as reachability
                  information in a given BGP UPDATE message appears to be helpful in
                  enforcing an end-to-end QoS policy.
                  This draft aims at specifying a new BGP4 attribute, the QOS_NLRI
                  attribute, that will convey QoS-related information associated to
                  the routes described in the corresponding NLRI (Network Layer
                  Reachability Information) field of a BGP UPDATE message.
                  This document is organized into the following sections:
                  - Section 3 identifies the changes that have been made in the
                    document since the last version,
                  - Section 4 describes the attribute and its mode of operation,
                  - Section 5 elaborates on the use of the capabilities advertisement
                    feature of the BGP4 protocol,
                  - Finally, sections 6 and 7 introduce IANA and some security
                    considerations, respectively.
               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 [3].
               3. Changes since the last version of this draft
                  The current version of this draft reflects the following changes:
                  - Re-wording of the Abstract section (summarized),
                  - Re-wording of the Introduction section (section 1),
                  - Insertion of the <AFI, SAFI> information in the QOS_NLRI attribute
                    (section 4),
               Jacquenet           Experimental - Expires May 2001            [Page 2]

               Internet Draft        The QOS_NLRI BGP4 attribute             Nov. 2000
                  - Insertion of an acknowledgements section (section ,
                  - Revision of the
                  - Correction of remaining typos.
               4. The QOS_NLRI attribute (Type Code XY*)
                  (*): "XY" is subject to the IANA considerations section of this
                  This is an optional transitive attribute that can be used for the
                  following purposes:
                  (a) To advertise a QoS route to a peer. A QoS route is a route that
                      meets one or a set of QoS requirement(s) to reach a given (set
                      of) destination prefixes (see [4], for example). 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, and/or the identification of the
                      traffic that is expected to use this specific route
                      (identification means for such traffic include DSCP (DiffServ
                      Code Point, [5]) marking). These QoS requirements can be used as
                      an input for the route calculation process embedded in the BGP
                      peers, e.g. thanks to the activation of a signaling protocol,
                      such as RSVP (Resource ReSerVation Protocol, [6]),
                  (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.
                  This draft makes no specific assumption about the means to actually
                  value this attribute, since this is mostly a matter of
                  implementation, but the reader is kindly suggested to have a look on
                  the [7], as an example of a means to feed the BGP peer with the
                  appropriate information.
                  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)                        |
                           | Address Family Identifier (2 octets)                    |
                           | Subsequent Address Family Identifier (1 octet)          |
               Jacquenet           Experimental - Expires May 2001            [Page 3]

               Internet Draft        The QOS_NLRI BGP4 attribute             Nov. 2000
                           | Network Address of Next Hop (1 octet)                   |
                           | Network Layer Reachability Information (variable)       |
                  The use and meaning of the fields of the QOS_NLRI attribute are
                  defined 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, [8]) 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
                  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 incompatibility).
                           |    |  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 |    |
               Jacquenet           Experimental - Expires May 2001            [Page 4]

               Internet Draft        The QOS_NLRI BGP4 attribute             Nov. 2000
                  - 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 (bps),
                  (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.
                  - Address Family Identifier (AFI):
                   This field carries the identity of the Network Layer protocol
                    associated with the Network Address that follows. Presently defined
                    values for this field are specified in [9] (see the Address Family
                    Numbers section of this reference document).
                  - Subsequent Address Family Identifier (SAFI):
                    This field provides additional information about the type of the
                    Network Layer Reachability Information carried in the QOS_NLRI
                  - 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, given 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.
               Jacquenet           Experimental - Expires May 2001            [Page 5]

               Internet Draft        The QOS_NLRI BGP4 attribute             Nov. 2000
                  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    subnet
                  with the next hop address.  This is known as a "third party" next hop
                  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 AS_PATH.
                  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.
               5. 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 [10], so that it
                  might be able to determine if it can use such an attribute with a
                  particular peer.
               Jacquenet           Experimental - Expires May 2001            [Page 6]

               Internet Draft        The QOS_NLRI BGP4 attribute             Nov. 2000
                  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 [11]), while
                    the Capability Length field is set to "1".
                  - The Capability Value field is a one-octet field, encoded the same
                    way as the QOS Information Code field of the QOS_NLRI attribute.
               6. 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.
               7. Security Considerations
                  This additional BGP-4 attribute specification does not change the
                  underlying security issues inherent in the existing BGP-4 protocol
                  specification [12].
               8. 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.
                  [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
                       Levels", BCP 14, RFC 2119, March 1997.
                  [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]  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.
                  [6]  Braden R. et al., "Resource ReSerVation Protocol (RSVP)- Version
                       1 Functional Specification", RFC 2205, September 1997.
                  [7] Jacquenet C., "A COPS client-type for IP traffic engineering",
                       draft-jacquenet-ip-te-cops-00.txt, Work in Progress, November
                  [8]  Heinanen J. et al., " Assured Forwarding PHB Group", RFC 2597,
                       June 1999.
               Jacquenet           Experimental - Expires May 2001            [Page 7]

               Internet Draft        The QOS_NLRI BGP4 attribute             Nov. 2000
                  [9]  Reynolds J., Postel J., "ASSIGNED NUMBERS", RFC 1700, October
                  [10]         R. Chandra, J. Scudder, "Capabilities Advertisement with
                       BGP-4", RFC 2842, May 2000.
                  [11] Narten T., Alvestrand H., "Guidelines for Writing an IANA
                       Considerations Section in RFCs", RFC 2434, October 1998.
                  [12] Heffernan A., "Protection of BGP sessions via the TCP MD5
                       Signature Option", RFC 2385, August 1998.
               9. 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, [4]) project, which is itself part of
                  the IST (Information Society Technologies) research program.
                  The author would also like to thank all the partners of the TEQUILA
                  project for the fruitful discussions that have been conducted within
                  the context of the traffic engineering specification effort of the
               10. Author's Addresses
                  Christian Jacquenet
                  France Telecom R & D
                  42, rue des Coutures
                  BP 6243
                  14066 CAEN Cedex 04
                  Phone: +33 2 31 75 94 28
                  Email: christian.jacquenet@francetelecom.fr
               11. Full Copyright Statement
                  Copyright(C) The Internet Society (2000). 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
               Jacquenet           Experimental - Expires May 2001            [Page 8]

               Internet Draft        The QOS_NLRI BGP4 attribute             Nov. 2000
                  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
               Jacquenet           Experimental - Expires May 2001            [Page 9]