INTERNET DRAFT Bernhard Suter
Category: Standards Track Ping Pan
Title: draft-pan-cops-te-00.txt Bell Labs
Date: June 1999
COPS Extension for Intra-Domain Traffic Engineering
Status of this Memo
This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
COPS [COPS] is a Policy Transport protocol that can be used for
exchanging resource allocation commands between PDP and PEP
[COPSFRAME]. This memo defines COPS messages and objects for
supporting Traffic Engineering and resource management functionality
at network edge routers.
The work defined in this memo is motivated by the recent activities
in Internet-2 QBone and IETF AAA and RAP working groups.
Suter, Pan expires December 1999 [Page 1]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
1 Introduction
The objective in this memo is to define a communication mechanism
between PDP's and PEP's which can be used to provide traffic
engineering functionality within an ISP's network.
1.1 Network Model
Figure-1 illustrates a sample network.
+------------------+
| PDP |
+------------------+
^ ^
| |
+---------------+ +---------------+
| |
| |
v v
+----------+ +----+ +----+ +----+ +----------+
==>| Edge Rt1 |-----| R1 |-----| R2 |-----| R3 |-----| Edge Rt2 |==>
| / PEP1 | +----+ +----+ +----+ | / PEP2 |
+----------+ +----------+
| |
| +----+ +----+ +----+ |
+-------| R4 |-------| R5 |-------| R6 |-------+
+----+ +----+ +----+
Figure 1: Sample Backbone Network Configuration
Rt1 and Rt2 are the edge/border routers in an ISP domain. User
traffic enters the network at Rt1 and exits at Rt2. As a transit
network, the ISP can set up multiple "virtual" tunnels between Rt1
and Rt2. The tunnel setup mechanism can be RSVP[RSVP], RSVP-LSP
extension[RSVP-LSP] or other means. Network resource allocated to
each tunnel can be described in terms of bandwidth, traffic
class[DIFFSERV] and/or MPLS labels[MPLS].
As shown in the figure, there could be multiple routes between R1 and
Rt2. In this case, both R1-R2-R3 and R4-R5-R6 can be used to carry
traffic across the ISP backbone. For redundancy, one of them can be
used as the backbone tunnel. In the example, when Rt1 detects a
tunnel failure on R1-R2-R3, it can redirect the traffic to R4-R5-R6
Suter, Pan expires December 1999 [Page 2]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
tunnel.
To provide traffic engineering functionality, we assume that the edge
routers are controlled by Policy Servers (that is, PDP's as being
defined in [COPSFRAME]). The communication between PDP's and PEP's
uses COPS protocol.
Policy Servers distributes resource allocation policy information to
the edge routers. To comply with the policy, the edge routers (or
PEP's) may trigger tunnel setup protocols to create/modify/delete
virtual tunnels, and interface with router's forwarding path or
routing database to implement filters to assign traffic to a specific
tunnel.
The PEP's need to notify the PDP's in case of tunnel changes.
1.2 Components
This memo defines two major policy components: tunnels and filters.
1. A tunnel is a means of forwarding packets from one point to
another in a network which appear to be virtually connected by
this tunnel. Tunnels are unidirectional and have a defined ingress
and egress node and depending on the type of tunnel, may have
additional parameters like bandwidth reservation or specified
route. Supported types of tunnels can be MPLS label paths, IP-in-
IP tunnels, DiffServ trunks, RSVP flows, ATM or Frame Relay
logical interfaces or anything else that satisfies the above
description.
2. A filter is a means of selecting packets to be forwarded
through a tunnel. Filter rules may be based on fields of the
packet headers, routing protocol information or properties of the
incoming L2 interface. Packets are forwarded based on the first
matching filter rule. Filters have a priority that can be used to
resolve ordering problems where they arise. The priority among
different types of filters is implementation dependent. A filter
can be associated with an ordered list of tunnels, packets will be
forwarded to the tunnel with the highest preference level in this
list. Supported types of filters can include incoming MPLS labels,
ATM or Frame Relay circuits, packet classifiers, incoming DiffServ
codepoints, BGP attributes, etc.
Suter, Pan expires December 1999 [Page 3]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
Supporting traffic engineering implies the following:
1. PDP's need to be able to request PEP's (ingress nodes) to set
up tunnels with specified properties within the network. Traffic
engineering decisions may be unsolicited and triggered by user
policy update on the PDP. The PDP may specify source route or
explicit route objects to implement QoS or constraint based
routing and path selection policies.
2. PDP's need to be able to configure PEP's to forward incoming
data traffic onto these tunnels by specifying various kinds of
filters with associations to these tunnels.
Each tunnel or filter rule is considered a policy element or object
and assigned a unique ID by the PDP. This ID is used by the PDP to
modify or uninstall a policy element or create associations among
them (e.g. associate filters with tunnels) and by the PEP to report
status changes of a policy element. The policy element ID is
orthogonal to the COPS client handle, which identifies a client
request context.
1.3 Disclaim and Assumptions
DIAMETER [DIAMETERFRAME, DIAMETER] can also be used to transfer
policy information between PDP's and PEP's. This extension can be
easily modified to interface with DIAMETER as well. Until various
IETF working groups have resolved their differences on policy
requirements, we will use COPS for traffic engineering support.
Further, the scope of this draft is limited by the following
assumptions:
o We do not describe the operation of the tunnel setup protocols.
However, by design, the extension will work with [RSVP-LSP].
o We do not specify the definition of tunnels, which can be RSVP
flows, MPLS tunnels, DiffServ trunks, etc. Our goal is to support
any tunnel descriptors between PDP's and PEP's.
1.4 Specification of Requirements
Suter, Pan expires December 1999 [Page 4]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
In this document, several words are used to signify the requirements
of the specification as defined in [REC]. These words are often
capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the
specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that
there may exist valid reasons in particular circumstances
to ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementation
which does include the option.
2. Extension Specific Object Formats
The object format follows the convention defined in [COPS].
2.1 TUNNEL_ID Object
The TUNNEL_ID object encapsulates a unique value that identifies a
tunnel. The identification is assigned by the PDP, and is 4-byte
long. The tunnel id is used by the PDP to create, modify or withdraw
tunnel policy objects of specified type and by the PEP for error or
status reports regarding a specific tunnel.
C-Num = 30
C-type = 1, "Classical" RSVP tunnel
C-type = 2, RSVP LSP tunnel
C-type = 3, DiffServ Trunk
C-type = 4, IP-IP tunnel
Suter, Pan expires December 1999 [Page 5]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
The object has the following context.
+-------------+-------------+-------------+-------------+
| Tunnel Id value |
+-------------+-------------+-------------+-------------+
2.2 TUNNEL_PREF Object
This object is used to describe the relative priority level of a
tunnel associated with a filter. A filter policy may contain a list
of pairs of tunnel Id and tunnel preference objects. The PEP MUST
send traffic matching this filter rule to the available tunnel with
the highest preference level. If multiple tunnels are listed with the
same highest eligible preference levels, the PEP MAY do load sharing
among them or pick one at random.
Note that the preference is not a property of the tunnel policy, but
of the association or binding of a tunnel to a filter policy. E.g.
two tunnels may implement 2 different service classes to the same
egress node and serve as each others standby in case of failure of
one of the tunnels.
C-Num = 31
C-type = 1
The object has the following context.
+-------------+-------------+-------------+-------------+
| Preference Levels | Flag |
+-------------+-------------+-------------+-------------+
The lowest preference level is 0, and the highest is 0xffff.
Flag:
Don't Care = 1
Suter, Pan expires December 1999 [Page 6]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
2.3 DSCP Object
The DSCP Object defines the Differentiated Services Code Point
associated with a tunnel. The tunnel is represented by a diffServ
trunk and results in its packets being marked with the indicated
DSCP.
C-Num = 32
C-type = 1, DiffServ Code Point
The object has the following context.
+-------------+-------------+-------------+-------------+
| DSCP Value | Padding |
+-------------+-------------+-------------+-------------+
2.4 BANDWIDTH Object
It is used to defined the bandwidth associated with a tunnel. The
BANDWIDTH Object may be used along with the DSCP Object to define a
DiffServ "trunk" in a network. Alternate bandwidth request
description objects may be used in accordance with the signaling
protocols and networks services used (E.g. IntServ).
C-Num = 33
C-type = 1
The object has the following context.
+-------------+-------------+-------------+-------------+
| Token Size |
+-------------+-------------+-------------+-------------+
| Measurement Interval |
+-------------+-------------+-------------+-------------+
The value of Token Size is the maximum number of bytes that can be
Suter, Pan expires December 1999 [Page 7]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
transmitted per interval on a particular tunnel. The bandwidth of a
tunnel is given by (Token Size)/(Measurement Interval).
2.5 FILTER_ID Object
The FILTER_ID Object encapsulates a unique value that identifies a
filter. The identification is assigned by the PDP, and is 4-byte
long. The filter id is used by the PDP to create, modify or withdraw
filter policy objects of specified type and by the PEP for error or
status reports regarding a specific tunnel.
C-Num = 34
C-type = 1
The object has the following context.
+-------------+-------------+-------------+-------------+
| Filter id |
+-------------+-------------+-------------+-------------+
2.6 FILTER Object
The FILTER Object is used to set up ingress packet classification at
edge routers. Several types of filters are defined here. They are
differentiated by the C-type of the object.
C-Num = 35
C-type = 1 packet classification
C-type = 2 MPLS LSP
C-type = 3 BGP Path Attributes
Each FILTER Object has a common header and multiple sub-objects that
Suter, Pan expires December 1999 [Page 8]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
provide detailed description of the filter.
The format of the object is
+-------------+-------------+-------------+-------------+
| Priority | Action of Last Resort |
+-------------+-------------+-------------+-------------+
| |
// Filter Content //
| |
+-------------+-------------+-------------+-------------+
Priority indicates the order of rules for a given filter entry. It is
used for building up policy tables at the PEP. Filters with same
priority do not have a defined order and MAY be ordered by the PEP in
any order among each other.
When all the tunnels associated with a filter are disabled, the
router refers to the Action-of-Last-Resort to decide what to do. If
tunnels are used to implement VPNs with private addressing, there
might be no implicit default route to deliver the packets on a best
effort basis.
Action of Last Resort:
1. remove the filter;
2. best effort;
3. discard;
o Packet Classifier
Packet classifiers are rules based on combinations of fields in the
IP and TCP or UDP headers. If the protocol is neither UDP or TCP, the
port information MUST be ignored. Protocol set to zero indicates that
the rule does not cover the IP protocol field. Fields with Min and
Max value rules can be rendered insignificant by setting min to zero
and Max to the maximum value (255 or 65535). IP address masks can
only denote prefixes. A packet matches a rule if all the constraints
of this rule are satisfied.
+-------------+-------------+-------------+-------------+
Suter, Pan expires December 1999 [Page 9]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
| Destination IP Address |
+-------------+-------------+-------------+-------------+
| Destination IP Address Mask |
+-------------+-------------+-------------+-------------+
| Source IP Address |
+-------------+-------------+-------------+-------------+
| Source IP Address Mask |
+-------------+-------------+-------------+-------------+
| DSCP Min | DSCP Max | Protocol | Padding |
+-------------+-------------+-------------+-------------+
| Dst Port Min | Dst Port Max |
+-------------+-------------+-------------+-------------+
| Src Port Min | Src Port Max |
+-------------+-------------+-------------+-------------+
o MPLS LSP
The object content is a stack of LSP's. All incoming MPLS packets
with this label stack will be assigned to a tunnel based on this
filter. This may be useful, to terminate an MPLS tunnel and assign
its traffic to a specific DiffServ trunk.
+-------------+-------------+-------------+-------------+
| LSP # 1 |
+-------------+-------------+-------------+-------------+
// ... //
+-------------+-------------+-------------+-------------+
| LSP # N |
+-------------+-------------+-------------+-------------+
o BGP Path Attributes
This object applies to the BGP-speaking border routers. It can be
used to direct inter-domain traffic within an ISP's network.
+-------------+-------------+-------------+-------------+
| BGP Next-Hop |
+-------------+-------------+-------------+-------------+
BGP Next-Hop is the IP address of a remote BGP-speaking border
router.
Suter, Pan expires December 1999 [Page 10]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
4. Additional Requirements in the Base Protocol
The extension requires a new Client Type, 3. The PEP's and the PDP's
that support this extension MUST be able to parse all the objects
defined Section 2.
Two new C-types are defined in the Client Specific Information Object
(ClientSI):
C-type = 3, for RSVP-LSP extension
With this type ClientSI, the PDP and the PEP should encapsulate and
understand a sequence of relevant RSVP objects such as EXPLICIT_ROUTE
and SESSION_ATTRIBUTE objects.
C-type = 4, for status report on policy elements
In RPT messages, the PEP can send a sequence of policy element
objects (such as TUNNEL_ID and FILTER_ID objects) along with a
object to inform the status of tunnels and filters.
A new C-type is defined in the Decision Object:
C-type = 6, Traffic Engineering Server Specific Decision Data
This decision serves as a container for all relevant tunnel and
filter objects. Each tunnel or filter decision MUST start with a
TUNNEL_ID or FILTER_ID, respectively.
A tunnel decision MAY consists of any amount of descriptive objects
such as DSCP, bandwidth as well as a ClientSI object, which in term
MAY consist of RSVP objects for tunnel establishment.
A filter decision MAY consist of a FILTER object and the information
on the tunnels that are associated with the filter.
A Traffic Engineering-specific Decision object may have the following
format:
Suter, Pan expires December 1999 [Page 11]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
::= | ::= [] []
::=
[] [ ]
::= |
Two new C-types are defined for the Report Type Object for status
updates on installed policy elements:
C-type = 8, Failed C-type = 9, Restored C-type = 10, Switched
Failed is used by the PEP to indicate that a policy element which has
previously been reported as Installed, has operationally failed due
to network or device failure conditions. Restored is used to indicate
that this failure condition has been resolved and that the policy
element reverts back into a fully operational state. Switched is used
to indicated that a policy object has performed a valid and
preconfigured switchover operation due to a failure condition or
restoration. (E.g a filter rule has changed its active tunnel to the
most preferable among the active ones in its list of tunnel
associations.)
5. Description of Operation
5.1 Initialization
As being defined in COPS, at initialization time, the PEP sends OPN
(Client-Open) messages to the PDP to inform about the client
capability that the PEP can support and the PEP identification. It
must send the new client-type (3).
Suter, Pan expires December 1999 [Page 12]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
5.2 Policy Element Installation
The operation required in this memo is very simple: the PDP sends
tunnel setup commands and traffic classification rules to the PEP in
COPS DEC (Decision) messages, using an Install decision flags command
code. Each TE decision object defines one policy element and needs to
contain sufficient information for the successful creation and
activation of this object.
The TUNNEL_ID contains a number generated by the PDP. The DSCP value
inside the DSCP object is used to describe the traffic class of the
tunnel inside the network.
In current version, the ClientSI contains all possible RSVP objects
that can be used to set up a LSP tunnel within the network.
The C-type for the Decision must be 6.
The PEP MUST acknowledge either installation of failure
(Installed/NotInstalled) of each policy element by including its
policy element ID in the clientSI object of a report message. For
tunnels with a long expected setup time, the PEP MAY send a Commit
report to the PDP to indicate that the policy element has been
validated, local resources allocated and that setup is pending in the
network. If a filter rule is successfully linked to an operational
tunnel, its tunnel ID must be included as application object in the
ClientSI object of the report message.
If installation of a policy element depending on network conditions
has failed, the PEP must report any application error to the PDP and
retry periodically until the PDP removes the policy element.
5.3 Policy Elements Affected by Network State Changes
Whenever the PEP detects changes in the operational state of any
policy element, it MUST notify the PDP through additional report
messages. Such state changes may include failure or restoration of
tunnels or changes in association of traffic filters with tunnels.
5.4 Modification of Policy Elements
Any additional Install decisions with an existing policy element ID
is considered a modification. Any existing configuration state of the
policy element in the PEP MUST be replaced with the content of the
new decision object. The PEP must reply with an
Installed/NotInstalled report on the policy element. If a
Suter, Pan expires December 1999 [Page 13]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
modification has failed (NotInstalled) the PDP assumes that it has
remained in its previous state. If the failed modification attempt
has rendered the policy element inoperational, the PEP MUST report
its failure.
5.5 Client Requested Creation of Policy Elements
The PEP can also initiate a tunnel setup by sending a request to the
PDP with a RSVP ClientSI which contains the necessary objects to
describe a tunnel setup demand. The PDP may respond with a sequence
of decisions objects to set up the necessary elements. All messages
related to policy elements that are related to a client request MUST
carry the client handle of the request. The server still picks unique
TUNNEL_ID resp. FILTER_ID to identify each of the policy elements in
any decision message. Deletion of this client handle by the PEP
implicitly invalidates all policy element IDs associated within the
context of this client handle.
6. Redundancy Consideration
One important feature in traffic engineering is tunnel redundancy: if
a tunnel goes down, its traffic should be sent using a backup tunnel.
This requires the edge routers to setup and maintain multiple
connections between two same ingress and egress edge routers.
To allow fast switch-over, the PDP may associate a filter policy with
multiple tunnels. Each of this associations has a precedence level.
In case of a tunnel failure, the PEP should switch the traffic to the
ones with lower preference levels.
7. On-line vs. Off-line Tunnel Setup
In case of MPLS tunnel setup, the path can be determined offline by
configuration servers or online by QoS routing.
In case of offline path computation, the explict route information
MUST be sent down in COPS DEC messages. The operation is outlined in
Section 5.2.
For online path computation, the PEP can determine the path
dynamically, and MAY report the explict route information to the PDP
for accounting purposes.
Suter, Pan expires December 1999 [Page 14]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
8. Inter-domain Considerations
Inter-domain tunnel request information could either be exchanged
through the tunnel setup protocol at the domain border (see section
5.5). Or by means of additional protocols among PDPs which is beyond
the scope of this memo.
9. Security Considerations
The security requirements of the operations described in this memo
must be covered by the COPS base protocol. Particularly it must
ensure mutual authentication of PDP and PEP.
Acknowledgments
We would like to thanks Petri Aukia, Helena Sarin and Murali Kodialam
for useful comments. Special thanks go to Pramod Koppol and T.V.
Lakshman for many ideas and significent contributions.
References
[COPS] Boyle, J. et al., "The COPS (Common Open Policy Service)
Protocol", Internet Draft, draft-ietf-rap-cops-06.txt, February 24,
1999.
[COPSFRAME] Yavatkar, R. et al., "A Framework for Policy-based
Admission Control", Internet Draft, draft-ietf-rap-framework-02.txt,
April 1999.
[DIAMETERFRAME] Zorn, G. et al., "DIAMETER Framework", Internet
Draft, Internet Engineering Task Force, May 1998.
[DIAMETER] Calhoun, P. et al., "DIAMETER Base Protocol", Internet
Draft, draft-calhoun-diameter-07.txt, November 1998.
[DIFFSERV] Blake, S. et al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RSVP] R. Braden, et al., "Resource ReSer-Vation Protocol (RSVP) --
Version 1 Functional Specification ", RFC 2205, September 1997.
[REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels" , RFC2119, March 1997
Suter, Pan expires December 1999 [Page 15]
INTERNET DRAFT draft-pan-cops-te-00.txt June 1999
[RSVP-LSP] Awduche, D. et al., "Extensions to RSVP for LSP Tunnels",
Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999
[MPLS] Callon, R. et al., "A Framework for Multiprotocol Label
Switching", Internet Draft, draft-ietf-mpls-framework-02.txt,
November 21, 1997.
Author Information
Bernhard Suter
Bell Labs, Lucent
101 Crawfords Corner Road, Room 4C-526
Holmdel, NJ 07733
USA
Phone: 732 949 8516
Email: suter@dnrc.bell-labs.com
Ping Pan
Bell Labs, Lucent
101 Crawfords Corner Road, Room 4C-508
Holmdel, NJ 07733
USA
Phone: 732 332 6744
Email: pingpan@dnrc.bell-labs.com
Suter, Pan expires December 1999 [Page 16]