Internet Engineering Task Force
INTERNET-DRAFT
July 2000
Francis Reichmeyer
IPHighway
Steven Wright
BellSouth
Mark Gibson
Nortel Networks
COPS Usage for MPLS/Traffic Engineering
<draft-franr-mpls-cops-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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 made obsolete 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.''
To view the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in an Internet-Drafts
Shadow Directory, see http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This draft describes the application of the COPS for Provisioning
(COPS-PR) protocol for managing MPLS and its traffic engineering
functionality. A new COPS client type is described, the COPS-MPLS
client type, and the use of the basic COPS messages by this client
type is described.
Reichmeyer, et. al. [Page 1]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
Table of Contents
1. Introduction.....................................................3
2. MPLS/TE Policy Management Model..................................5
3. COPS-MPLS Policy Management......................................6
3.1. COPS-MPLS Client Type.......................................6
3.2. MPLS/TE PIBs................................................7
3.3. Client Handles..............................................7
3.4. Request States..............................................8
4. COPS-MPLS Messages...............................................8
4.1. Protocol Objects............................................9
4.2. Request Message.............................................9
4.3. Decision Message............................................9
4.4. Report Message..............................................9
5. Common Operations...............................................10
6. Security Considerations.........................................12
7. References......................................................12
8. Author's Addresses..............................................13
9. Full Copyright Statement........................................13
Reichmeyer, et. al. Expires December 2000 [Page 2]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
1. Introduction
This document describes how COPS can be used in an MPLS network for
managing MPLS and Traffic Engineering. A new client type is
described, the COPS-MPLS client type, which defines the usage of
the COPS-PR protocol specification for MPLS and Traffic
Engineering.
Policy controls enable improved administrative control of network
capabilities to meet service objectives. MPLS provides efficient
explicit routing capabilities for IP networks, a key element in the
traffic engineering of those networks. A goal of specifying a
policy control protocol for MPLS is to enable improved network
service implementations.
A primary concern in traffic engineering is the classification and
proper handling of different traffic within the network [TE/MPLS].
For example, forwarding certain flows along a path known to have
the necessary resources for the type and amount of traffic in the
flow, even if the path is different from the hop-by-hop routed
path. The use of MPLS for traffic engineering requires configuring
the LSRs in the network to support this type of TE functionality,
then applying admission control policy at the ingress to the
network to manage the usage of the resources.
In general, there are two basic categories of policies for MPLS/TE
management: LSP/tunnel management (or LSP life cycle) policies and
LSP admission control (or flow management) policies. LSP/tunnel
management policy deals with LSR configuration related to
initiating, maintaining, and removing LSPs/tunnels. LSP admission
control policy deals with classification directives for mapping
data flows onto LSPs/tunnels according to characteristics of the
data packets and traffic engineering objectives. In effect, these
policies define finer-grained forwarding equivalence classes (FECs)
for a tunnel and map them to a label for the tunnel. Policy
management coordinates the two types of policy in the MPLS network
and enables policy-based administration for a number of traffic
engineering objectives e.g. protection, load distribution [LOAD-
DIS], etc.
MPLS supports explicit traffic engineering via several mechanisms
that allow LSPs to be managed based on QoS and other constraints,
for example [CR-LDP] and [RSVP-TE]. The architecture of the policy
management system used to control MPLS/traffic engineering
functionality should be independent of the MPLS mechanisms used. It
is these mechanisms that we target with policy management. That is,
the focus here is on managing MPLS mechanisms to provide
consistent, predictable network services.
Reichmeyer, et. al. Expires December 2000 [Page 3]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
Note that although LSPs can also be established via the LDP label
distribution protocol, for the purpose of traffic engineering, this
is less interesting and generally are not considered in the context
of MPLS policy management. This may change in future versions of
this draft if/when the scope of MPLS policy management is expanded
beyond its current traffic engineering focus. Also, non-MPLS
networks may in the future use COPS for managing some TE functions,
but these are beyond the scope of the current draft.
The CR-LDP and RSVP-TE label distribution mechanisms considered
here share similar attributes that are exploited by the COPS-MPLS
client specification. In the effort to achieve abstraction of
policy throughout the policy management system, the details of the
underlying MPLS label distribution should not affect the policy
protocol (e.g. COPS-MPLS), though it will show up in the data model
(e.g. MPLS/TE PIB) defined for use with the protocol. For example,
the way in which LSP/tunnels are uniquely identified in the two
label distribution mechanisms is different and since the policy
system needs to identify LSP/tunnels for flow management policies,
it needs to be aware of the different formats. This is done through
the data model specifying classes and/or parameters specific to the
use of CR-LDP or RSVP-TE. Also, then, if one of the MPLS mechanisms
were to be extended or amended to support some new TE functionality
in the future, the protocol need not change, just the data model.
This example highlights the advantage of separating the protocol
from the data model, as done, for example, with COPS-PR and PIBs.
The primary benefit of policy-based networking within the context
of MPLS networks is in the area of management of traffic
engineering features and functions offered by the MPLS
specifications. When we refer to MPLS policy, then, we are usually
referring to configuration and policy management with respect to
traffic engineering as achieved by MPLS mechanisms. That is, this
draft does not consider general purpose configuration management
for MPLS LSRs, just those mechanisms related to traffic
engineering.
Policy control for MPLS provides a richer environment for the
creation of network services in an efficient manner. The use of a
higher abstraction level policy specification provides a mechanism
to abstract away some of the implementation options within MPLS,
such as label distribution protocols used to create tunnels. While
MPLS may be operated in an autonomous fashion, e.g. with topology
driven LSP establishment, this does not necessarily provide the
explicit routes and QoS required for traffic engineering. Also,
while manual establishment of explicit route LSPs with associated
QoS parameters may be feasible, this is expected to have some
issues of scale, and consistency when applied in large networks.
The COPS-PR protocol is well suited for MPLS and Traffic
Engineering policy and configuration management. Separation of
policy protocol (COPS-PR) and data model (e.g. PIB) accommodates
the higher level abstraction required for MPLS policy control.
Reichmeyer, et. al. Expires December 2000 [Page 4]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
Also, applying COPS-PR to the MPLS/TE environment allows us to re-
use the existing work on Diff Serv policy management. This draft
describes the application of COPS-PR for use in managing MPLS/TE in
IP network environments.
2. MPLS/TE Policy Management Model
When thinking about defining the COPS-MPLS client type and COPS
usage for MPLS/TE policy management, we need to consider which
policy management model is appropriate. For LSP admission control
policy, the provisioning model of COPS-PR is a good fit. For
LSP/tunnel management, however, the outsourcing model of COPS-RSVP
might be considered since MPLS supports RSVP-TE for label
distribution.
Although RSVP-TE is supported in MPLS, this use of the RSVP
protocol is slightly different than the way it is supported by
COPS-RSVP. In MPLS, an RSVP-TE session is initiated by an edge LSR,
as opposed to an end station. This implies that the initiating LSR
must be configured or somehow directed to start the session by
sending a Path message to the appropriate destination. A natural
place to decide to setup an LSP/tunnel, and tell the LSR to
initiate the setup, is in the PDP. But COPS-RSVP is designed for
the PDP to issue policy decisions based on requests triggered by
RSVP messages received at edge routers. For the PDP to initiate the
RSVP-TE session, it needs to send an unsolicited message to the LSR
containing the parameters for the Path message, such as resource
requirements, explicit route information, etc. Sending this
unsolicited decision fits more closely with the provisioning model
of COPS-PR.
In MPLS, with RSVP-TE, the PEP does not necessarily outsource a
policy decision with regards to allowing the reservation since, as
discussed above the PDP initiates the reservation. For example when
a Resv message is received at an ingress LSR, the router notifies
the PDP that resources have (or have not) been reserved for a
tunnel but does not necessarily need to ask the PDP if it should be
allowed. The PDPÆs decision, then, is not whether to accept or deny
the reservation request, but to issue a LSP admission control
policy for the tunnel.
Thus, although RSVP-TE is supported in MPLS, the policy management
model it calls for is different than that of COPS-RSVP and is more
similar to the COPS-PR model. So, COPS-MPLS described in this draft
is based on COPS-PR.
Both CR-LDP and RSVP-TE label distribution mechanisms may
potentially need to be supported in an MPLS network. At the policy
protocol level, the details of whether one mechanism or the other,
or both, are used to establish a tunnel should be abstracted away.
What are of interest is the ability for policy control to:
- establish the tunnel with some set of constraints
Reichmeyer, et. al. Expires December 2000 [Page 5]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
- uniquely identify the tunnel
- define flow management policy for the tunnel.
Using the provisioning model of COPS-PR and separate data model,
for example an MPLS/TE PIB, allows us to isolate the details of the
label distribution mechanism in the data model. The LSR notifies
the PDP of the label distribution mechanism(s) it supports, for
example by advertising its capabilities to the PDP, and the PDP
provides decisions including the parameters needed by that
mechanism. The LSR then uses the data to initiate the tunnel with
whichever mechanism it supports. This also makes it easier to
expand support for new traffic engineering features that may be
added to MPLS in the future, by updating just the data model and
not the protocol.
Also, it is already necessary to define a COPS-PR based protocol
and data model for COPS-MPLS to support packet classification for
LSP admission control policy, and LSR capability notification to
the PDP. So extending that model for general LSP/tunnel policy
saves the work and confusion of defining two policy management
protocols for MPLS/TE policy.
3. COPS-MPLS Policy Management
This section describes the application of COPS-PR protocol features
to the COPS-MPLS policy management model.
3.1. COPS-MPLS Client Type
The COPS-PR architecture [COPS-PR] provides the flexibility to
define different client types that can all make use of the COPS-PR
protocol specification and policy management model. Differentiation
among client types is made when the COPS client in the PEP (Policy
Enforcement Point) opens a connection to the COPS server in the PDP
(Policy Decision Point), specifying the client type. Each client
type uses the basic COPS messages to exchange general and client
specific policy information between the PDP and PEP.
In an MPLS environment, the PEP resides in the LSRs (Label Switch
Routers) that require a connection to the policy server. A router
MAY contain multiple COPS clients of different type, e.g a Diff
Serv provisioning client, COPS-MPLS client, etc., depending on the
different functions the router performs in the network (Diff Serv
router, LSR, etc.) Each client opens a separate COPS connection to
the PDP, over a single TCP connection using the Client-type to
distinguish between them [COPS]. An LSR opening a connection to a
PDP for MPLS/TE policy management MUST use the COPS-MPLS Client-
type defined here.
The COPS client type is used to differentiate between different
types of policy data that will be exchanged between a COPS client
and COPS server. For example, different classes of policy data, as
defined in the PIB [FRAME-PIB], are accessed by different COPS
Reichmeyer, et. al. Expires December 2000 [Page 6]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
client types. In the case of the COPS-MPLS client type, there will
be defined, in a separate draft, the appropriate policy data model
in the form of an MPLS/TE PIB.
3.2. MPLS/TE PIBs
As part of the specification of COPS usage for MPLS and TE, we need
to define the data model for the MPLS/TE policy information
exchanged between the PEP and PDP. One possible data model will be
defined in an accompanying MPLS/TE PIB draft [MPLS-PIB]. Other data
models may be defined as well. MPLS/TE PIBs specify the data
content carried in COPS-MPLS client specific objects. For example,
QoS constraints, explicit route information, and other parameters
for LSP tunnel configuration are carried in COPS Decision messages
to tell an edge LSR to initiate the tunnel setup.
MPLS-specific device capabilities may also be defined in the
MPLS/TE PIB. For example information about label spaces used by the
LSR, or label distribution mechanism(s) supported, may be sent to
the PDP by the LSR in the initial Request message. The PDP could
then use this information when generating policy decisions that
affect the LSR.
MPLS/TE PIBs are also used for coordinating MPLS policy and other
related policy, such as Diff Serv, on an interface via the
specification and distribution of policy rules based on roles and
interface types.
The intent when defining the MPLS/TE PIB classes is to make use of
existing PIB modules already defined for Diff Serv [DS-PIB] as well
as those defined for all COPS-PR client types [FRAME-PIB]. Indeed,
the MPLS/TE PIB should contain extensions to those PIBs, using the
mechanisms defined in the SPPI [SPPI]. For example, it should be
possible to define MPLS/TE PIB classes for LSP admission control
policies by extending the qosIpAce class to include classification
on incoming label, and the qosAction class, to include assigning
MPLS labels to packets for a created LSP tunnel. Other extensions
would be likely, as well.
As previously discussed, the MPLS/TE PIB needs to contain classes
and parameters specific to the different MPLS technologies, such as
CR-LDP and RSVP-TE, to be flexible enough to handle cases where the
mechanisms differ. An example of this includes the different
information that can be carried in the "LSP/tunnel initiation"
message (i.e. Label Request or Path). Support for specifying named
path (LSP-ID) in the explicit route specification vary, as does
support for carrying objects to record the route (RRO) taken by the
LSP/tunnel through the network.
3.3. Client Handles
COPS-MPLS follows the Client Handle usage as defined in COPS-PR.
After opening a COPS connection to the PDP, the PEP sends a REQ
(config-request) to the PDP containing a Client Handle which is
Reichmeyer, et. al. Expires December 2000 [Page 7]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
unique to that COPS-MPLS client. In return, the PDP sends policy
DECs to the PEP using that same handle. The PEP may send multiple
config-requests for the COPS-MPLS client and may receive policy
from the PDP for any of them. Each config-request corresponds to a
separate request state (see next section) and has a unique Client
Handle associated with it. The PDP must send MPLS policy decisions
to the PEP using the Client Handle for the appropriate request
state.
3.4. Request States
COPS-PR supports the notion of the PDP configuring policy
information for different request states at the PEP. That is,
policy decisions can be installed for separate virtual policy
stores associated with different request states, for example
different time of day, day of week, etc. Then, the PDP can instruct
the PEP to switch request states, activating the policy
configuration of one and de-activating another. Only one request
state may be active at any time.
In the COPS-MPLS case, switching contexts may result in the need to
tear down LSP tunnel(s) associated with the policy for one request
state and establish new tunnels associated with the configuration
of the new request state. In addition, flow management policies for
a new request state may also be desirable. However, if a policy
rule is dependent on a label or tunnel identifier from a previous
policy decision, and that decision is not active in the current
request state, the policy rule cannot be installed (results in an
error returned to the PDP).
When a request state switch occurs, an attempt to install a flow
management policy that references a label or tunnel identifier that
has not been previously established for that request state MUST
result in an error message sent by the PEP to the PDP. Upon
processing the error, the PDP MAY instruct the LSR revert back to
the previous request state or it MAY issue additional DECs to
address the error(s) reported.
4. COPS-MPLS Messages
This section describes the usage of the COPS protocol messages for
the COPS-MPLS client type. Message types not described here require
no client specific definition and are to be implemented according
to the COPS-PR [COPS-PR] and/or COPS base protocol [COPS]
specifications.
COPS-MPLS messages MUST contain:
Client-type = "COPS-MPLS Client"
in the Client-type field of the COPS Common Header (number to be
assigned).
Reichmeyer, et. al. Expires December 2000 [Page 8]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
4.1. Protocol Objects
COPS-MPLS messages use the client specific message content and
protocol objects as specified in [COPS-PR].
4.2. Request Message
The Request (REQ) message is used after the PEP has first
established COPS connectivity with the PDP, to notify the PDP of
the LSRÆs capabilities and limitations with regard to MPLS/TE
functionality. The REQ is sent with the æconfiguration requestÆ
context flag in the Context object.
Multiple REQ messages can be sent by the PEP to open multiple
policy request states. Each request state gets associated with a
unique Client Handle, chosen by the COPS-MPLS client, included in
the REQ message.
COPS-MPLS policy request data is carried in the Named ClientSI
request data object. The format of this object is defined by the
<Named ClientSI: Provisioning> object, for REQ, in [COPS-PR].
4.3. Decision Message
The Decision (DEC) message is used by the PDP to send LSP tunnel
and flow management policy decisions to the PEP.
For setting up LSP tunnels, the PDP sends a DEC to the PEP with the
QoS resource requirements for the tunnel, explicit route
information, if applicable, and an æInstallÆ Decision Flags object.
The PEP MUST respond with a Report message containing either
æFailureÆ or æSuccessÆ Report-Type object indicating whether the
tunnel was established or not. When tearing down a tunnel, the PDP
sends a DEC with æRemoveÆ Decision Flags object and reference to
the existing policy to be removed.
For MPLS admission control policies, the PDP sends a DEC to the PEP
with flow classification information and MPLS/TE policy action, for
example assigning a label, or labels, to forward the traffic onto a
particular LSP tunnel. The PEP MUST respond with a Report message
containing either æSuccessÆ or æFailureÆ Report-Type object
indicating whether the policy rule(s) were successfully installed
at the LSR.
The Client Handle used in the DEC message MUST corresponds to a
Client Handle sent in a REQ by the PEP to the PDP.
COPS-MPLS policy decision data is carried in the Named Decision
Data object. The format of this object is defined by the <Named
Decision Data: Provisioning> object in [COPS-PR].
4.4. Report Message
The Report (RPT) message is used by the PEP to acknowledge DEC
messages sent by the PDP and report LSP performance monitoring
Reichmeyer, et. al. Expires December 2000 [Page 9]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
information for traffic engineering purposes. The PEP must send a
RPT in response to a DEC message from the PDP.
When the PEP receives a DEC for a LSP tunnel policy, a RPT message
must be returned indicating:
- Failure: notification of errors/warnings that occurred in
processing the DEC message or in establishing the LSP tunnel
- Success: notification of successful establishment of LSP tunnel
(including tunnel identifier and other relevant information).
When the PEP receives a DEC for a MPLS admission control policy, a
RPT message must be returned indicating:
- Failure: notification of errors/warnings that occurred in
processing the DEC message or installing the policy at the LSR
- Success: notification of successful installation of the policy.
Monitoring tunnel performance is critical to the traffic
engineering process. The PEP can perform LSP monitoring and send
performance information to the PDP in a RPT message, with Report-
Type = æAccountingÆ. This monitoring information may be used by the
PDP in making adjustments to the current MPLS network configuration
as well as in future MPLS-related policy decisions. The
æAccountingÆ RPT message is also used to send other state and
network information to the PDP, that is relevant to the MPLS policy
controlled by the PDP.
COPS-MPLS policy report data is carried in the Named ClientSI
request data object. The format of this object is defined by the
<Named ClientSI: Provisioning> object, for RPT, in [COPS-PR].
5. Common Operations
COPS-MPLS is based on the COPS-PR policy management model.
In COPS-MPLS, PEPs reside at LSRs that are to interact with the
PDP. The PEP establishes a connection with the PDP as described in
[COPS-PR] and sends a REQ (config-request) to the PDP. The REQ
contains capabilities and limitations of the LSR with respect to
MPLS/TE policy management and a unique Client Handle for the client
request state. The PDP responds with policy DECs for the COPS-MPLS
client.
LSP tunnels are established by the PDP sending an æInstallÆ DEC to
the PEP that is the ingress edge LSR (E-LSR) for the tunnel. The
COPS-MPLS Named Decision Data object carries the MPLS policy data
for setting up the tunnel, such as the label distribution mechanism
to be used, and appropriate QoS constraints and explicit route
information. The PEP processes the DEC and, if no errors are found,
such as invalid protocol objects, etc., proceeds to attempt to
establish the tunnel across the network.
Reichmeyer, et. al. Expires December 2000 [Page 10]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
When the ingress LSR receives notification that the tunnel is
successfully established, e.g. via either Label Mapping message or
Resv message, depending on the label distribution protocol used,
the PEP sends a RPT to the PDP. The æSuccessÆ Report-Type is used
and the Named ClientSI Report object carries the information being
reported by the PEP. In response to a tunnel set up policy DEC, the
RPT message SHOULD contain a tunnel identifier, label used to
forward traffic to the next-hop LSR in the tunnel and possibly any
return route information specifying the exact path taken by the
tunnel.
If notification is received by the E-LSR that the tunnel could not
be set up, the PEP sends a RPT with a æFailureÆ Report-Type and
information on the error that occurred. For example, a path with
the specified QoS constraints may not have been available or one of
the nodes in the explicit route may not have sufficient resources
available.
The PDP, upon receiving a æSuccessÆ RPT, may then send DECs to the
PEP with MPLS flow management policy for the existing tunnel. The
Named Decision Data contains classification information, similar to
that used for Diff Serv QoS policy, specifying data flows and
conditions for forwarding the flows over the tunnel. The policy
rule actions specified in these policy DECs MAY include applying a
certain label associated with the tunnel. The PEP processes these
DECs and replies with a RPT indicating success or failure in
installing the policy.
Tunnel performance measurements, taken by the LSR(s) along the path
of a tunnel, are reported by the PEP to the PDP by sending RPT
messages containing the æAccountingÆ Report-Type and appropriate
measurement data/statistics in the COPS-MPLS Named ClientSI Report
object. Over the life of the tunnel, performance is measured and
analyzed by the PDP for traffic engineering and planning and for
making incremental changes to the configuration as necessary.
Changes to existing tunnels are made by the PDP sending a DEC that
references an existing tunnel policy, but specifies new parameters
for the tunnel. The PEP processes the changes as before and replies
with a RPT to the PDP. Changes to MPLS flow management DECs are
made in a similar manner, by the PDP sending a DEC with the new
parameters.
To delete a tunnel, the PDP sends a æRemoveÆ DEC to the ingress E-
LSR of the tunnel. The PEP processes the DEC and tears down the
tunnel by issuing the appropriate label distribution protocol
message, Path Tear if RSVP-TE, or Label Release if CR-LDP, to the
next-hop LSR. A RPT message from the PEP indicates whether the
tunnel was successfully removed. Prior to deleting a tunnel, all
MPLS flow management policies that reference the tunnel, for
example via label assignment or tunnel identifier, should be
removed first. This is to avoid the timing problem of an E-LSR
Reichmeyer, et. al. Expires December 2000 [Page 11]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
enforcing a flow classification policy and assigning a label to a
packet for a LSP tunnel which has been removed.
6. Security Considerations
The use of COPS for MPLS/TE introduces no new security issues over
the base COPS protocol [COPS] or COPS-PR protocol [COPS-PR]. The
security mechanism described in [COPS] should be deployed in a
COPS-MPLS environment.
7. References
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
Sastry, A., "The COPS (Common Open Policy Service)
Protocol," RFC 2748, January 2000.
[COPS-PR] Chan, K., Durham, D., Gai, S., Herzog, S., McCloghrie,
K., Reichmeyer, F., Seligson, J., Smith, A., Yavatkar,
R., "COPS Usage for Policy Provisioning," draft-ietf-
rap-cops-pr-02.txt, March 2000.
[CR-LDP] Jamoussi, B., et. al., "Constraint-Based LSP Setup Using
LDP," draft-ietf-mpls-cr-ldp-03.txt, September 1999.
[DS-PIB] Fine, F., McCloghrie, K., Seligson, J., Chan K., Hahn,
S., Smith, A., Reichmeyer, F., "Differentiated Services
Quality of Service Policy Information Base," draft-ietf-
diffserv-pib-00.txt, March 2000.
[FRAME-PIB] Fine, F., McCloghrie, K., Seligson, J., Chan K., Hahn,
S., Smith, A., Reichmeyer, F., "Framework Policy
Information Base," draft-ietf-rap-frameworkpib-00.txt,
March 2000
[LOAD-DIS] Wright, S., Jaeger, R., Reichmeyer, F., "Traffic
Engineering of Load Distribution," draft-wright-load-
distribution-00.txt, July 2000.
[MPLS-PIB] "MPLS/Traffic Engineering Policy Information Base," work
in progress.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G.,
Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," draft-ietf-mpls-rsvp-lsp-tunnel-05.txt,
February 2000.
[SPPI] McCloghrie, K., et. al., "Structure of Policy
Provisioning Information," draft-ietf-rap-sppi-00.txt,
March 2000.
[TE/MPLS] Awduche, D., et. al., "Requirements for Traffic
Engineering over MPLS," RFC 2702, September 1999.
Reichmeyer, et. al. Expires December 2000 [Page 12]
Internet Draft draft-franr-mpls-cops-00.txt July 2000
8. Author's Addresses
Francis Reichmeyer
IPHighway, Inc.
55 New York Ave.
Framingham, MA 01701
Phone: +1 201 665 8714
Email: franr@iphighway.com
Steven Wright
Science & Technology
BellSouth Telecommunications
41G70 BSC
675 West Peachtree St. NE.
Atlanta, GA 30375
Phone +1 (404) 332-2194
Email: steven.wright@snt.bellsouth.com
Mark Gibson
Nortel Networks
Harlow Laboratories, London Rd.
Harlow, Essex UK CM17 9NA
Phone: +44(0)1279 402621
Email: mrg@nortelnetworks.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
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.
Reichmeyer, et. al. Expires December 2000 [Page 13]