Network Working Group M. Boucadair
Internet Draft C. Jacquenet
Document: draft-jacquenet-ip-te-pib-01.txt France Telecom R&D
Category: Experimental November 2001
Expires May 2002
An IP Traffic Engineering Policy Information Base
<draft-jacquenet-ip-te-pib-01.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 will 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 last version..............................3
4. Scalability considerations..................................4
4.1. A tentative metric taxonomy.................................4
4.2. Reporting the Enforcement of an IP Traffic Engineering
Policy....................................................5
5. PIB Overview................................................5
Jacquenet et al. Experimental - Expires May 2002 [Page 1]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
6. The IP Traffic Engineering Policy Information Base..........6
7. Security Considerations....................................22
8. References.................................................23
9. Acknowledgments............................................24
10. Authors' Addresses.........................................24
1. Introduction
The deployment of value-added IP services (like QoS (Quality of
Service)-based IP Virtual Private Networks) over the Internet has
become one of the most competing challenges for service providers, as
well as a complex technical issue, as far as the appropriate
provisioning and usage of the resources of the IP networks is
concerned.
From this standpoint, the COPS protocol and its usage for the support
of Policy Provisioning ([2]) is one of the ongoing specification
effort of the Resource Allocation Protocol (rap) Working Group of the
IETF that should help service providers in dynamically enforcing an
IP Traffic Engineering (IP TE) policy which happens to be one the key
components to service customers according to the contents of the
contractual agreements they have signed with their service
provider(s).
Indeed, the enforcement of an IP traffic engineering policy is based
upon the use 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.
As such, an IP traffic engineering policy (partly) 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]).
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 ([6], [7])
that will be activated in the network to appropriately 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 exactly reflect these QoS
requirements, given the dynamic routing protocols support traffic
engineering capabilities for the calculation and the selection of
such routes.
Jacquenet et al. Experimental - Expires May 2002 [Page 2]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
These capabilities are currently being specified in [8] and [9] for
the OSPF (Open Shortest Path First, [5]) and the IS-IS (Intermediate
System to Intermediate System routing protocol, [10]) interior
routing protocols respectively, while there is an equivalent and
ongoing specification effort for the BGP4 (Border Gateway Protocol,
version 4) protocol, as described in [11], for example.
To provide the route selection processes with the above-mentioned
information, one possibility is to use the COPS protocol and its
usage for policy provisioning, together with a collection of
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 are
based upon the use of above-mentioned extensions to existing IP
routing protocols - namely the OSPF and the BGP4 protocols, and which
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 last version
- Section 6 has been updated according to the semantics rules
introduced in [13],
- The PIB itself has been slightly reorganized to introduce an
additional level of hierarchy, so that the IP TE provisioning
information is now classified into three main classes - the "route
information" classes, the "traffic engineering metrics" classes,
and the "statistics" classes. Next versions of the draft will
complement each of these classes as appropriate,
Jacquenet et al. Experimental - Expires May 2002 [Page 3]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
- The references section has been updated,
- The authors' list has been updated.
4. Scalability considerations
The usage of the COPS-PR protocol for the dynamic enforcement of an
IP traffic engineering policy that would be based upon the use of
traffic engineering extensions to IP routing protocols naturally
raises the scalability issue, 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.
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 dynamic 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 SPF algorithms for
IP TE route calculation can be classified into two basic categories:
1. Permanently assigned metrics, which basically consist of the
"usual" cost metrics, as per [6]. These metrics are those that
are assigned on a per (logical) interface basis, and they aim at
reflecting the link quality the corresponding interface is
attached to. Such metrics can also be derived on a per-DSCP
basis, so that a given interface will be assigned different
costs, depending on the value of the DS field,
2. Dynamically assigned metrics, which MAY consist of the following
information:
- The available bandwidth, (e.g. based upon the SNMP (Simple
Network Management Protocol) variables like ifType,
ifInOctets and ifOutOctets),
- The amount of bandwidth that can be reserved, according to
arithmetic calculation based upon the above-mentioned
variables, for example,
- The amount of reserved bandwidth, according to the
information maintained in the PIB.
While statically assigned metric values should not change frequently
by definition (because they reflect the physical resources of the
network as they are available, as well as the generic routing policy
that has been defined by the network administrator to reflect how
such resources will be used), the dynamically assigned metric values
MAY vary like the ongoing usage of the resources of the network.
Jacquenet et al. Experimental - Expires May 2002 [Page 4]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
Therefore, the static or dynamic computation of dynamically assigned
metric values is in the magnitude of the corresponding SPF
computation, since newly assigned values yield the spontaneous
generation of LSU (Link State Update, [6]) messages. Hence, the IP
traffic engineering provisioning data exchange SHOULD be minimized
according to pre-computation engineering recommendations like those
described in [15].
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 above-mentioned requirements, without any extra
computation (within the context of [5], for example).
From this perspective, the report of the installed routes is in the
magnitude of the route announcement procedures of the IP routing
protocols machineries (like OSPF), and it is therefore 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 deploying an IP traffic engineering policy that
should raise scalability issues, NOT the choice of activating the
COPS-PR protocol as a means to convey the IP TE provisioning data
that will reflect such a deployment.
Nevertheless, it is obviously one of the most important concerns of
the ongoing specification and development effort that is partly
reflected by this draft, and which is further described in [5]. In
particular, it is the intention of the author 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 is based
upon the activation of intra- and inter-domain routing protocols that
will have the ability to take into account traffic engineering-
related information for the calculation and the selection of routes,
which will comply as much as possible with the QoS requirements that
Jacquenet et al. Experimental - Expires May 2002 [Page 5]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
have been contractually defined between customers and service
providers.
This traffic engineering-related information is basically composed of
metric values (as they have been depicted in [8] for the traffic
engineering extensions to the OSPF protocol, for example) 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 automation (which can be expressed in
terms of accessing the service, for example) and 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 calculate 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.
From this perspective, the IP TE PIB is currently organized into the
following provisioning classes:
1. The OSPF TE Metrics Table: this class represents the collection
of provisioning data that will reflect a specific intra-domain
routing policy, in terms of TE metric value assignment,
2. The BGP TE Table: this class aims at depicting the BGP routes
that have been announced by the routers with associated QoS
information,
3. The IP TE Route Table: this class describes the information
related to the traffic engineered routes that have been
installed by the routers in their FIB bases, according to the
traffic engineering policy they will have to enforce.
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
Jacquenet et al. Experimental - Expires May 2002 [Page 6]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
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"
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.
--
--
--
Jacquenet et al. Experimental - Expires May 2002 [Page 7]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
-- 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
STATUS current
DESCRIPTION
"A particular traffic engineered route to a particular
destination."
PIB-INDEX { ipTeRoutePrid }
UNIQUENESS { ipTeRouteDest,
ipTeRouteMask,
ipTeRoutePhbId,
ipTeRouteNextHopAddress
ipTeRouteNextHopMask }
::= { 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."
Jacquenet et al. Experimental - Expires May 2002 [Page 8]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
::= { ipTeRouteEntry 1 }
ipTeRouteDestAddrType OBJECT-TYPE
SYNTAX InetAddressType
STATUS current
DESCRIPTION
"The address type enumeration value ([16]) used to
specify the type of a route's destination IP address."
::= { ipTeRouteEntry 2 }
ipTeRouteDest OBJECT-TYPE
SYNTAX InetAddress
STATUS current
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
Jacquenet et al. Experimental - Expires May 2002 [Page 9]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
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
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, [17]) 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."
Jacquenet et al. Experimental - Expires May 2002 [Page 10]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
::= { 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.
--
-- 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. Next versions of
-- the draft will include IS-IS specific information, as well as
-- extensions of the BGP4-specific provisioning information for the
-- "basic" enforcement of a BGP4 routing policy.
--
--
--
-- 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."
::= { ipTeMetricsClasses 1 }
ospfTeMetricsEntry OBJECT-TYPE
SYNTAX ospfTeMetricsEntry
STATUS current
DESCRIPTION
Jacquenet et al. Experimental - Expires May 2002 [Page 11]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
"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 }
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,
ospfTeMetricsIfIndex Unsigned32
}
ospfTeMetricsPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An integer index that uniquely identifies this instance of
the ospfTeMetrics class."
::= { ospfTeMetricsEntry 1 }
Jacquenet et al. Experimental - Expires May 2002 [Page 12]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
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
"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
Jacquenet et al. Experimental - Expires May 2002 [Page 13]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
"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
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-
Jacquenet et al. Experimental - Expires May 2002 [Page 14]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
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."
::= { 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
Jacquenet et al. Experimental - Expires May 2002 [Page 15]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
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."
::= { 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
Jacquenet et al. Experimental - Expires May 2002 [Page 16]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
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
"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 }
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 21 }
--
-- The bgpTeTable
--
Jacquenet et al. Experimental - Expires May 2002 [Page 17]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
bgpTeTable OBJECT-TYPE
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."
::= { ipTeMetricsClasses 2 }
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 May 2002 [Page 18]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
}
bgpTePrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An integer index that uniquely identifies this instance of
the bgpTe class."
::= { bgpTeEntry 1 }
bgpTeNlriAddressType OBJECT-TYPE
SYNTAX InetAddressType
STATUS current
DESCRIPTION
"The address type enumeration value ([18]) 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
Jacquenet et al. Experimental - Expires May 2002 [Page 19]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
STATUS current
DESCRIPTION
"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
Jacquenet et al. Experimental - Expires May 2002 [Page 20]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
"Specifies the available rate that may be reserved on this
instance of the bgpTeNlriAddress object in this direction
(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
Jacquenet et al. Experimental - Expires May 2002 [Page 21]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
"Specifies the maximum one-way delay that has been observed
on this route instantiated by the bgpTeNlriAddress object,
expressed in milliseconds."
::= { 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.
Jacquenet et al. Experimental - Expires May 2002 [Page 22]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
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
([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-02.txt, Work in Progress, June 2001.
[4] Fine, M., et al., "Framework Policy Information Base", draft-
ietf-rap-frameworkpib-05.txt, Work in Progress, July 2001.
[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-01.txt, Work in Progress, June
2001. 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-03.txt, Work in Progress, July 2001.
[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] Guerin, R., et al., "QoS Routing Mechanisms and OSPF
Extensions", RFC 2676, August 1999.
[16] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J.,
"Textual Conventions for Internet Network Addresses", RFC 2851,
June 2000.
Jacquenet et al. Experimental - Expires May 2002 [Page 23]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
[17] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop
Behaviour Identification Codes", RFC 3140, June 2001.
[18] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J.,
"Textual Conventions for Internet Network Addresses", RFC 2851,
June 2000.
[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
Mohammed 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 (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, 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.
Jacquenet et al. Experimental - Expires May 2002 [Page 24]
Internet Draft An IP Traffic Engineering PIB Nov. 2001
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 May 2002 [Page 25]