Base (MIB) being developed in the DiffServ
WG as well as with extensions to the COPS
being developed by the Resource Allocation
Protocol (RAP) WG.
Policy rules must be represented as data struc-
tures so they can be stored and retrieved. To
address this issue, the IETF ’s Policy Working
Group has defined the Policy Framework Core
Information Model, which defines a high-level
set of object-oriented classes that can be used for
general policy representation. The intent of the
Policy Working Group of the IETF is closely
related with the work underway in the Directory
Enabled Network (DEN) Working Group, and in
the Networks Working Group of the Distributed
Management Task Force (DMTF). As a result,
the DEN standards have been adopted by the
DMTF as part of their Common Information
Model (CIM) and CIM itself serves as the basis
for the IETF Policy Working Group’s core
model.
5.4 Policy-enabled MPLS Networks
In general, policy management for MPLS in-
volves Life Cycle management (i.e. creating,
deleting and monitoring) of Label Switched
Paths (LSPs) through the network along with
controlling traffic flow admission (LSP Admis-
sion Control) to those managed resources.
MPLS supports explicit traffic engineering via a
number of specifications (CR-LDP, RSVP) that
allow LSPs to be managed based on certain con-
straints. The policy management architecture
used to control traffic engineering functionality
should be independent of the MPLS mechanisms
used. An objective of introducing policy man-
agement is to arrive at predictable network ser-
vices.
A major application of MPLS is in providing
traffic engineering capabilities to IP networks. In
some cases, this may involve the use of specific
mechanisms (e.g. DiffServ- and IntServ-related).
For handling MPLS related to traffic engineer-
ing, there are two basic categories of polices, ref.
[ID_MPLScops]:
- LSP/tunnel management (or LSP life-cycle)
policies; dealing with configuration related to
initiating, maintaining and removing LSPs; - LSP admission control (or flow management)
policies; dealing with classification for map-
ping traffic flows onto LSPs.
In an MPLS environment, the PEP resides in the
LSRs (Label Switching Routers). A connection
to a policy server (PDP) is then required, al-
though several of the decisions would likely be
taken internally in the LSR, possibly notifying
the policy server. However, allowing the PDP to
make the decisions may result in a more efficient
operation for the total network. Then a Request
message (REQ) may be sent from the PEP to the
PDP when an LSP is to be established, e.g. due
to an incoming RSVP or CR-LDP message to
the LSR. The PDP will reply with a Decision
message (DEC) instructing the PEP on how to
set up the LSP. During the operation a Report
message (REP) can be used by the PEP to
acknowledge the DEC and report performance-
monitoring results.5.5 Differentiated Services Policy
Information Base
The DiffServ Working Group has also released
an Internet Draft specifying a set of Policy Rule
Classes (PRCs) designed for configuring QoS
policy for Differentiated Services. The base
module contains the PRCs for setting DiffServ
policy queues, classifiers, meters, etc., and also
contains filters for matching IP packets.This may be broken down into several different
groups, including:- QoS Interface Group: contains PRCs which
can be used to tell a PDP the types of interface
supported by a PEP and the PRCs a PDP may
install to configure the PEP. Examples of
attributes are: queues, scheduling parameters,
buffer sizes, etc. - QoS Metering Group: contains PRCs relating
to the configuration of meters. - QoS Action Group: contains PRCs used to
define the actions to be taken after the result
of classification and metering. It also contains
policies that associate classifiers, meters and
actions. - IP Classification and Policing Group: contains
policies that define IP classifier elements.
5.6 Some Related Protocols
5.6.1 COPS
The main characteristics of the COPS protocol
include:- A client/server model where the PEP sends
requests, updates, and deletes to the remote
PDP and the PDP returns decisions back to
the PEP. - The utilisation of TCP as its transport protocol
for reliable exchange of messages. - The protocol is extensible in that it is designed
to take advantage of self-identifying objects
and can support diverse PEP specific informa-