One document matched: draft-jacquenet-ip-te-pib-02.txt
Differences from draft-jacquenet-ip-te-pib-01.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 04:21:17 |