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

Versions: 00                                                            
Network Working Group                                       C. Jacquenet
Internet Draft                                            France Telecom
Document: draft-jacquenet-cops-te-00.txt                   February 2004
Category: Experimental
Expires August 2004


               A COPS Client-Type for Traffic Engineering
                    <draft-jacquenet-cops-te-00.txt>


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
   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 specifies a COPS (Common Open Policy Service) client-type
   designed for the enforcement of IP Routing and Traffic Engineering
   (TE) policies. The usage of this TE COPS client-type relies upon the
   activation of the COPS protocol for policy provisioning purposes.

Table of Contents

   1.      Introduction...............................................2
   2.      Conventions used in this Document..........................3
   3.      Terminology Considerations.................................3
   4.      The Generic Model of an IP Routing/TE Policy
             Enforcement Scheme.......................................4
   5.      TE Client-Type Specific Information to be Carried in
             COPS Messages............................................6
   5.1.    Client-Type Field of the Common Header of Every COPS
             Message..................................................7
   5.2.    COPS Message Content.......................................7
   5.2.1.  Request Messages (REQ).....................................7
   5.2.2.  Decision Messages (DEC)....................................8

Jacquenet          Experimental - Expires August 2004           [Page 1]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


   5.2.3.  Report Messages (RPT)......................................8
   5.3.    Backward Compatibility Issues..............................9
   6.      COPS-PR Usage of the TE Client-Type.......................10
   7.      IANA Considerations.......................................11
   8.      Security Considerations...................................11
   9.      References................................................11
   10.     Acknowledgments...........................................12
   11.     Author's Address..........................................12
   12.     Full Copyright Statement..................................13

1.   Introduction

   The deployment of value-added IP services over the Internet has
   become one of the most competing challenges for service providers, as
   well as a complex technical issue, from a (dynamic) resource
   provisioning perspective.

   To address such technical issue, the COPS protocol ([2]) and its
   usage for the support of Policy Provisioning ([3]) is one of the
   specification efforts of the Resource Allocation Protocol (rap)
   Working Group of the IETF that should help service providers by
   introducing a high level of automation for the dynamic production of
   a wide range of services and policies.

   Such policies include routing and traffic engineering policies. They
   aim at appropriately provisioning, allocating/de-allocating, and
   using the switching and the transmission resources of an IP network
   (i.e. the routers and the links that connect these routers,
   respectively), according to a set of constraints like Quality of
   Service (QoS) requirements (e.g. rate, one-way delay, inter-packet
   delay variation, etc.) that have been possibly negotiated between the
   customers and the service providers, as well as routing metrics,
   which can reflect the network conditions.

   Within the scope of this document, the actual enforcement of IP
   routing and traffic engineering policies is primarily based upon the
   activation of both intra- and inter-domain routing protocols (e.g.
   [4], [5], not to mention the use of multicast routing protocols [6])
   that will be activated in the network to appropriately select,
   install, maintain and possibly withdraw routes that will comply with
   the aforementioned QoS requirements and/or specific routing
   constraints, depending on the type of traffic that will be conveyed
   along these routes.

   It is therefore necessary to provide the route selection processes
   with the information that will depict the routing policies that are
   to be enforced within a domain, including the aforementioned
   constraints and metrics, given the dynamic routing protocols actually
   support traffic engineering capabilities for the calculation and the
   selection of such routes.



Jacquenet          Experimental - Expires August 2004           [Page 2]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


   These capabilities are currently being specified in [7] and [8] for
   the OSPF (Open Shortest Path First) and the IS-IS (Intermediate
   System to Intermediate System routing protocol, [9]) interior routing
   protocols respectively, while there is an equivalent specification
   effort for the BGP4 (Border Gateway Protocol, version 4) protocol, as
   described in [10], for example.

   To provide the routers that will participate in the dynamic
   enforcement of an IP routing and/or traffic engineering policy with
   the appropriate configuration information (such as metrics' values),
   one possibility is to use the COPS protocol and its usage for policy
   provisioning. To do so, a new COPS client-type is specified, called
   the "Traffic Engineering" client-type, and this specification effort
   is the purpose of this draft.

   This document is organized into the following sections:

   - Section 3 introduces terminology as well as basic assumptions,
   - Section 4 introduces the generic architecture,
   - Section 5 defines the contents of the COPS messages that MUST
      include the TE client-type specific information,
   - Section 6 defines the usage of the TE client-type, including its
      mode of operation with the PDP (Policy Decision Point, [11]) with
      whom a COPS communication has been established,
   - Finally, sections 7 and 8 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 [12].

3.   Terminology Considerations

   The enforcement of an IP routing/TE policy is based upon the
   processing of configuration information that reflects the
   characteristics of these policies (IGP metric values, BGP attributes'
   values, QoS requirements and/or constraints, etc.).

   This information is called the "QoS-related" information within the
   context of this draft.

   Then, this QoS-related information must be taken into account by the
   routing processes that will participate in the calculation, the
   selection, the installation and the maintenance of the routes that
   will comply with the aforementioned requirements. The algorithms
   invoked by the routing processes take into account the cost metrics
   (whose corresponding values can possibly be inferred by a DSCP
   (DiffServ Code Point, [13]) value) that have been assigned by the
   network administrators.


Jacquenet          Experimental - Expires August 2004           [Page 3]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


   This metric-related information is called the "TE"-related
   information within the context of this draft.

   Thus, this draft makes a distinction between QoS-related information
   and TE-related information, where:

   - QoS-related information is negotiated between customers and
      service providers,

   - TE-related configuration information is dynamically provided to
      routers, and is exchanged between routers so that they can
      compute, select, install, and maintain the (traffic-engineered)
      routes accordingly.

   From this perspective, QoS-related information provides information
   on the traffic (both unicast and multicast) to be forwarded in the
   network (such as source address, destination address, protocol
   identification, DSCP marking, etc.), whereas TE-related information
   provides information for the routing processes that will indicate the
   routers of the network how to forward the aforementioned traffic,
   i.e. compute and select the routes that will convey such traffic.

   Given these basic assumptions, this draft aims at specifying a COPS-
   based TE client-type that has the following characteristics:

   - The TE client-type is supported by the PEP (Policy Enforcement
      Point) capability that allows a router to enforce a collection of
      policies, thanks to a COPS communication that has been established
      between the PEP and the PDP,

   - The actual enforcement of an IP routing/TE policy is based upon
      the TE-related configuration information that will be exchanged
      between the PDP and the PEP, and that will be used by the router
      for selecting, installing, maintaining and possibly withdrawing IP
      TE routes.

4.   The Generic Model of an IP Routing/TE Policy Enforcement Scheme

   The use of the COPS protocol for dynamically enforcing an IP
   routing/TE policy yields the generic model depicted in figure 1.













Jacquenet          Experimental - Expires August 2004           [Page 4]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


             +----------------+
             |                |
             |    IP Router   |
             |                |
             |     +-----+    |   COPS-PR     +-----+    +-----------+
             |     | PEP |<---|-------------->| PDP |<-->| IP TE PIB |
             |     +-----+    |               +-----+    +-----------+
             |        |       |
             |        |       |
             |     +-----+    |
             |     | LPDP|    |
             |     +-----+    |
             |        |       |
             |        |       |
             |    /-------\   |
             |    |       |   |
             | +-----+ +-----+|
             | | RIB |.| RIB ||
             | +-----+ +-----+|
             |    |       |   |
             |    |       |   |
             |    \-------/   |
             |        |       |
             |     +-----+    |
             |     | FIB |    |
             |     +-----+    |
             +----------------+

      Figure 1: Generic model of an IP routing/TE policy enforcement
                                  scheme.

   As depicted in figure 1, the routers embed the following components:

   - A PEP capability, which supports the TE client-type. The support
      of the TE client-type is notified by the PEP to the PDP, and is
      unique for the area covered by the IP routing/traffic engineering
      policy, so that the PEP can treat all the COPS client-types it
      supports as non-overlapping and independent namespaces,

   - A Local Policy Decision Point (LPDP), which can be somewhat
      compared to the routing processes that have been activated in the
      router. The LPDP will therefore contribute to the computation and
      the selection of the IP routes (see section 6 of this draft),

   - Several instances of Routing Information Bases (RIB), according to
      the different (unicast and multicast) routing processes that have
      been activated - one can easily assume the activation of at least
      one IGP (Interior Gateway Protocol, like OSPF) and BGP4,

   - Conceptually one Forwarding Information Base (FIB), which will
      store the routes that have been selected by the routing processes,
      but this draft makes no assumption about the number of FIBs that

Jacquenet          Experimental - Expires August 2004           [Page 5]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


      can be supported by a router (e.g. within the context of an IP VPN
      (Virtual Private Network) service offering).

   As suggested in [14], the enforcement of an IP routing/traffic
   engineering policy is based upon the use of a policy server (the PDP
   in the above figure) that sends IP TE-related information towards the
   PEP capability embedded in the IP router.

   The TE-related information is stored and maintained in an TE Policy
   Information Base ([15]), which will be accessed by the PDP to
   retrieve and update the TE-related information whenever necessary
   (see section 6 of this draft).

   Also, this TE-related information is conveyed between the PDP and the
   PEP thanks to the establishment of a COPS-PR connection between these
   two entities. The COPS-PR protocol assumes a named data structure
   (the PIB), so as to identify the type and purpose of the policy
   information that is sent by the PDP to the PEP for the provisioning
   of a given policy.

   Within the context of this draft, the data structure of the PIB
   refers to the IP routing/TE policy that is described in the PIB as a
   collection of PRovisioning Classes (PRC). Furthermore, these classes
   contain attributes that actually describe the TE-related policy
   provisioning data that will be sent by the PDP to the PEP. Some of
   these attributes consist of the link and traffic engineering metrics
   that will be manipulated by the routing processes being activated in
   the routers to compute the IP routes.

   The TE classes are instantiated as multiple PRI (PRovisioning
   Instance) instances, each of which being identified by PRovisioning
   Instance iDentifier (PRID). A given PRI specifies the data content
   carried in the TE client specific objects. A TE PRI typically
   contains a value for each attribute that has been defined for the TE
   PRC.

   Currently, the TE PIB has identified a per-DSCP TE PRC instantiation
   scheme, because the DSCP value conveyed in each IP datagram that will
   be processed by the routers privileges the notion of "DSCP-based"
   routing. Such a routing scheme aims at reflecting the IP routing/TE
   policies that have been defined by a service provider, assuming a
   restricted number of DSCP-identified classes of service that will
   service the customers' requirements.

5.   TE Client-Type Specific Information to be Carried in COPS Messages

   This section describes the formalism that is specific to the use of a
   TE client-type, given that only the COPS messages that require a TE
   client-type specific definition are described in this section, i.e.
   the other COPS messages to be exchanged between a PEP that supports
   the TE client-type and a PDP, and which do not need to carry TE


Jacquenet          Experimental - Expires August 2004           [Page 6]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


   client-type specific information, are those described in the
   corresponding [2] and [3] documents, without any further elaboration.

   It must be noted that, whatever the contents of the COPS messages
   that MAY be exchanged between the PEP supporting the TE client-type
   and the PDP, the actual calculation, selection, installation,
   maintenance and possible withdrawal of IP routes in the router's FIB
   is left to the routers.

   Nevertheless, the information contained in the router's FIB MUST be
   consistent with the information contained in the TE PIB: this is done
   thanks to the synchronization features of the COPS architecture, as
   defined in [2].

5.1.     Client-Type Field of the Common Header of Every COPS Message

   All of the TE client-type COPS messages MUST contain the COPS Common
   Header with the 2-byte encoded Client-Type field valued with the yet-
   to-be assigned IANA number (see section 7 of this draft) for the TE
   client-type.

5.2.     COPS Message Content

5.2.1.       Request Messages (REQ)

   The REQ message is sent by the TE client-type to issue a
   configuration request to the PDP, as specified in the COPS Context
   Object. The REQ message includes the current configuration
   information related to the enforcement of an IP routing/TE policy.
   Such configuration information is encoded according to the ClientSI
   format that is defined for the Named ClientSI object of the REQ
   message.

   The configuration information is encoded as a collection of bindings
   that associate a PRID object and an Encoded Provisioning Instance
   Data (EPD).

   Such information MAY consist of:

   - The identification information of the router, e.g. the
      identification information that is conveyed in OSPF LSA (Link
      State Advertisement) Type 1 messages. The use of a loopback
      interface's IP address is highly recommended for the instantiation
      of the corresponding EPD,

   - The link metric values that have been currently assigned to each
      (physical/logical) interface of the router, as described in [4]
      for example. Such values MAY vary with an associated DSCP value,
      i.e. the link metric assigned to an interface is a function of the
      DSCP value encoded in each IP datagram that this router may have
      to forward,


Jacquenet          Experimental - Expires August 2004           [Page 7]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


   - The traffic engineering metric values that specify the link metric
      values for traffic engineering purposes, as defined in [7], for
      example. These values MAY be different from the above-mentioned
      link metric values and they MAY also vary according to DSCP
      values.

5.2.2.       Decision Messages (DEC)

   The DEC messages are used by the PDP to send TE policy provisioning
   data to the TE client-type. DEC messages are sent in response to a
   REQ message received from the PEP, or they can be unsolicited, e.g.
   subsequent DEC messages can be sent at any time after, to supply the
   PEP with additional or updated TE policy configuration information
   without the solicited message flag set in the COPS message header,
   since such messages correspond to unsolicited decisions.

   DEC messages typically consist of "install" and/or "remove"
   decisions, and, when there is no Decision Flags set, the DEC message
   includes the Named Decision Data (Provisioning) object.

   Apart from the aforementioned identification information, and
   according to the kind of (PRID, EPD) bindings that MAY be processed
   by the PEP (see section 5.2.1. of the draft), DEC messages MAY refer
   to the following decision examples:

   - Assign new link/traffic engineering metric values each time a new
      interface is installed/created on the router. These new values
      will obviously yield the generation of LSA messages in the case of
      the activation of the OSPF protocol, and/or the generation of BGP4
      UPDATE messages (e.g. in the case of a new instantiation of the
      MULTI_EXIT_DISC (MED) attribute). This will in turn yield the
      computation of (new) IP routes that MAY be installed in the
      router's FIB,

   - Modify previously assigned metric values, thanks to a
      remove/install decision procedure (this may yield a modification
      of the router's FIB as well, obviously),

   - Remove assigned metric values, e.g. the corresponding interfaces
      may not be taken into consideration by the routing algorithms
      anymore (or during a specific period of time, e.g. for maintenance
      purposes).

5.2.3.       Report Messages (RPT)

   The Report message allows the PEP to notify the PDP with a particular
   set of IP routing/TE policy provisioning instances that have been
   successfully or unsuccessfully installed/removed.

   When the PEP receives a DEC message from the PDP, it MUST send back a
   RPT message towards the PDP. The RPT message will contain one of the
   following Report-Types:

Jacquenet          Experimental - Expires August 2004           [Page 8]


Internet Draft     COPS Usage for Traffic Engineering      February 2004



   "Failure":    Notification of errors that occurred during the
                 processing of the (PRID, EPD) bindings contained in
                 the DEC message. Such a notification procedure can
                 include a failure report in assigning an updated value
                 of a given metric for example,

   "Success":    Notification of successful assignment of metric
                 values, and/or successful installation of IP routes in
                 the router's FIB. From this perspective, there MAY be
                 routes that will be installed in the router's FIB
                 without any explicit decision sent by the PDP to the
                 PEP regarding the calculation/installation of the
                 aforementioned route. This typically reflects a normal
                 dynamic routing procedure, whenever route
                 advertisement messages are received by the router,
                 including messages related to a topology change. In
                 any case (i.e. whatever the effect that yielded the
                 installation of a route in the router's FIB), a RPT
                 message MUST be sent by the PEP towards the PDP to
                 notify such an event, so that the TE PIB will be
                 updated by the PDP accordingly.

   "Accounting": The accounting RPT message will carry statistical
                 information related to the traffic that will transit
                 through the router. This statistical information MAY
                 be used by the PDP to possibly modify the metric
                 values that have been assigned when thresholds have
                 been crossed: for example, if the RPT message reports
                 that x % of the available rate associated to a given
                 interface have been reached, then the PDP MAY send an
                 unsolicited DEC message in return, so that potential
                 bottlenecks be avoided.

5.3.     Backward Compatibility Issues

   In the case where the IP network is composed of COPS-aware routers
   (which embed a PEP capability that supports the TE client-type), as
   well as COPS-unaware routers, the activation of a link state routing
   protocol (like OSPF) together with the reporting mechanism that has
   been described in section 5.2. of this draft addresses the backward
   compatibility issue.

   Indeed, the flooding mechanism that is used by the OSPF protocol for
   the propagation of the LSA messages assumes that, in particular, the
   COPS-aware routers will receive these update messages. Upon receipt
   of such messages, the PEP will have the ability to notify the PDP
   with the corresponding changes (e.g. by using a "Success" report-type
   that will reflect the installation of new routes in the router's
   FIB), so that the TE PIB can be updated accordingly.



Jacquenet          Experimental - Expires August 2004           [Page 9]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


   The same observation can be made within the context of the activation
   of the BGP4 protocol, because of the iBGP full-mesh topology that is
   required to allow the routers of a given domain to get a homogeneous
   view of the "outside" world.

6.   COPS-PR Usage of the TE Client-Type

   After having opened a COPS connection with the PDP, the PEP sends a
   REQ message towards the PDP that will contain a Client Handle. The
   Client Handle is used to identify a specific request state associated
   to the TE client-type supported by the PEP. The REQ message will
   contain a "Configuration Request" context object.

   This REQ message will also carry the named client specific
   information (including the (default) configuration information), as
   described in section 5.2.1.of the draft. Default configuration
   information includes the information available during the bootstrap
   procedures of the routers.

   The routes that have been installed in the router's FIB MAY be
   conveyed in specific (PRID, EPD) bindings in the REQ message as well.

   Upon receipt of the REQ message, the PDP will send back a DEC message
   towards the PEP. This DEC message will carry TE Named Decision Data
   object that will convey all the appropriate installation/removal of
   (PRID, EPD), as described in section 5.2.2 of this draft. One of the
   basic goals of this named Decision objects consists in making the
   routers enforce a given IP routing/TE policy.

   Upon receipt of a DEC message, the TE-capable PEP will (try to) apply
   the corresponding decisions, by making the network device (and its
   associated implementation-specific Command Line Interface, if
   necessary) install the named TE policy data (e.g. assign a metric
   value to a recently-installed interface).

   Then, the PEP will notify the PDP about the actual enforcement of the
   named TE policy decision data, by sending the appropriate RPT message
   back to the PDP. Depending on the report-type that will be carried in
   the RPT message, the contents of the message MAY include:

   - Successfully/unsuccessfully assigned new/updated metric values,

   - Successfully installed routes from the router's FIB. Note that the
      notion of "unsuccessfully installed routes" is meaningless,

   - Successfully/unsuccessfully withdrawn routes from the router's
      FIB. Route withdrawal is not only subject to the normal IGP and
      BGP4 procedures (thus yielding the generation of the corresponding
      advertisement messages), but also subject to named TE policy
      decision data (carried in a specific DEC message), like those data
      related to the lifetime of a service.


Jacquenet          Experimental - Expires August 2004          [Page 10]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


   The RPT message MAY also carry the "Accounting" report-type, as
   described in section 5.2.3.of this draft.

7.   IANA Considerations

   Section 5.1 of this draft has identified the need for the assignment
   of a specific number that will uniquely identify the TE client-type
   in every COPS message to be exchanged between a PEP and a PDP.

   This value SHOULD be chosen in the range of 0x8000 - 0xFFFF,according
   to a First Come First Served policy, as mentioned in both [2] and
   [16].

8.   Security Considerations

   This draft specifies a new client-type that will make use of the COPS
   protocol for the provisioning and the enforcement of IP routing/TE
   policies. As such, it introduces no new security issues over the COPS
   protocol itself, or its usage for policy provisioning.

   Nevertheless, it is recommended that the TE client-type
   systematically uses the Message Integrity Object (Integrity) for the
   authentication and the validation of every COPS message it may
   exchange with the PDP with whom it has established a COPS
   communication. The Message Integrity Object also prevents from replay
   attacks.

   In addition, the IP Security ([17]) protocol suite may be activated,
   and the IPSec Authentication Header (AH) should be used for the
   validation of the COPS connection, while the Encapsulated Security
   Payload (ESP) may be used to provide both validation and secrecy, as
   stated in [2].

9.   References

   [1]  Bradner, S.,"The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.
   [2]  Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja R., Sastry
      A., "The COPS (Common Open Policy Service) Protocol", RFC 2748,
      January 2000.
   [3]  Ho Chan, K., Durham, D., Gai, S., Herzog, S., McLoghrie, K.,
      Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., "COPS Usage
      for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
   [4]  Moy, J.,"OSPF Version 2", RFC 2328, April 1998.
   [5]  Rekhter, Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC
      1771, March 1995.
   [6]  Jacquenet, C., Proust, C., "An Introduction to IP Multicast
      Traffic Engineering", Proceedings of the ECUMN 2002 conference.
      See http://iutsun1.colmar.uha.fr/ECUMN02.html for further details.
   [7]  Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
      Extensions to OSPF", RFC 3630, September 2003.


Jacquenet          Experimental - Expires August 2004          [Page 11]


Internet Draft     COPS Usage for Traffic Engineering      February 2004



   [8]  Smit, H., Li T., "IS-IS Extensions for Traffic Engineering",
      draft-ietf-isis-traffic-05.txt, Work in Progress, August 2003.
   [9]  ISO/IEC 10589, "Intermediate System to Intermediate System,
      Intra-Domain Routing Exchange Protocol for use in Conjunction with
      the Protocol for Providing the Connectionless-mode Network Service
      (ISO 8473)", June 1992.
   [10] Jacquenet, C., Cristallo, G., "The BGP QOS_NLRI Attribute",
      draft-jacquenet-bgp-qos-00.txt, Work in Progress, February 2004.
   [11] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for
      Policy-Based Admission Control", RFC 2753, January 2000.
   [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
   [13] 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.
   [14] Apostopoulos G., Guerin R., Kamat S., Tripathi S. K., "Server
      Based QOS Routing", Proceedings of the 1999 GLOBCOMM Conference.
   [15] Boucadair, M., Jacquenet, C., "An IP Forwarding Policy
      Information Base", draft-jacquenet-fwd-pib-00.txt, Work in
      Progress, February 2004.
   [16] Alvestrand H., Narten T., "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
   [17] Atkinson R., "Security Architecture for the Internet Protocol",
      RFC 2401, August 1998.

10.    Acknowledgments

   Part of this work is funded by the European Commission, within the
   context of the MESCAL (Management of End-to-End Quality of Service
   Across the Internet At Large, http://www.mescal.org) 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 MESCAL
   project for the fruitful discussions that have been conducted so far
   within the context of the traffic engineering specification effort of
   the project, as well as MM. Boucadair and Brunner for their valuable
   input.

11.    Author's Address

   Christian Jacquenet
   France Telecom
   3, avenue Fran‡ois Ch‚teau
   CS 36901
   35069 Rennes CEDEX
   France
   Phone: +33 2 99 87 63 31
   Email: christian.jacquenet@francetelecom.com



Jacquenet          Experimental - Expires August 2004          [Page 12]


Internet Draft     COPS Usage for Traffic Engineering      February 2004


12.    Full Copyright Statement

   Copyright(C) The Internet Society (2004). 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          Experimental - Expires August 2004          [Page 13]


Network Working Group                                       M. Boucadair
Internet Draft                                              C. Jacquenet
Document: draft-jacquenet-fwd-pib-00.txt                  France Telecom
Category: Experimental                                     February 2004
Expires August 2004


                An IP Forwarding Policy Information Base
                     <draft-jacquenet-fwd-pib-00.txt>


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
   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 specifies a set of Policy Rule Classes (PRC) for the
   enforcement of an IP forwarding policy by network devices. Instances
   of such classes reside in a virtual information store, which is
   called the IP Forwarding Policy Information Base (PIB). The
   corresponding IP forwarding policy provisioning data are intended for
   use by a COPS-PR TE Client-Type, and they complement the PRC classes
   that have been defined in the Framework PIB.

Table of Contents

   1.      Introduction...............................................2
   2.      Conventions used in this document..........................3
   3.      PIB Overview...............................................3
   4.      The IP Forwarding Policy Information Base..................4
   5.      Security Considerations....................................9
   6.      References.................................................9
   7.      Acknowledgments...........................................10
   8.      Authors' Addresses........................................10
   9.      Full Copyright Statement..................................11

Jacquenet et al.   Experimental - Expires August 2004           [Page 1]


Internet Draft            An IP Forwarding PIB             February 2004



1.   Introduction

   The deployment of value-added IP services over the Internet has
   become one of the most competing challenges for service providers, as
   well as a complex technical issue.

   Within the context of network resource provisioning and allocation,
   the Common Open Policy Service protocol (COPS, [2]) and its usage for
   the support of Policy Provisioning ([3]) is one of the most promising
   candidate protocols that should help service providers in dynamically
   enforcing IP routing and traffic engineering policies.

   An IP routing/TE policy consists in appropriately provisioning and
   allocating/de-allocating the switching and the transmission resources
   of an IP network (i.e. the routers and the links that connect these
   routers, respectively), according to e.g. rate, one-way delay, inter-
   packet delay variation, etc.) that have been possibly negotiated
   between the customers and the service providers, and according to (a
   set of)routing metrics, which can also reflect the network
   conditions.

   Thus, the enforcement of IP routing/TE policies yields the need for
   an introduction of a high level of automation for the dynamic
   provisioning of the configuration data that will be taken into
   account by the routers to select the appropriate IP routes.

   Within the context of this document, the actual enforcement of an IP
   forwarding policy is primarily based upon the activation of both
   intra- and inter-domain dynamic routing protocols that will be
   activated by the routers to select, install, maintain and possibly
   withdraw IP routes.

   Such routes have been selected so that they comply as much as
   possible with the aforementioned QoS requirements and/or specific
   routing constraints, possibly depending on the type of traffic that
   will be conveyed along these routes.

   It is therefore necessary to provide the route selection processes
   with the information that will depict the routing policies that are
   to be enforced within a domain and, whenever appropriate, the
   aforementioned constraints and metrics, given the dynamic routing
   protocols actually support traffic engineering capabilities for the
   calculation and the selection of such routes.

   Some of these capabilities are currently being specified in [4] and
   [5] for the OSPF (Open Shortest Path First) and the IS-IS
   (Intermediate System to Intermediate System routing protocol, [6])
   interior routing protocols respectively, while there is a comparable
   effort for the BGP4 (Border Gateway Protocol, version 4) protocol, as
   described in [7], for example.


Jacquenet et al.   Experimental - Expires August 2004           [Page 2]


Internet Draft            An IP Forwarding PIB             February 2004


   To provide the route selection processes with the aforementioned
   information, one possibility is to use the COPS-PR protocol, together
   with a collection of policy provisioning data that will be stored in
   a virtual information store, called a Policy Information Base.

   This draft describes a collection of Policy Rule Classes that will be
   stored and dynamically maintained in an IP forwarding PIB. The "rule"
   and "role" concepts, which have been defined in [8], are adopted by
   this document to distribute the IP routing policy provisioning data
   over the COPS-PR protocol.

   The corresponding IP forwarding policy provisioning data are intended
   for use by a COPS-PR TE Client-Type ([9]), and they complement the
   PRC classes that have been defined in the Framework PIB ([10]).

   This document is organized as follows:

   - Section 3 provides an overview of the organization of the IP
     forwarding PIB,

   - Section 4 provides a description of the PRC classes of the IP
     forwarding PIB, according to the semantics of the Structure of
     Policy Provisioning Information (SPPI, [11]).

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 [12].

3.   PIB Overview

   The dynamic enforcement of an IP forwarding policy relies upon the
   activation of intra- and inter-domain routing protocols that will
   have the ability to take into account configuration information for
   the computation and the selection of routes, which will comply as
   much as possible with the constraints and requirements that MAY have
   been contractually defined between customers and service providers.

   This document specifies an IP forwarding PIB that mainly aims at
   storing and maintaining the information related to the IP routes that
   have been installed in the routers' Forwarding Information Bases, so
   that service providers maintain and update the adequate knowledge of
   the network's resources availability, from an IP routing perspective.

   As such, this PIB has been designed so that it SHOULD be gracefully
   complemented by PIB modules that will reflect the IGP- and BGP-
   inferred routing policies to be enforced, in terms of cost metrics'
   values to be assigned and updated whenever needed.

   Also, the accounting PIB module which is described in [13] aims at
   providing the most accurate feedback (to service providers) on how

Jacquenet et al.   Experimental - Expires August 2004           [Page 3]


Internet Draft            An IP Forwarding PIB             February 2004


   efficient the enforcement of a given IP forwarding policy (as
   specified in this document) actually is.

   The choice of this PIB organization is basically twofold:

   - Make the PIB implementation simple,

   - Provide the appropriate granularity of policy provisioning data
      that will be manipulated according to the requirements and
      technical choices of service providers.

   Therefore, the IP forwarding PIB is currently organized into the
   following provisioning classes:

     1. The Forwarding Classes (ipFwdClasses): the information
         contained in these classes is meant to provide a detailed
         description of the IP routes as they have been selected by the
         routers of a given domain,

     2. The Statistics Classes (ipFwdStatsClasses): the information
         contained in these classes is meant to provide statistics on
         the use of the IP routes currently depicted in the IP
         forwarding PIB.

4.   The IP Forwarding Policy Information Base

   IP-FWD-PIB PIB-DEFINITIONS ::= BEGIN

   IMPORTS
        Unsigned32, Integer32, MODULE-IDENTITY,
        MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP
                FROM COPS-PR-SPPI
        InstanceId, ReferenceId, Prid, TagId
                FROM COPS-PR-SPPI-TC
        InetAddress, InetAddressType
                FROM INET-ADDRESS-MIB
        Count, TEXTUAL-CONVENTION
                FROM ACCT-FR-PIB-TC
        TruthValue, TEXTUAL-CONVENTION
                FROM SNMPv2-TC
        RoleCombination, PrcIdentifier
                FROM FRAMEWORK-ROLE-PIB
        SnmpAdminString
                FROM SNMP-FRAMEWORK-MIB;


   ipFwdPib     MODULE-IDENTITY

        SUBJECT-CATEGORIES { tbd }      -- TE client-type to be
                                                        -- assigned by IANA
        LAST-UPDATED    "200301220900Z"
        ORGANIZATION    "France Telecom"

Jacquenet et al.   Experimental - Expires August 2004           [Page 4]


Internet Draft            An IP Forwarding PIB             February 2004


        CONTACT-INFO    "
                        Mohamed Boucadair
                        France Telecom R & D
                        42, rue des Coutures
                        BP 6243
                        14066 CAEN CEDEX 04
                        France
                        Phone: +33 2 31 75 92 31
                        E-Mail: mohamed.boucadair@francetelecom.com"
        DESCRIPTION
                "The PIB module containing a set of policy rule classes
                that describe the IP routes that have been computed by
                means of routing/TE policy enforcement, as well as
                route traffic statistics."
        REVISION        "200402041000Z"
        DESCRIPTION
                "Initial version."

        ::= { pib tbd } -- tbd to be assigned by IANA

   ipFwdClasses         OBJECT IDENTIFIER ::= { ipFwdPib 1 }
   ipFwdStatsClasses    OBJECT IDENTIFIER ::= { ipFwdPib 2 }

   --
   -- Forwarding classes. The information contained in these classes
   -- is meant to provide a detailed description of the available IP
   -- routes. One table has been specified so far, but there is room
   -- for depicting different kinds of routes, like MPLS (MultiProtocol
   -- Label Switching, ([14]) LSP (Label switched Paths) paths.
   --
   --
   --


   --
   -- The ipFwdTable
   --

   ipFwdTable           OBJECT-TYPE

          SYNTAX        SEQUENCE OF ipRouteEntry
          PIB-ACCESS    notify
          STATUS        current
          DESCRIPTION
                "This table describes the IP routes that are installed
                in the forwarding tables of the routers."

          ::= { ipFwdClasses 1 }

   ipRouteEntry OBJECT-TYPE

          SYNTAX        ipRouteEntry

Jacquenet et al.   Experimental - Expires August 2004           [Page 5]


Internet Draft            An IP Forwarding PIB             February 2004


          STATUS        current
          DESCRIPTION
                "A particular route to a particular destination."

          PIB-INDEX     { ipRoutePrid }
          UNIQUENESS    { ipRouteDest,
                          ipRouteMask,
                          ipRoutePhbId,
                          ipRouteNextHopAddress
                          ipRouteNextHopMask
                          ipRouteIfIndex }

          ::= { ipFwdTable 1 }

   ipRouteEntry ::= SEQUENCE {
                ipRoutePrid                     InstanceId,
                ipRouteDestAddrType             InetAddressType,
                ipRouteDest                     InetAddress,
                ipRouteMask                     Unsigned32,
                ipRouteNextHopAddrType          InetAddressType,
                ipRouteNextHopAddress           InetAddress,
                ipRouteNextHopMask              Unsigned32,
                ipRoutePhbId                    Integer32,
                ipRouteOrigin                   Integer32,
                ipRouteIfIndex                  Unsigned32
   }

   ipRoutePrid                  OBJECT-TYPE

        SYNTAX                  InstanceId
        STATUS                  current
        DESCRIPTION
                "An integer index that uniquely identifies this route
                entry among all the route entries."

        ::= { ipRouteEntry 1 }

   ipRouteDestAddrType          OBJECT-TYPE

        SYNTAX                  InetAddressType
        STATUS                  current
        DESCRIPTION
                "The address type enumeration value ([15]) used to
                specify the type of a route's destination IP address."

        ::= { ipRouteEntry 2 }

   ipRouteDest          OBJECT-TYPE

        SYNTAX          InetAddress
        STATUS          current
        DESCRIPTION

Jacquenet et al.   Experimental - Expires August 2004           [Page 6]


Internet Draft            An IP Forwarding PIB             February 2004


                "The IP address to match against the packet's
                destination address."

        ::= { ipRouteEntry 3 }

   ipRouteMask          OBJECT-TYPE

        SYNTAX          Unsigned32 (0..128)
        STATUS          current
        DESCRIPTION
                "Indicates the length of a mask for the matching of the
                destination IP address. Masks are constructed by
                setting bits in sequence from the most-significant bit
                downwards for ipRouteMask bits length. All other bits
                in the mask, up to the number needed to fill the length
                of the address ipRouteDest are cleared to zero.  A zero
                bit in the mask then means that the corresponding bit
                in the address always matches."

        ::= { ipRouteEntry 4 }

   ipRouteNextHopAddrType       OBJECT-TYPE

        SYNTAX                  InetAddressType
        STATUS                  current
        DESCRIPTION
                "The address type enumeration value used to specify the
                type of the next hop's IP address."

        ::= { ipRouteEntry 5 }

   ipRouteNextHopAddress        OBJECT-TYPE

        SYNTAX                  InetAddress
        STATUS                  current
        DESCRIPTION
                "On remote routes, the address of the next router en
                route; Otherwise, 0.0.0.0."

        ::= { ipRouteEntry 6 }

   ipRouteNextHopMask           OBJECT-TYPE

        SYNTAX                  Unsigned32 (0..128)
        STATUS                  current
        DESCRIPTION
                "Indicates the length of a mask for the matching of the
                next hop's IP address. Masks are constructed by setting
                bits in sequence from the most-significant bit
                downwards for ipRouteNextHopMask bits length. All other
                bits in the mask, up to the number needed to fill the
                length of the address ipRouteNextHop are cleared to

Jacquenet et al.   Experimental - Expires August 2004           [Page 7]


Internet Draft            An IP Forwarding PIB             February 2004


                zero.  A zero bit in the mask then means that the
                corresponding bit in the address always matches."

        ::= { ipRouteEntry 7 }

   ipRoutePhbId OBJECT-TYPE

        SYNTAX          Integer32 (-1 | 0..63)
        STATUS          current
        DESCRIPTION
                "The binary encoding that uniquely identifies a Per Hop
                Behaviour (PHB, [16]) or a set of PHBs associated to
                the DiffServ Code Point (DSCP) marking of the IP
                datagrams that will be conveyed along this route. A
                value of -1 indicates that a specific PHB ID value has
                not been defined, and thus, all PHB ID values are
                considered a match."

        ::= { ipRouteEntry 8 }

   ipRouteOriginOBJECT-TYPE

        SYNTAX  INTEGER {
                        OSPF (0)
                        IS-IS (1)
                        BGP (2)
                        STATIC (3)
                        OTHER (4)
                }
        STATUS          current
        DESCRIPTION
                "The value indicates the origin of the route. Either
                the route has been computed by OSPF, by IS-IS,
                announced by BGP4, is static, or else."

        ::= { ipRouteEntry 9 }

   ipRouteIfIndex       OBJECT-TYPE

        SYNTAX          Unsigned32 (0..65535)
        STATUS          current
        DESCRIPTION
                "The ifIndex value that identifies the local interface
                through which the next hop of this route is
                accessible."

        ::= { ipRouteEntry 10 }

   --
   -- Route statistics classes. The information contained
   -- in the yet-to-be defined tables aim at reporting statistics about
   -- COPS control traffic, route traffic and potential errors. The

Jacquenet et al.   Experimental - Expires August 2004           [Page 8]


Internet Draft            An IP Forwarding PIB             February 2004


   -- next version of the draft will provide a first table that will be
   -- based upon the use of the "count" clause.
   --
   --

   END

5.   Security Considerations

   The traffic engineering policy provisioning data as they are
   described in this PIB will be used for configuring the appropriate
   network elements that will be involved in the dynamic enforcement of
   the corresponding routing and traffic engineering policies, by means
   of a COPS-PR communication that will convey this information.

   The function of dynamically provisioning network elements with such
   configuration information implies that only an authorized COPS-PR
   communication takes place.

   From this perspective, this draft does not introduce any additional
   security issues other than those that have been identified in the
   COPS-PR specification, and it is therefore recommended that the IPSec
   ([17]) protocol suite be used to secure the above-mentioned
   authorized communication.

6.   References
   [
   [1]  Bradner,] S., "The Internet Standards Process -- Revision 3",
      BCP 9, RFC 2026, October 1996.
   [2]  Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja R., Sastry
      A., "The COPS (Common Open Policy Service) Protocol", RFC 2748,
      Proposed Standard, January 2000.
   [3]  Ho Chan, K., Durham, D., Gai, S., Herzog, S., McLoghrie, K.,
      Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., "COPS Usage
      for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
   [4]  Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
      Extensions to OSPF", RFC 3630, September 2003.
   [5]  Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering",
      draft-ietf-isis-traffic-05.txt, Work in Progress, August 2003.
   [6]  ISO/IEC 10589, "Intermediate System to Intermediate System,
      Intra-Domain Routing Exchange Protocol for use in Conjunction with
      the Protocol for Providing the Connectionless-mode Network Service
      (ISO 8473)", June 1992.
   [7]  Jacquenet, C., "The BGP QOS_NLRI Attribute", draft-jacquenet-
      bgp-qos-00.txt, Work in Progress, February 2004.
   [8]  Moore, B. et al., "Policy Core Information Model -- Version 1
      Specification", RFC 3060, February 2001.
   [9]  Jacquenet, C., "A COPS Client-Type for Traffic Engineering",
      draft-jacquenet-cops-te-00.txt, Work in Progress, February 2004.




Jacquenet et al.   Experimental - Expires August 2004           [Page 9]


Internet Draft            An IP Forwarding PIB             February 2004



   [10] Sahita, R., et al., "Framework Policy Information Base", RFC
      3318, March 2003.
   [11] McLoghrie, K., et al., "Structure of Policy Provisioning
      Information (SPPI)", RFC 3159, August 2001.
   [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997
   [13] Boucadair, M., "An IP TE PIB for Accounting purposes", draft-
      boucadair-ipte-acct-pib-02.txt, Work in Progress, June 2003.
   [14] Rosen, E., et al., "Multiprotocol Label Switching Architecture",
      RFC 3031, January 2001.
   [15] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J.,
      "Textual Conventions for Internet Network Addresses", RFC 3291,
      May 2002.
   [16] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop
      Behaviour Identification Codes", RFC 3140, June 2001.
   [17] Kent, S., Atkinson, R., "Security Architecture for the Internet
      Protocol", RFC 2401, November 1998.

7.   Acknowledgments

   Part of this work is funded by the European Commission, within the
   context of the MESCAL (Management of End-to-End Quality of Service
   Across the Internet At Large, http://www.mescal.org) project, which
   is itself part of the IST (Information Society Technologies) research
   program.

   The authors would also like to thank all the partners of the MESCAL
   project for the fruitful discussions that have been conducted so far
   within the context of the traffic engineering specification effort of
   the project.

8.   Authors' Addresses

   Mohamed Boucadair
   France Telecom R & D
   DMI/SIR
   42, rue des Coutures
   BP 6243
   14066 Caen Cedex 4
   France
   Phone: +33 2 31 75 92 31
   Email: mohamed.boucadair@francetelecom.com

   Christian Jacquenet
   France Telecom
   3, avenue Fran‡ois Ch‚teau
   CS 36901
   35069 Rennes CEDEX
   France
   Phone: +33 2 99 87 63 31
   Email: christian.jacquenet@francetelecom.com

Jacquenet et al.   Experimental - Expires August 2004          [Page 10]


Internet Draft            An IP Forwarding PIB             February 2004



9.   Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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, coed, 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 et al.   Experimental - Expires August 2004          [Page 11]


Network Working Group                                       G. Cristallo
Internet Draft                                                   Alcatel
Document: draft-jacquenet-bgp-qos-00.txt                    C. Jacquenet
Category: Experimental                                    France Telecom
Expires August 2004                                        February 2004



                       The BGP QOS_NLRI Attribute
                    <draft-jacquenet-bgp-qos-00.txt>


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
   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.

   NOTE: a PDF version of this document (which includes the figures
   mentioned in section 7) can be accessed at http://www.mescal.org.

Abstract

   This draft specifies an additional BGP4 (Border Gateway Protocol,
   version 4) attribute, named the "QOS_NLRI" attribute, which aims at
   propagating QoS (Quality of Service)-related information associated
   to the NLRI (Network Layer Reachability Information) information
   conveyed in a BGP UPDATE message.

Table of Contents

   1.      Conventions Used in this Document..........................2
   2.      Introduction...............................................2
   3.      Basic Requirements.........................................3
   4.      The QOS_NLRI Attribute (Type Code tbd*)....................3
   5.      Operation..................................................7
   6.      Use of Capabilities Advertisement with BGP-4...............8
   7.      Simulation Results.........................................8

Jacquenet          Experimental - Expires August 2004           [Page 1]


Internet Draft           The QOS_NLRI Attribute            February 2004


   7.1.    A Phased Approach..........................................8
   7.2.    A Case Study..............................................10
   7.3.    Additional Results........................................11
   7.4.    Next Steps................................................12
   8.      IANA Considerations.......................................12
   9.      Security Considerations...................................12
   10.     References................................................13
   11.     Acknowledgments...........................................13
   12.     Authors' Addresses........................................14
   13.     Full Copyright Statement..................................14


1.   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 [2].

2.   Introduction

   Providing end-to-end quality of service is 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 enforced within an
   autonomous system, and which may well differ from one AS (Autonomous
   System) to another.

   For 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 networks
   is concerned. Nevertheless, providing end-to-end quality of service
   across administrative domains still remains an issue, mainly because:

   - QoS policies may dramatically differ from one service provider to
     another,

   - The enforcement of a specific QoS policy may also differ from one
     domain to another, although the definition of a set of common
     quality of service indicators may be shared between the service
     providers.

   Activate the BGP4 protocol ([3]) for exchanging reachability
   information between autonomous systems has been a must for many
   years. Therefore, disseminating QoS information coupled with
   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, which will convey QoS-related information associated to
   the routes described in the corresponding NLRI field of the
   attribute.


Jacquenet          Experimental - Expires August 2004           [Page 2]


Internet Draft           The QOS_NLRI Attribute            February 2004


   This document is organized according to the following sections:

   - Section 3 describes the basic requirements that motivate the
     approach,

   - Section 4 describes the attribute,

   - Section 5 elaborates on the mode of operation,

   - Section 6 elaborates on the use of the capabilities advertisement
     feature of the BGP4 protocol,

   - Section 7 depicts the results of a simulation work,

   - Finally, sections 8 and 9 introduce IANA and some security
     considerations, respectively.

3.   Basic Requirements

   The choice of using the BGP4 protocol for exchanging QoS information
   between domains is not only motivated by the fact BGP is currently
   the only inter-domain (routing) protocol activated in the Internet,
   but also because the manipulation of attributes is a powerful means
   for service providers to disseminate QoS information with the desired
   level of precision.

   The approach presented in this draft has identified the following
   requirements:

   - Keep the approach scalable. The scalability of the approach can be
     defined in many ways that include the convergence time taken by the
     BGP peers to reach a consistent view of the network connectivity,
     the number of route entries that will have to be maintained by a
     BGP peer, the dynamics of the route announcement mechanism (e.g.,
     how frequently and under which conditions should an UPDATE message
     containing QoS information be sent?), etc.

   - Keep the BGP4 protocol operation unchanged. The introduction of a
     new attribute should not affect the way the protocol operates, but
     the information contained in this attribute may very well influence
     the BGP route selection process.

   - Allow for a smooth migration. The use of a specific BGP attribute
     to convey QoS information should not constrain network operators to
     migrate the whole installed base at once, but rather help them in
     gradually deploying the QoS information processing capability.

4.   The QOS_NLRI Attribute (Type Code tbd*)

   (*): "tbd" is subject to the IANA considerations section of this
   draft.


Jacquenet          Experimental - Expires August 2004           [Page 3]


Internet Draft           The QOS_NLRI Attribute            February 2004


   The QOS_NLRI attribute is an optional transitive attribute that can
   be used:

   1. 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. Such QoS requirements can be expressed in
     terms of minimum one-way delay ([4]) to reach a destination, the
     experienced delay variation for IP datagrams that are destined to
     a given destination prefix ([5]), the loss rate experienced 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, [6]) marking). These QoS requirements can be used as an
     input for the BGP route calculation process,

   2. To provide QoS-related information along with the NLRI information
     in a single BGP UPDATE message. It is assumed that this
     information will be related to the route (or set of routes)
     described in the NLRI field of the attribute.

   From a service provider's perspective, the choice of defining the
   QOS_NLRI attribute as an optional transitive attribute is motivated
   by the fact that this kind of attribute allows for gradual deployment
   of the dissemination of QoS-related information by BGP4: not all the
   BGP peers are supposed to be updated accordingly, while partial
   deployment of such QoS extensions can already provide an added value,
   e.g. in the case where a service provider manages multiple domains,
   and/or has deployed a BGP confederation ([7]).

   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 suggested to have a look on
   document [8], 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)          |
         +---------------------------------------------------------+
         | Network Address of Next Hop (4 octets)                  |
         +---------------------------------------------------------+
         | Flags (1 octet)                                         |

Jacquenet          Experimental - Expires August 2004           [Page 4]


Internet Draft           The QOS_NLRI Attribute            February 2004


         +---------------------------------------------------------+
         | Identifier (2 octets)                                   |
         +---------------------------------------------------------+
         | Length (1 octet)                                        |
         +---------------------------------------------------------+
         | Prefix (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) Packet rate, i.e. the number of IP datagrams that can be
       transmitted (or have been lost) per unit of time, this number
       being characterized by the elaboration provided in the QoS
       Information Sub-code (see below)
   (2) One-way delay metric
   (3) Inter-packet delay variation
   (4) PHB Identifier

   -  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-
       type)
   (1) Reserved rate
   (2) Available rate
   (3) Loss rate
   (4) Minimum one-way delay
   (5) Maximum one-way delay
   (6) Average one-way delay

   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).









Jacquenet          Experimental - Expires August 2004           [Page 5]


Internet Draft           The QOS_NLRI Attribute            February 2004


            +---------------------------------------+
            |    |  0 |  1 |  2 |  3 |  4 |  5 |  6 |
            +---------------------------------------+
            |  0 |    |    |    |    |    |    |    |
            +---------------------------------------+
            |  1 |    |    |    |    |  X |  X |  X |
            +---------------------------------------+
            |  2 |    |  X |  X |  X |    |    |    |
            +---------------------------------------+
            |  3 |    |  X |  X |  X |  X |  X |  X |
            +---------------------------------------+
            |  4 |    |  X |  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 kilobits per second
       (kbps), and the rate encoding rule is composed of a 3-bit
       exponent (with an assumed base of 8) followed by a 13-bit
       mantissa, as depicted in the figure below:

                             0      8       16
                             |       |       |
                             -----------------
                             |Exp| Mantissa  |
                             -----------------

       This encoding scheme advertises a numeric value that is (2^16 -1
       - exponential encoding of the considered rate), as depicted in
       [9].
   (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.

   -  QoS Information Origin:

       This field provides indication on the origin of the path
       information, as defined in section 4.3.of [3].

   -  Address Family Identifier (AFI):

       This field carries the identity of the Network Layer protocol
       associated with the Network Address that follows. Currently
       defined values for this field are specified in [10] (see the
       Address Family Numbers section of this reference document).



Jacquenet          Experimental - Expires August 2004           [Page 6]


Internet Draft           The QOS_NLRI Attribute            February 2004


   -  Subsequent Address Family Identifier (SAFI):

       This field provides additional information about the type of the
       prefix carried in the QOS_NLRI attribute.

   -  Network Address of Next Hop:

       This field contains the IPv4 Network Address of the next router
       on the path to the destination prefix, (reasonably) assuming that
       such routers can at least be addressed according to the IPv4
       formalism.

   -  Flags, Identifier, Length and Prefix fields:

       These four fields actually compose the NLRI field of the QOS_NLRI
       attribute, and their respective meanings are as defined in
       section 2.2.2 of [11].

5.   Operation

   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 one or several
   route(s) is (are) being advertised shares a common subnet with the
   next hop address.  This is known as a "first party" next hop
   information.

   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
   information.

   A BGP speaker that sends an UPDATE message with the QOS_NLRI
   attribute has the ability to advertise multiple QoS routes, since the
   Identifier field of the attribute is part of the NLRI description. In
   particular, the same prefix can be advertised more than once without
   subsequent advertisements that would replace previous announcements.

   Since the resolution of the NEXT_HOP address that is always conveyed
   in a BGP UPDATE message is left to the responsibility of the IGP that
   has been activated within the domain, the best path according to the
   BGP route selection process depicted in [3] SHOULD also be
   advertised. As long as the routers on the path towards the address
   depicted in the NEXT_HOP attribute of the message have the additional
   paths depicted in the QOS_NLRI attribute, the propagation of QoS
   routes within a domain where all the routers are QOS_NLRI aware
   should not yield inconsistent routing.

   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

Jacquenet          Experimental - Expires August 2004           [Page 7]


Internet Draft           The QOS_NLRI Attribute            February 2004


   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 Sub-code set to Malformed AS_PATH.

   Finally, 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 [12], 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
   follows:

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

   -  The Capability Value field is a one-octet field, which contains
       the Type Code of the QOS_NLRI attribute, as defined in the
       introduction of section 5 of the present draft.

   In addition, the multiple path advertisement capability MUST be
   supported, as defined in section 2.1 of [4].


7.   Simulation Results

7.1.     A Phased Approach

   The simulation work basically aims at qualifying the scalability of
   the usage of the QOS_NLRI attribute for propagating QoS-related
   information across domains.

   This effort also focused on the impact on the stability of the BGP
   routes, by defining a set of basic engineering rules for the
   introduction of additional QoS information, as well as design
   considerations for the computation and the selection of "QoS routes".

   This ongoing development effort is organized into a step-by-step
   approach, which consists in the following phases:

     1. Model an IP network composed of several autonomous systems.
        Since this simulation effort is primarily focused on the

Jacquenet          Experimental - Expires August 2004           [Page 8]


Internet Draft           The QOS_NLRI Attribute            February 2004


        qualification of the scalability related to the use of the
        QOS_NLRI attribute for exchanging QoS-related information
        between domains, it has been decided that the internal
        architecture of such domains should be kept very simple, i.e.
        without any specific IGP interaction,

     2. Within this IP network, there are BGP peers that are QOS_NLRI
        aware, i.e. they have the ability to process the information
        conveyed in the attribute, while the other routers are not: the
        latter do not recognize the QOS_NLRI attribute by definition,
        and they will forward the information to other peers, by setting
        the Partial bit in the attribute, meaning that the information
        conveyed in the message is incomplete. This approach contributes
        to the qualification of a progressive deployment of QOS_NLRI-
        aware BGP peers,

     3. As far as QOS_NLRI aware BGP peers are concerned, they will
        process the information contained in the QOS_NLRI attribute to
        possibly influence the route decision process, thus yielding the
        selection (and the announcement) of distinct routes towards a
        same destination prefix, depending on the QoS-related
        information conveyed in the QOS_NLRI attribute,

     4. Modify the BGP route decision process: at this stage of the
        simulation, the modified decision process relies upon the one-
        way delay information (which corresponds to the QoS Information
        Code field of the attribute valued at "2"), and it also takes
        into account the value of the Partial bit of the attribute.

   Once the creation of these components of the IP network has been
   completed (together with the modification of the BGP route selection
   process), the behavior of a QOS_NLRI-capable BGP peer is as follows.

   Upon receipt of a BGP UPDATE message that contains the QOS_NLRI
   attribute, the router will first check if the corresponding route is
   already stored in its local RIB, according to the value of the one-
   way delay information contained in both QoS Information Code and Sub-
   code fields of the attribute.

   If not, the BGP peer will install the route in its local RIB.
   Otherwise (i.e. an equivalent route already exists in its database),
   the BGP peer will select the best of both routes according to the
   following criteria:

   - If both routes are said to be either incomplete (Partial bit has
      been set) or complete (Partial bit is unset), the route with the
      lowest delay will be selected,

   - Otherwise, a route with the Partial bit unset is always preferred
      over any other route, even if this route reflects a higher transit
      delay.


Jacquenet          Experimental - Expires August 2004           [Page 9]


Internet Draft           The QOS_NLRI Attribute            February 2004


   If ever both Partial bit and transit delay information are not
   sufficient to make a decision, the standard BGP decision process
   (according to the breaking ties mechanism depicted in [3]) is
   performed.

7.2.     A Case Study

   REMINDER: a PDF version of this document (which includes the figures
   mentioned in this section) can be accessed at http://www.mescal.org.

   As stated in the previous section 7.1, the current status of the
   simulation work basically relies upon the one-way transit delay
   information only, as well as the complete/incomplete indication of
   the Partial bit conveyed in the QOS_NLRI attribute.

   The following figures depict the actual processing of the QoS-related
   information conveyed in the QOS_NLRI attribute, depending on whether
   the peer is QOS_NRLI-aware or not.

                          [Fig. 1: A Case Study.]

   Figure 1 depicts the IP network that has been modelled, while figure
   2 depicts the propagation of a BGP UPDATE message that contains the
   QOS_NLRI attribute, in the case where the contents of the attribute
   are changed, because of complete/incomplete conditions depicted by
   the Partial bit of the QOS_NLRI attribute.

       [Fig. 2: Propagation of One-way Delay Information via BGP4.]

   Router S in figure 2 is a QOS_NRLI-capable speaker. It takes 20
   milliseconds for node S to reach network 192.0.20.0: this information
   will be conveyed in a QOS_NLRI attribute that will be sent by node S
   in a BGP UPDATE message with the Partial bit of the QOS_NLRI
   attribute unset.

   Router A is another QOS_NLRI BGP peer, and it takes 3 milliseconds
   for A to reach router S. Node A will update the QoS-related
   information of a QOS_NLRI attribute, indicating that, to reach
   network 192.0.20.0, it takes 23 milliseconds. Router A will install
   this new route in its database, and will propagate the corresponding
   UPDATE message to its peers.

   On the other hand, router B is not capable of processing the
   information conveyed in the QOS_NLRI attribute, and it will therefore
   set the Partial bit of the QOS_NLRI attribute in the corresponding
   UPDATE message, leaving the one-way delay information detailed in
   both QoS Information Code and Sub-code unchanged.

   Upon receipt of the UPDATE message sent by router A, router E will
   update the one-way delay information since it is a QOS_NRLI-capable
   peer. Finally, router D receives the UPDATE message, and selects a


Jacquenet          Experimental - Expires August 2004          [Page 10]


Internet Draft           The QOS_NLRI Attribute            February 2004


   route  with  a  40  milliseconds  one-way  delay  to  reach  network
   192.0.20.0, as depicted in figure 3.

              [Fig. 3: Selecting QoS Routes Across Domains.]

   This simulation result shows that the selection of a delay-inferred
   route over a BGP route may not yield an optimal decision. In the
   above example, the 40 ms-route goes through routers D-E-A-S, while a
   "truly optimal" BGP route would be through routers D-E-F-A-S, hence a
   38 ms-route. This is because of a BGP4 rule that does not allow
   router F to send an UPDATE message towards router E, because router F
   received the UPDATE message from router A thanks to the iBGP
   connection it has established with A.

7.3.     Additional Results

   The following table reflects the results obtained from a simulation
   network composed of 9 autonomous systems and 20 BGP peers. The
   numbers contained in the columns reflect the percentage of serviced
   requirements, where the requirements are expressed in terms of delay.

   Three parameters have been taken into account:

   - The percentage of BGP peers that have the ability to process the
     information conveyed in the QOS_NLRI attribute (denoted as "x% Q-
     BGP" in the following table),

   - The transit delays "observed" (and artificially simulated) on each
     transmission link: the higher the delays, the lower the percentage
     of serviced QoS requirements,

   - The QoS requirements themselves, expressed in terms of delay: as
     such, the strongest requirements (i.e. the lowest delays) have less
     chance to be satisfied.

            +-------------------------------------------+
            | Delay | 0% Q-BGP | 50% Q-BGP | 100% Q-BGP |
            +-------------------------------------------+
            |  3    |    11    |    8,3    |    11      |
            +-------------------------------------------+
            |  5    |    30,5  |    30,5   |    36,1    |
            +-------------------------------------------+
            |  6    |    40    |    47,2   |    55,5    |
            +-------------------------------------------+
            |  7    |    47    |    59,7   |    72,2    |
            +-------------------------------------------+
            |  8    |    62,5  |    79     |    91,6    |
            +-------------------------------------------+
            |  9    |    63    |    84,7   |    97,2    |
            +-------------------------------------------+
            |  10   |    70,8  |    90,2   |    98,6    |
            +-------------------------------------------+

Jacquenet          Experimental - Expires August 2004          [Page 11]


Internet Draft           The QOS_NLRI Attribute            February 2004


            |  11   |    76,3  |    93     |    98,6    |
            +-------------------------------------------+
            |  12   |    86,1  |    97,2   |    100     |
            +-------------------------------------------+
            |  13   |    88,8  |    98,6   |    100     |
            +-------------------------------------------+
            |  14   |    94,4  |    100    |    100     |
            +-------------------------------------------+
            |  15   |    94,4  |    100    |    100     |
            +-------------------------------------------+
            |  16   |    94,4  |    100    |    100     |
            +-------------------------------------------+
            |  17   |    97,2  |    100    |    100     |
            +-------------------------------------------+
            |  18   |    98,6  |    100    |    100     |
            +-------------------------------------------+
            |  19   |    98,6  |    100    |    100     |
            +-------------------------------------------+
            |  20   |    98,6  |    100    |    100     |
            +-------------------------------------------+
            |  21   |    98,6  |    100    |    100     |
            +-------------------------------------------+
            |  22   |    100   |    100    |    100     |
            +-------------------------------------------+

   This table clearly demonstrates the technical feasibility of the
   approach, and how the use of the QOS_NLRI attribute can improve the
   percentage of serviced QoS requirements.

7.4.     Next Steps

   This simulation effort is currently pursued in order to better
   qualify the interest of using the BGP4 protocol to convey QoS-related
   information between domains, from a scalability perspective, i.e. the
   growth of BGP traffic vs. the stability of the network.

   The stability of the IP network is probably one of the most important
   aspects, since QoS-related information is subject to very dynamic
   changes, thus yielding non-negligible risks of flapping.

8.   IANA Considerations

   Section 4 of this draft documents an optional transitive BGP-4
   attribute named "QOS_NLRI" whose type value will be assigned by IANA.
   Section 5 of this draft also documents a Capability Code whose value
   should be assigned by IANA as well.

9.   Security Considerations

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

Jacquenet          Experimental - Expires August 2004          [Page 12]


Internet Draft           The QOS_NLRI Attribute            February 2004





10.    References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.
   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
   [3]  Rekhter, Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC
      1771, March 1995.
   [4]  Almes, G., Kalidindi, S., "A One-Way-Delay Metric for IPPM", RFC
      2679, September 1999.
   [5]  Demichelis, C., Chimento, P., "IP Packet Delay Variation Metric
      for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
   [6]  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.
   [7]  Traina, P., McPherson, D., Scudder, J., "Autonomous System
      Confederations for BGP", RFC 3065, February 2001.
   [8]  Jacquenet, C., "A COPS Client-Type for Traffic Engineering",
      draft-jacquenet-cops-te-00.txt, Work in Progress, February 2004.
   [9]  Apostolopoulos, G. et al, "QoS Routing Mechanisms and OSPF
      Extensions", RFC 2676, August 1999.
   [10] Reynolds, J., Postel, J., "ASSIGNED NUMBERS", RFC 1700, October
      1994.
   [11] Walton, D., et al., "Advertisement of Multiple Paths in BGP",
      draft-walton-bgp-add-paths-01.txt, Work in Progress, November
      2002.
   [12] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-
      4", RFC 3392, November 2002.
   [13] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
      Considerations Section in RFCs", RFC 2434, October 1998.
   [14] Heffernan, A., "Protection of BGP sessions via the TCP MD5
      Signature Option", RFC 2385, August 1998.

11.    Acknowledgments

   Part of this work is funded by the European Commission, within the
   context of the MESCAL (Management of End-to-End Quality of Service
   Across the Internet At Large, http://www.mescal.org) 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 MESCAL
   project for the fruitful discussions that have been conducted within
   the context of the traffic engineering specification effort of the
   project, as well as O. Bonaventure and B. Carpenter for their
   valuable input.




Jacquenet          Experimental - Expires August 2004          [Page 13]


Internet Draft           The QOS_NLRI Attribute            February 2004



12.    Authors' Addresses

   Geoffrey Cristallo
   Alcatel
   Francis Wellesplein, 1
   2018 Antwerp
   Belgium
   Phone: +32 (0)3 240 7890
   E-Mail: geoffrey.cristallo@alcatel.be

   Christian Jacquenet
   France Telecom
   3, avenue Fran‡ois Ch‚teau
   CS 36901
   35069 Rennes Cedex
   France
   Phone: +33 2 99 87 63 31
   Email: christian.jacquenet@francetelecom.com

13.    Full Copyright Statement

   Copyright(C) The Internet Society (2004). 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           Experimental - Exp. August 2004           [Page 14]