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

Versions: 00 01 02                                                      
Network Working Group                                       M. Boucadair
Internet Draft                                              C. Jacquenet
Document: draft-jacquenet-ip-te-pib-02.txt            France Telecom R&D
Category: Experimental                                         June 2002
Expires December 2002


           An IP Traffic Engineering Policy Information Base
                    <draft-jacquenet-ip-te-pib-02.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 traffic engineering policy by COPS-PR ([2])-
   capable routers. Instances of such classes reside in a virtual
   information store, which is called the IP Traffic Engineering Policy
   Information Base (IP TE PIB). The corresponding IP TE policy
   provisioning data are intended for use by the COPS-PR IP TE Client-
   Type([3]), and they complement the PRC classes that have been defined
   in the Framework PIB ([4]).

Table of Contents

   1.      Introduction................................................2
   2.      Conventions used in this document...........................3
   3.      Changes since the previous version..........................3
   4.      Scalability considerations..................................3
   4.1.    A tentative metric taxonomy.................................4
   4.2.    Reporting the enforcement of an IP traffic engineering
             policy....................................................4
   5.      PIB Overview................................................5

Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 1]


Internet Draft       An IP Traffic Engineering PIB            June 2002


   6.      The IP Traffic Engineering Policy Information Base..........6
   7.      Security Considerations....................................26
   8.      References.................................................27
   9.      Acknowledgments............................................28
   10.     Authors' Addresses.........................................28

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 COPS protocol and its usage for the support of Policy
   Provisioning is one of the ongoing specification efforts of the
   Resource Allocation Protocol (rap) Working Group of the IETF that
   should help service providers in dynamically enforcing IP Traffic
   Engineering (IP TE) policies.

   An IP traffic engineering 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 Quality
   of Service (QoS) requirements (e.g. rate, one-way delay, inter-packet
   delay variation, etc.) that have been expressed by the customers who
   can access such resources within the context of a given service
   subscription procedure ([5]).

   Thus, the enforcement of an IP traffic engineering policy yields the
   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
   traffic engineering policy is primarily based upon the activation of
   both intra- and inter-domain dynamic routing protocols (e.g. [6],
   [7]) that will be activated in the network to select, install,
   maintain and possibly withdraw routes that will comply with the
   above-mentioned QoS requirements and/or specific routing constraints,
   depending on the type of traffic that will be conveyed along these
   traffic engineered routes.

   It is therefore necessary to provide the route selection processes
   with the information that will reflect these QoS requirements, given
   the dynamic routing protocols support traffic engineering
   capabilities for the computation of such routes.

   Some of these capabilities are currently being specified in [8] and
   [9] for the OSPF (Open Shortest Path First, [6]) and the IS-IS
   (Intermediate System to Intermediate System routing protocol, [10])
   interior routing protocols respectively, while there is a comparable


Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 2]


Internet Draft       An IP Traffic Engineering PIB            June 2002


   effort for the BGP4 (Border Gateway Protocol, version 4) protocol, as
   described in [11], for example.

   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 the IP TE PIB. The "rule" and
   "role" concepts, which have been defined in [12], are adopted by this
   document to distribute the IP traffic engineering policy provisioning
   data over the COPS-PR protocol.

   This document is organized as follows:

   - Section 4 introduces some considerations about the scalability of
     such a dynamic provisioning scheme,

   - Section 5 provides an overview of the organization of the IP TE
     PIB,

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

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

3. Changes since the previous version

   - The PIB has been slightly reorganized to introduce an additional
     table for IS-IS-related policy provisioning data according to [9],

   - The introduction has been slightly reworded,

   - The references section has been updated.

4. Scalability considerations

   The usage of the COPS-PR protocol for the dynamic enforcement of an
   IP traffic engineering policy raises some scalability issues, as far
   as the volume of configuration information that will be exchanged not
   only between the routers themselves (because of the OSPF machinery
   for example), but also between the PEP (Policy Enforcement Point)
   components embedded in the routers and the PDP (Policy Decision
   Point) they communicate with is concerned.



Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 3]


Internet Draft       An IP Traffic Engineering PIB            June 2002


   While the concern strictly related to the design of a routing policy
   is outside the scope of this document, the dynamic provisioning of
   metric values as well as the reports related to the actual
   enforcement of decisions taken by the PDP, deserve some elaboration.

4.1. A tentative metric taxonomy

   The metrics that will be taken into account by the Shortest Path
   First (SPF) algorithms for IP TE route calculation can be classified
   into two basic categories:

     1. Metrics assigned on a long-term basis, which basically consist
        of the "usual" cost metrics, like those defined in [5]. These
        metrics are those that are assigned on a (logical) interface
        basis, and they aim at reflecting the link quality the
        corresponding interface is attached to,

     2. Metrics assigned on a (very) short term basis, which MAY consist
        of the following information:

         - The available bandwidth, (e.g. based upon the information
           provided by SNMP (Simple Network Management Protocol, [15])
           counters like ifInOctets and ifOutOctets),
         - The amount of bandwidth that can be reserved,
         - The amount of reserved bandwidth.

   While "long term" metric values should not change frequently by
   definition, the "short term" metric values MAY vary like the ongoing
   usage of the resources of the network.

   Therefore, the dynamic computation of "short term" metric values
   SHOULD remain in the magnitude of the corresponding SPF computation,
   since newly assigned values yield the spontaneous generation of LSU
   (Link State Update, [5]) messages. Thus, the traffic generated by the
   IP traffic engineering provisioning data SHOULD be minimized
   according to pre-computation engineering recommendations like those
   described in [16].

4.2. Reporting the enforcement of an IP traffic engineering policy

   Likewise, the actual enforcement of policy decisions implies the
   activation of a reporting mechanism, as described in the COPS-PR
   specification.

   From this perspective, this draft assumes that the corresponding
   reports sent by the PEP components of the routers towards the PDP
   SHOULD include the traffic engineered routes that have been computed
   by the routers, at least for network planning purposes: the service
   subscription requests will be negotiated according to the knowledge
   of the network resources that are actually available, and this
   information includes the routes that could very well service the
   aforementioned requirements, without any extra computation.

Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 4]


Internet Draft       An IP Traffic Engineering PIB            June 2002



   Therefore, the traffic generated by the notification reports of the
   installed routes SHOULD remain in the magnitude of the route
   announcement procedures of the IP routing protocols machineries (like
   OSPF), and it is assumed that the volume of the corresponding COPS-PR
   traffic is also highly dependent on the pre-computation engineering
   recommendations that have been mentioned in the above section 3.1.

   In other words, this draft assumes that it is mainly the
   responsibility of a network operator to enforce an IP traffic
   engineering policy that should raise scalability issues (raised by
   design), NOT the choice of activating the COPS-PR protocol as a means
   to convey the corresponding IP TE provisioning data.

   Nevertheless, it is obviously one of the most important concerns of
   the ongoing specification and development effort that is partly
   reflected by this draft. In particular, it is the intention of the
   authors of this draft to later submit a publication that will aim at
   depicting the simulation results obtained through the validation of
   this COPS-PR architecture for the dynamic enforcement of an IP
   traffic engineering policy within the context of an operational
   service provider's environment.

5. PIB Overview

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

   This traffic engineering-related information is basically composed of
   metric values that will aim at reflecting an IP TE policy, as well as
   the result of the enforcement of such a policy, so that customers and
   providers can check anytime that the IP service is provisioned with
   the appropriate (and contractual) levels of quality (which can be
   expressed in terms of service availability, for example).

   Therefore, the IP TE PIB mainly aims at:

   - Storing and maintaining the configuration information that will be
     used by the routers to compute and select the routes that will
     comply with a collection of QoS requirements, such as the one-way
     maximum transit delay, or the maximum inter-packet delay
     variation,

   - Storing and maintaining the information related to the traffic
     engineered routes that have been installed in the routers'
     Forwarding Information Bases, so that the service providers have
     the permanent knowledge of the network's resources availability.


Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 5]


Internet Draft       An IP Traffic Engineering PIB            June 2002


   From this perspective, the IP TE PIB is currently organized into the
   following provisioning classes:

     1. The Forwarding Classes (ipTeFwClasses): the information
        contained in these classes is meant to provide a detailed
        description of the traffic-engineered routes. Only one table is
        defined at the current stage of this draft: the IP TE Route
        table which describes the information related to TE routes that
        have been installed by the routers in their FIBs,

     2. The Metrics Classes (ipTeMetricsClasses): the information
        stored in the tables of this class is meant to provide a
        description of the metric values that will be taken into
        account by intra- and inter-domain routing protocols for the
        computation and the selection of traffic-engineered routes. So
        far, two groups have been identified: the first group is based
        upon the traffic engineering extensions of intra-domain routing
        protocols, the second group is related to QoS-related
        information that can be conveyed in BGP-4 messages,

     3. The Statistics Classes (ipTeStatsClasses): the information
        contained in these classes is meant to provide statistic on the
        enforcement of the TE policies.

6. The IP Traffic Engineering Policy Information Base

   IP-TE-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;


   ipTePib     MODULE-IDENTITY

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

Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 6]


Internet Draft       An IP Traffic Engineering PIB            June 2002


        CONTACT-INFO   "
                       Christian Jacquenet
                       France Telecom R & D
                       42, rue des Coutures
                       BP 6243
                       14066 CAEN CEDEX 04
                       France
                       Phone: +33 2 31 75 94 28
                       E-Mail: christian.jacquenet@francetelecom.com"
        DESCRIPTION
               "The PIB module containing a set of policy rule classes
                that describe IP Traffic Engineering policies to be
                enforced within and between domains."
       REVISION        "200111061600Z"
       DESCRIPTION
               "Initial version."

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

   ipTeFwdClasses      OBJECT IDENTIFIER ::= { ipTePib 1 }
   ipTeMetricsClasses  OBJECT IDENTIFIER ::= { ipTePib 2 }
   ipTeStatsClasses    OBJECT IDENTIFIER ::= { ipTePib 3 }

   --
   -- Forwarding classes. The information contained in these classes
   -- is meant to provide a detailed description of the traffic
   -- engineered routes. One table has been specified so far, but there
   -- is room for depicting specific kinds of routes, like MPLS LSP
   -- paths, for example.
   --
   --


   --
   -- The ipTeRouteTable
   --

   ipTeRouteTable      OBJECT-TYPE

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

          ::= { ipTeFwdClasses 1 }

   ipTeRouteEntry      OBJECT-TYPE

          SYNTAX        ipTeRouteEntry

Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 7]


Internet Draft       An IP Traffic Engineering PIB            June 2002


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

          PIB-INDEX    { ipTeRoutePrid }
          UNIQUENESS   { ipTeRouteDest,
                          ipTeRouteMask,
                          ipTeRoutePhbId,
                          ipTeRouteNextHopAddress
                         ipTeRouteNextHopMask
                          ipTeRouteIfIndex }

          ::= { ipTeRouteTable 1 }

   ipTeRouteEntry ::= SEQUENCE {
               ipTeRoutePrid                  InstanceId,
               ipTeRouteDestAddrType          InetAddressType,
               ipTeRouteDest                  InetAddress,
               ipTeRouteMask                  Unsigned32,
               ipTeRouteNextHopAddrType       InetAddressType,
               ipTeRouteNextHopAddress        InetAddress,
               ipTeRouteNextHopMask           Unsigned32,
               ipTeRoutePhbId                 Integer32,
               ipTeRouteOrigin                 Integer32,
               ipTeRouteIfIndex               Unsigned32
   }

   ipTeRoutePrid              OBJECT-TYPE

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

        ::= { ipTeRouteEntry 1 }

   ipTeRouteDestAddrType       OBJECT-TYPE

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

       ::= { ipTeRouteEntry 2 }

   ipTeRouteDest       OBJECT-TYPE

        SYNTAX         InetAddress
        STATUS         current

Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 8]


Internet Draft       An IP Traffic Engineering PIB            June 2002


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

        ::= { ipTeRouteEntry 3 }

   ipTeRouteMask       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 ipTeRouteMask bits length. All other bits
                in the mask, up to the number needed to fill the length
                of the address ipTeRouteDest are cleared to zero.  A
                zero bit in the mask then means that the corresponding
                bit in the address always matches.""

        ::= { ipTeRouteEntry 4 }

   ipTeRouteNextHopAddrType    OBJECT-TYPE

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

       ::= { ipTeRouteEntry 5 }

   ipTeRouteNextHopAddress     OBJECT-TYPE

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

        ::= { ipTeRouteEntry 6 }

   ipTeRouteNextHopMask        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 ipTeRouteNextHopMask bits length. All
                other bits in the mask, up to the number needed to fill

Jacquenet et al.    Experimental - Expires Dec. 2002            [Page 9]


Internet Draft       An IP Traffic Engineering PIB            June 2002


                the length of the address ipTeRouteNextHop are cleared
                to zero.  A zero bit in the mask then means that the
                corresponding bit in the address always matches."

        ::= { ipTeRouteEntry 7 }

   ipTeRoutePhbId      OBJECT-TYPE

        SYNTAX          Integer32 (-1 | 0..63)
        STATUS          current
        DESCRIPTION
                "The binary encoding that uniquely identifies a Per Hop
                Behaviour (PHB, [18]) or a set of PHBs associated to
                the DiffServ Code Point (DSCP, [15]) marking of the IP
                datagrams that will be conveyed along this traffic
                engineered 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."

        ::= { ipTeRouteEntry 8 }

   ipTeRouteOrigin     OBJECT-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."

        ::= { ipTeRouteEntry 9 }

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

        ::= { ipTeRouteEntry 10 }

   --
   --
   -- Traffic engineering metrics classes.

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 10]


Internet Draft       An IP Traffic Engineering PIB            June 2002


   --
   -- The information stored in the following tables is meant to provide
   -- the description of the metric values that will be taken into
   -- account by intra- and inter-domain routing protocols for the
   -- computation and the selection of traffic-engineered routes. So
   -- far, two tables have been identified: one which is based upon the
   -- traffic engineering extensions of OSPF, the other which is based
   -- upon the contents of a specific BGP4 attribute.
   --
   --
   igpTeGroup  OBJECT IDENTIFIER ::= { ipTeMetricsClasses  1 }
   bgpTeGroup  OBJECT IDENTIFIER ::= { ipTeMetricsClasses  2 }

   --
   -- The ospfTeMetricsTable
   --

   ospfTeMetricsTable  OBJECT-TYPE

        SYNTAX         SEQUENCE OF ospfTeMetricsEntry
        PIB-ACCESS     install-notify
        STATUS          current
        DESCRIPTION
                "This class describes the link and traffic engineering
                metrics that will be used by OSPF for TE route
                calculation purposes."

          ::= { igpTeGroup 1 }

   ospfTeMetricsEntry  OBJECT-TYPE

        SYNTAX          ospfTeMetricsEntry
        STATUS          current
        DESCRIPTION
                "The collection of OSPF metrics assigned to the router
                on a per interface and per DSCP basis."

        PIB-INDEX      { ospfTeMetricsPrid }
        UNIQUENESS     { ospfTeMetricsLinkMetricValue,
                          ospfTeMetricsDscpValue,
                          ospfTeMetricSubTlvLinkType,
                          ospfTeMetricSubTlvLinkId,
                          ospfTeMetricSubTlvLocalIfAddress,
                          ospfTeMetricSubTlvRemoteIfAddress,
                          ospfTeMetricSubTlvTeMetric,
                          ospfTeMetricSubTlvMaxBandwidth,
                          ospfTeMetricSubTlvMaxRsvBandwidth,
                          ospfTeMetricSubTlvUnRsvBandwidth,
                          ospfTeMetricIfIndex }

        ::= { ospfTeMetricsTable 1 }


Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 11]


Internet Draft       An IP Traffic Engineering PIB            June 2002


   ospfTeMetricsEntry ::= SEQUENCE {

               ospfTeMetricsPrid                      InstanceId,
               ospfTeMetricsIfMetricValue            Unsigned32,
               ospfTeMetricsDscpValue                Integer32,
               ospfTeMetricsTopTlvAddressType        InetAddressType,
               ospfTeMetricsTopTlvRouterAddress       InetAddress,
               ospfTeMetricsTopTlvRouterAddrMask      Unsigned32,
               ospfTeMetricsSubTlvLinkType           Unsigned32,
               ospfTeMetricsSubTlvLinkIdAddressType   InetAddressType,
               ospfTeMetricsSubTlvLinkId             InetAddress,
               ospfTeMetricsSubTlvLinkIdMask         Unsigned32,
               ospfTeMetricsSubTlvLocalIfAddressType  InetAddressType,
               ospfTeMetricsSubTlvLocalIfAddress      InetAddress,
               ospfTeMetricsSubTlvLocalIfAddrMask     Unsigned32,
               ospfTeMetricsSubTlvRemoteIfAddressType InetAddressType,
               ospfTeMetricsSubTlvRemoteIfAddress     InetAddress,
               ospfTeMetricsSubTlvRemoteIfAddrMask    Unsigned32,
               ospfTeMetricsSubTlvTeMetric           Unsigned32,
               ospfTeMetricsSubTlvMaxBandwidth        Unsigned32,
               ospfTeMetricsSubTlvMaxRsvBandwidth     Unsigned32,
               ospfTeMetricsSubTlvUnrsvBandwidth      Unsigned32,
               ospfTeMetricsSubTlvResourceClass       Unsigned32,
               ospfTeMetricsIfIndex                  Unsigned32
        }

   ospfTeMetricsPrid          OBJECT-TYPE

        SYNTAX                InstanceId
        STATUS                current
        DESCRIPTION
           "An integer index that uniquely identifies this instance of
           the ospfTeMetrics class."

        ::= { ospfTeMetricsEntry 1 }

   ospfTeMetricsIfMetricValue          OBJECT-TYPE

        SYNTAX         Unsigned32 (1..65535)
        STATUS         current
        DESCRIPTION
            "The link metric assigned on a per-DSCP and per-interface
            basis, as defined in this instance of the
            ospfTeMetricsTable."

        ::= { ospfTeMetricsEntry 2 }

   ospfTeMetricsDscpValue              OBJECT-TYPE

        SYNTAX         Integer32 (-1 | 0..63)
        STATUS         current
        DESCRIPTION

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 12]


Internet Draft       An IP Traffic Engineering PIB            June 2002


           "The DSCP value associated to the link metric value, as
           defined in the ospfTeMetricsIfMetricValue object. A value of
           -1 indicates that a specific DSCP value has not been defined
           and thus all DSCP values are considered a match."

        ::= { ospfTeMetricsEntry 3 }

   ospfTeMetricsTopTlvAddressType      OBJECT-TYPE

        SYNTAX         InetAddressType
        STATUS         current
        DESCRIPTION
           "The address type enumeration value used to specify the IP
           address of the advertising router. This IP address is always
           reachable, and is typically implemented as a "loopback"
           address."

        ::= { ospfTeMetricsEntry 4 }

   ospfTeMetricsTopTlvRouterAddress    OBJECT-TYPE

        SYNTAX        InetAddress
        STATUS        current
        DESCRIPTION
           "The IP address (typically a "loopback" address) of the
           advertising router."

        ::= { ospfTeMetricsEntry 5 }

   ospfTeMetricsTopTlvRouterAddrMask   OBJECT-TYPE

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

        ::= { ospfTeMetricsEntry 6 }

   ospfTeMetricsSubTlvLinkType         OBJECT-TYPE

        SYNTAX        INTEGER {
                              Point-to-Point (1)
                              Multiaccess (2)
                       }
        STATUS        current

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 13]


Internet Draft       An IP Traffic Engineering PIB            June 2002


        DESCRIPTION
           "The type of the link, either point-to-point or multi-
           access, as defined in [8]."

        ::= { ospfTeMetricsEntry 7 }

   ospfTeMetricsSubTlvLinkIdAddressType OBJECT-TYPE

        SYNTAX         InetAddressType
        STATUS         current
        DESCRIPTION
           "The address type enumeration value used to identify the
           other end of the link, described as an IP address."

        ::= { ospfTeMetricsEntry 8 }

   ospfTeMetricsSubTlvLinkId           OBJECT-TYPE

        SYNTAX         InetAddress
        STATUS         current
        DESCRIPTION
           "The identification of the other end of the link, described
           as an IP address."

        ::= { ospfTeMetricsEntry 9 }

   ospfTeMetricsSubTlvLinkMask         OBJECT-TYPE

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

        ::= { ospfTeMetricsEntry 10 }

   ospfTeMetricsSubTlvLocalIfAddressType       OBJECT-TYPE

        SYNTAX         InetAddressType
        STATUS         current
        DESCRIPTION
           "The address type enumeration value used to specify the IP
           address of the interface corresponding to this instance of
           the ospfTeMetricsSubTlvLinkType object."


Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 14]


Internet Draft       An IP Traffic Engineering PIB            June 2002


        ::= { ospfTeMetricsEntry 11 }

   ospfTeMetricsSubTlvLocalIfAddress           OBJECT-TYPE

        SYNTAX         InetAddress
        STATUS         current
        DESCRIPTION
           "Specifies the IP address of the interface of the
           advertising router which is connected to the link described
           as an instance of the ospfTeMetricsSubTlvLinkType object."

        ::= { ospfTeMetricsEntry 12 }

   ospfTeMetricsSubTlvLocalIfAddrMask          OBJECT-TYPE

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

        ::= { ospfTeMetricsEntry 13 }


   ospfTeMetricsSubTlvRemoteIfAddressType      OBJECT-TYPE

        SYNTAX         InetAddressType
        STATUS         current
        DESCRIPTION
           "The address type enumeration value used to specify the IP
           address(es) of the neighbour's interface corresponding to
           this instance of the ospfTeMetricsSubTlvLinkType object."

        ::= { ospfTeMetricsEntry 14 }

   ospfTeMetricSubTlvRemoteIfAddress   OBJECT-TYPE

        SYNTAX         InetAddress
        STATUS         current
        DESCRIPTION
           "Specifies the IP address of the neighbour's interface that
           is attached to this instance of the
           ospfTeMetricsSubTlvLinkType object."


Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 15]


Internet Draft       An IP Traffic Engineering PIB            June 2002


        ::= { ospfTeMetricsEntry 15 }

   ospfTeMetricSubTlvRemoteIfAddrMask  OBJECT-TYPE

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

        ::= { ospfTeMetricsEntry 16 }


   ospfTeMetricSubTlvTeMetric          OBJECT-TYPE

        SYNTAX         Unsigned32 (1..65535)
        STATUS         current
        DESCRIPTION
           "The link metric that has been assigned for traffic
           engineering purposes. This metric may be different from the
           ospfTeMetricsLinkMetricValue object of the ospfTeMetrics
           class."

        ::= { ospfTeMetricsEntry 17 }

   ospfTeMetricSubTlvBandwidthType     OBJECT-TYPE

        SYNTAX          Unsigned32 (0..4294967295)
        UNITS          "bytes per second"
        STATUS          current
        DESCRIPTION
           "Specifies the maximum bandwidth that can be used on this
           instance of the ospfTeMetricsSubTlvLinkType object in this
           direction (from the advertising router), expressed in bytes
           per second."

        ::= { ospfpTeMetricsEntry 18 }

   ospfTeMetricSubTlvMaxRsvBandwidth   OBJECT-TYPE

        SYNTAX         Unsigned32 (0..4294967295)
        UNITS          "bytes per second"
        STATUS          current
        DESCRIPTION

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 16]


Internet Draft       An IP Traffic Engineering PIB            June 2002


           "Specifies the maximum bandwidth that may be reserved on
           this instance of the ospfTeMetricsSubTlvLinkType object in
           this direction (from the advertising router), expressed in
           bytes per second."

        ::= { ospfTeMetricsEntry 19 }

   ospfTeMetricSubTlvUnrsvBandwidth    OBJECT-TYPE

        SYNTAX         Unsigned32 (0..4294967295)
        UNITS          "bytes per second"
        STATUS         current
        DESCRIPTION
           "Specifies the amount of bandwidth that has not been
           reserved on this instance of the ospfTeMetricsSubTlvLinkType
           object in this direction yet (from the advertising router),
           expressed in bytes per second."

        ::= { ospfTeMetricsEntry 20 }

   ospfTeMetricSubTlvResourceClass     OBJECT-TYPE

        SYNTAX         Unsigned32 (0..4294967295)
        STATUS         current
        DESCRIPTION
           "Specifies administrative group membership for the link in
           terms of a bit mask."

        ::= { ospfTeMetricsEntry 21 }

   ospfTeMetricIfIndex                 OBJECT-TYPE

        SYNTAX         Unsigned32 (0..65535)
        STATUS         current
        DESCRIPTION
           "The ifIndex value that identifies the local interface that
           has been assigned a (set of) metrics."

        ::= { ospfTeMetricsEntry 22 }

   --
   -- The isisTeMetricsTable
   --

   isisTeMetricsTable  OBJECT-TYPE

        SYNTAX         SEQUENCE OF isisTeMetricsEntry
        PIB-ACCESS     install-notify
        STATUS          current
        DESCRIPTION



Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 17]


Internet Draft       An IP Traffic Engineering PIB            June 2002


           "This class describes the link and traffic engineering
           metrics that will be used by IS-IS for TE route computation
           purposes."

        ::= { igpTeGroup 2 }

   isisTeMetricsEntry  OBJECT-TYPE

        SYNTAX          isisTeMetricsEntry
        STATUS          current
        DESCRIPTION
           "The collection of IS-IS metrics assigned to the router on a
           per interface basis."

        PIB-INDEX      { isisTeMetricsPrid }
        UNIQUENESS     {
                        isisTeMetricsSubTlvIfAddr,
                        isisTeMetricsSubTlvNbrAddr,
                       isisTeMetricSubTlvTeMetric,
                        isisTeMetricsSubTlvMaxLinkBwth,
                        isisTeMetricsSubTlvMaxRsvLinkBwth,
                        isisTeMetricsPriority,
                        isisTeMetricsSubTlvUnRsvBwth,
                       isisTeMetricsIfIndex }

        ::= { isisTeMetricsTable 1 }

   isisTeMetricsEntry ::= SEQUENCE {

                  isisTeMetricsPrid                    InstanceId,
                 isisTeMetricsTlvTeRouterID           InetAddress,
                 isisTeMetricsSubTlvIfAddrType         InetAddressType,
                  isisTeMetricsSubTlvIfAddr             InetAddress,
                  isisTeMetricsSubTlvIfAddrMask         Unsigned32,
                  isisTeMetricsSubTlvNbrAddType         InetAddressType,
                  isisTeMetricsSubTlvNbrAddr            InetAddress,
                  isisTeMetricsSubTlvNbrMask            Unsigned32,
                  isisTeMetricsSubTlvTeMetric                                                          Unsigned32,
                  isisTeMetricsSubTlvMaxLinkBwth                                                       Unsigned32,
                  isisTeMetricsSubTlvMaxRsvLinkBwth     Unsigned32,
                 isisTeMetricsPriority                Integer32,
                  isisTeMetricsSubTlvUnRsvBwth          Unsigned32,
                 isisTeMetricsIfIndex                  Unsigned32
        }

   isisTeMetricsPrid                   OBJECT-TYPE

        SYNTAX         InstanceId
        STATUS          current
        DESCRIPTION
           "An integer index that uniquely identifies this instance of
           the isisTeMetrics class."

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 18]


Internet Draft       An IP Traffic Engineering PIB            June 2002



        ::= { isisTeMetricsEntry 1 }

   isisTeMetricsTlvTeRouterID          OBJECT-TYPE

        SYNTAX         InetAddress
        STATUS         current
        DESCRIPTION
           "Specifies the router ID."

        ::= { isisTeMetricsEntry 2 }

   isisTeMetricsSubTlvIfAddrType        OBJECT-TYPE

        SYNTAX         InetAddressType
        STATUS         current
        DESCRIPTION
           "The address type enumeration value used to specify the type
           of the interface IP address."

        ::= { isisTeMetricsEntry 3 }

   isisTeMetricsSubTlvIfAddr           OBJECT-TYPE

        SYNTAX         InetAddress
        STATUS         current
       DESCRIPTION
           "Specifies the IP address of the interface."

        ::= { isisTeMetricsEntry 4 }

   isisTeMetricsSubTlvIfAddrMask       OBJECT-TYPE

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

        ::= { isisTeMetricsEntry 5 }

   isisTeMetricsSubTlvNbrAddrType      OBJECT-TYPE

        SYNTAX         InetAddressType
        STATUS         current
        DESCRIPTION

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 19]


Internet Draft       An IP Traffic Engineering PIB            June 2002


           "The address type enumeration value used to specify the type
           of the neighbouring router's IP address."

        ::= { isisTeMetricsEntry 6 }

   isisTeMetricsSubTlvNbrAddr          OBJECT-TYPE

        SYNTAX         InetAddress
        STATUS         current
        DESCRIPTION
           "Specifies the IP address of the neighbouring router on the
           link the corresponding interface (defined by the ifIndex) is
           attached to."

        ::= { isisTeMetricsEntry 7 }

   isisTeMetricsSubTlvNbrMask          OBJECT-TYPE

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

        ::= { isisTeMetricsEntry 8 }

   isisTeMetricsSubTlvTeMetric          OBJECT-TYPE

        SYNTAX         Unsigned32 (1..65535)
        STATUS         current
        DESCRIPTION
           "The traffic engineering default metric is used to present a
           differently weighted topology to TE-based SPF computations."

        ::= { isisTeMetricsEntry 9 }

   isisTeMetricsSubTlvMaxLinkBwth      OBJECT-TYPE

        SYNTAX          Unsigned32 (0..4294967295)
        UNITS          "bytes per second"
        STATUS          current
        DESCRIPTION
           "This metric specifies the maximum bandwidth that can be
           used on this link in this direction."

        ::= { isisTeMetricsEntry 10 }

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 20]


Internet Draft       An IP Traffic Engineering PIB            June 2002




   isisTeMetricsSubTlvMaxRsvLinkBwth   OBJECT-TYPE

        SYNTAX         Unsigned32 (0..4294967295)
        UNITS          "bytes per second"
        STATUS          current
        DESCRIPTION
           "Specifies the maximum bandwidth that may be reserved on
           this link in this direction, expressed in bytes per second."

        ::= { isisTeMetricsEntry 11 }

   isisTeMetricsPriority               OBJECT-TYPE

        SYNTAX         Integer32 (0..7)
        STATUS         current
        DESCRIPTION
           "Specifies one of the eight priority levels, possible values
           ranging from 0 and 7."

        ::= { isisTeMetricsEntry 12}


   isisTeMetricsSubTlvUnRsvBwth        OBJECT-TYPE

        SYNTAX         Unsigned32 (0..4294967295)
        UNITS          "bytes per second"
        STATUS         current
        DESCRIPTION
           "Specifies the amount of bandwidth that has not been
           reserved on this link in this direction and having the
           priority isisTeMetricsPriority, expressed in bytes per
           second."

        ::= { isisTeMetricsEntry 13 }

   isisTeMetricsIfIndex                 OBJECT-TYPE

        SYNTAX         Unsigned32 (0..65535)
        STATUS         current
        DESCRIPTION
           "The ifIndex value that uniquely identifies the interface
           that has been assigned a (set of) metrics."

        ::= { isisTeMetricsEntry 14 }

   --
   -- The bgpTeTable
   --

   bgpTeTable          OBJECT-TYPE

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 21]


Internet Draft       An IP Traffic Engineering PIB            June 2002



        SYNTAX         SEQUENCE OF bgpTeEntry
        PIB-ACCESS     install-notify
        STATUS          current
        DESCRIPTION
                "This class describes the QoS information that MAY be
                conveyed in BGP4 UPDATE messages for the purpose of
                enforcing an inter-domain traffic engineering policy."

          ::= { bgpTeGroup 1 }

   bgpTeEntry          OBJECT-TYPE

        SYNTAX          bgpTeEntry
        STATUS          current
        DESCRIPTION
                "The collection of QoS information to be exchanged by
                BGP peers, as far as the announcement of traffic
                engineered routes between domains is concerned."

        PIB-INDEX      { bgpTePrid }
        UNIQUENESS     { bgpTeNlriAddress,
                         bgpTeNextHopAddress,
                         bgpTeReservedRate,
                         bgpTeAvailableRate,
                         bgpTeLossRate,
                         bgpTePhbId,
                         bgpTeMinOneWayDelay,
                         bgpTeMaxOneWayDelay,
                         bgpTeAverageOneWayDelay,
                         bgpTeInterPacketDelay }

        ::= { bgpTeTable 1 }

   bgpTeEntry ::= SEQUENCE {

               bgpTePrid                       InstanceId,
               bgpTeNlriAddressType           InetAddressType,
               bgpTeNlriAddress               InetAddress,
               bgpTeNlriAddressMask           Unsigned32,
               bgpTeNextHopAddressType        InetAddressType,
               bgpTeNextHopAddress            InetAddress,
               bgpTeNextHopMask               Unsigned32,
               bgpTeReservedRate              Unsigned32,
               bgpTeAvailableRate             Unsigned32,
               bgpTeLossRate                  Unsigned32,
               bgpTePhbId                     Integer32,
               bgpTeMinOneWayDelay            Unsigned32,
               bgpTeMaxOneWayDelay            Unsigned32,
               bgpTeAverageOneWayDelay         Unsigned32,
               bgpTeInterPacketDelay          Unsigned32
        }

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 22]


Internet Draft       An IP Traffic Engineering PIB            June 2002



   bgpTePrid                  OBJECT-TYPE

        SYNTAX                InstanceId
        STATUS                current
        DESCRIPTION
            "An integer index that uniquely identifies this instance of
            the bgpTeTable class."

        ::= { bgpTeEntry 1 }

   bgpTeNlriAddressType        OBJECT-TYPE

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

       ::= { bgpTeEntry 2 }

   bgpTeNlriAddress           OBJECT-TYPE

        SYNTAX                InetAddress
        STATUS                current
        DESCRIPTION
            "The IP address to match against the NLRI field of the
            QOS_NLRI attribute of the BGP4 UPDATE message."

        ::= { bgpTeEntry 3 }

   bgpTeNlriAddressMask        OBJECT-TYPE

        SYNTAX                Unsigned32 (0..128)
        STATUS                current
        DESCRIPTION
            "Indicates the length of a mask for the matching of the
            NLRI field of the QOS_NLRI attribute of the BGP4 UPDATE
            message. Masks are constructed by setting bits in sequence
            from the most-significant bit downwards for bgpTeNlriMask
            bits length. All other bits in the mask, up to the number
            needed to fill the length of the address bgpTeNlri are
            cleared to zero.  A zero bit in the mask then means that
            the corresponding bit in the address always matches.""

        ::= { bgpTeEntry 4 }

   bgpTeNextHopAddressType     OBJECT-TYPE

        SYNTAX                InetAddressType
        STATUS                current
        DESCRIPTION

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 23]


Internet Draft       An IP Traffic Engineering PIB            June 2002


            "The address type enumeration value used to specify the
            type of the next hop's IP address."

       ::= { bgpTeEntry 5 }

   bgpTeNextHopAddress         OBJECT-TYPE

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

        ::= { bgpTeEntry 6 }

   bgpTeNextHopMask           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 bgpTeNextHopMask bits length. All other bits in the
            mask, up to the number needed to fill the length of the
            address bgpTeNextHopAddress are cleared to zero.  A zero
            bit in the mask then means that the corresponding bit in
            the address always matches."

        ::= { bgpTeEntry 7 }

   bgpTeReservedRate          OBJECT-TYPE

        SYNTAX                 Unsigned32 (0..4294967295)
        UNITS                 "kilobits per second"
        STATUS                 current
        DESCRIPTION
            "Specifies the reserved rate that cannot be used on this
            instance of the bgpTeNlriAddress object in this direction
            (from the advertising BGP peer), expressed in kilobits per
            second."

        ::= { bgpTeEntry 8 }

   bgpTeAvailableRate         OBJECT-TYPE

        SYNTAX                 Unsigned32 (0..4294967295)
        UNITS                 "kilobits per second"
        STATUS                 current
        DESCRIPTION
            "Specifies the available rate that may be reserved on this
            instance of the bgpTeNlriAddress object in this direction

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 24]


Internet Draft       An IP Traffic Engineering PIB            June 2002


            (from the advertising BGP peer), expressed in kilobits per
            second."

        ::= { bgpTeEntry 9 }

   bgpTeLossRate              OBJECT-TYPE

        SYNTAX                 Unsigned32 (0..4294967295)
        STATUS                 current
        DESCRIPTION
            "Specifies the packet loss ratio that has been observed on
            this route instantiated by the bgpTeNlriAddress object."

        ::= { bgpTeEntry 10 }

   bgpTePhbId                 OBJECT-TYPE

        SYNTAX                 Integer32 (-1 | 0..63)
        STATUS                 current
        DESCRIPTION
            "The binary encoding that uniquely identifies a Per Hop
            Behaviour (PHB) or a set of PHBs associated to the DiffServ
            Code Point marking of the IP datagrams that are to be
            conveyed along this traffic engineered 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."

        ::= { bgpTeEntry 11 }

   bgpTeMinOneWayDelay        OBJECT-TYPE

        SYNTAX                 Unsigned32 (0..4294967295)
        UNITS                 "milliseconds"
        STATUS                 current
        DESCRIPTION
            "Specifies the minimum one-way delay that has been observed
            on this route instantiated by the bgpTeNlriAddress object,
            expressed in milliseconds."

        ::= { bgpTeEntry 12 }

   bgpTeMaxOneWayDelay        OBJECT-TYPE

        SYNTAX                 Unsigned32 (0..4294967295)
        UNITS                 "milliseconds"
        STATUS                 current
        DESCRIPTION
            "Specifies the maximum one-way delay that has been observed
            on this route instantiated by the bgpTeNlriAddress object,
            expressed in milliseconds."


Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 25]


Internet Draft       An IP Traffic Engineering PIB            June 2002


        ::= { bgpTeEntry 13 }

   bgpTeAverageOneWayDelay     OBJECT-TYPE

        SYNTAX                 Unsigned32 (0..4294967295)
        UNITS                 "milliseconds"
        STATUS                 current
        DESCRIPTION
            "Specifies the average one-way delay that has been observed
            on this route instantiated by the bgpTeNlriAddress object,
            expressed in milliseconds."

        ::= { bgpTeEntry 14 }

   bgpTeInterPacketDelay       OBJECT-TYPE

        SYNTAX                 Unsigned32 (0..4294967295)
        UNITS                 "milliseconds"
        STATUS                 current
        DESCRIPTION
            "Specifies the inter-packet delay variation that has been
            observed on this route instantiated by the bgpTeNlriAddress
            object."

        ::= { bgpTeEntry 15 }

   --
   -- Traffic engineering statistics classes. The information contained
   -- in the yet-to-be defined tables aim at reporting statistics about
   -- COPS control traffic, engineered traffic and potential errors. The
   -- next version of the draft will provide a first table that will be
   -- based upon the use of the "count" clause.
   --
   --

   END

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

Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 26]


Internet Draft       An IP Traffic Engineering PIB            June 2002


   ([19]) protocol suite be used to secure the above-mentioned
   authorized communication.

8. References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.
   [2]  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.
   [3]  Jacquenet, C., "A COPS Client-Type for IP Traffic Engineering",
        draft-jacquenet-ip-te-cops-03.txt, Work in Progress, June 2002.
   [4]  Fine, M., et al., "Framework Policy Information Base", draft-
        ietf-rap-frameworkpib-07.txt, Work in Progress, January 2002.
   [5]  Goderis, D., T'Joens, Y., Jacquenet, C., Memenios, G., Pavlou,
        G., Egan, R., Griffin, D., Georgatsos, P., Georgiadis, L.,
        "Specification of a Service Level Specification (SLS)
        Template", draft-tequila-sls-02.txt, Work in Progress, February
        2002. Check http://www.ist-tequila.org for additional
        information.
   [6]  Moy J.,"OSPF Version 2", RFC 2328, April 1998.
   [7]  Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC
        1771, March 1995.
   [8]  Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
        Extensions to OSPF", draft-katz-yeung-ospf-traffic-06.txt, Work
        in Progress, October 2001.
   [9]  Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering",
        draft-ietf-isis-traffic-04.txt, Work in Progress, August 2001.
   [10] 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.
   [11] Jacquenet, C., "Providing Quality of Service Indication by the
        BGP-4 Protocol: the QOS_NLRI Attribute", draft-jacquenet-qos-
        nrli-04.txt, Work in Progress, March 2002.
   [12] Moore, B. et al., "Policy Core Information Model -- Version 1
        Specification", RFC 3060, February 2001.
   [13] McLoghrie, K., et al., "Structure of Policy Provisioning
        Information (SPPI)", RFC 3159, August 2001.
   [14] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997
   [15] Case, J., et al., "A Simple Network Management Protocol", RFC
        1157, May 1990.
   [16] Guerin, R., et al., "QoS Routing Mechanisms and OSPF
        Extensions", RFC 2676, August 1999.
   [17] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J.,
        "Textual Conventions for Internet Network Addresses", RFC 3291,
        May 2002.
   [18] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop
        Behaviour Identification Codes", RFC 3140, June 2001.



Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 27]


Internet Draft       An IP Traffic Engineering PIB            June 2002



   [19] Kent, S., Atkinson, R., "Security Architecture for the Internet
        Protocol", RFC 2401, November 1998.

9. Acknowledgments

   Part of this work is funded by the European Commission, within the
   context of the TEQUILA (Traffic Engineering for Quality of Service in
   the Internet At Large Scale, [5]) project, which is itself part of
   the IST (Information Society Technologies) research program.

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


10. Authors' Addresses

   Mohamed Boucadair, Christian Jacquenet
   France Telecom R & D
   DMI/SIR
   42, rue des Coutures
   BP 6243
   14066 Caen Cedex 4
   France
   Phone: +33 2 31 75 94 28
   Email: {mohamed.boucadair, christian.jacquenet}@rd.francetelecom.com


Full Copyright Statement

   Copyright (C) The Internet Society (2002). 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.



Jacquenet et al.    Experimental - Expires Dec. 2002           [Page 28]


Internet Draft       An IP Traffic Engineering PIB            June 2002


   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 Dec. 2002           [Page 29]