Side_1_360

tion without requiring modifications to the

COPS protocol itself.

• COPS provides message level security for
  authentication, replay protection, and message
  integrity. COPS can also reuse existing proto-
  cols for security such as IPSec to authenticate
  and secure the channel between the PEP and
  the PDP.


• The protocol is stateful in two main aspects:
  
  
  • Requests from PEP are installed or remem-
    bered by the remote PDP until they are
    explicitly deleted by the PEP. At the same
    time, decisions from the remote PDP can be
    generated asynchronously at any time for a
    currently installed request state.
  
  
  • The PDP may respond to new queries dif-
    ferently because of previously installed
    Request/Decision state(s) that are related.
  
  
  
  


• Additionally, the protocol is stateful in that it
  allows the PDP to push configuration informa-
  tion to the PEP, and then allows the PDP to
  remove such state from the PEP when it is no
  longer applicable.

Note that the COPS architecture does not pro-
vide a complete management framework as
such. It merely provides a way to distribute pol-
icy configuration information to devices. The
COPS architecture relies on other management
protocols, e.g. for monitoring.

A client-type of COPS for TE is drafted in
[ID_COPS]. There, within an IP router and in
addition to a PEP and the LPDP, a set of routing
information bases (RIBs) and Forwarding Infor-
mation Bases (FIBs) are also defined. The RIB
represents a routing protocol, like OSPF and
BGP. The FIB stores the routes that have been
selected by the routing processes. The request,
decision and report messages have to include
relevant attributes for traffic engineering, like
link metrics and traffic flow characteristics.

5.6.2 LDAP
While there are many choices of protocols for
directory/database access from the policy man-
agement function and policy decision function,
LDAP appears to be favoured by a number of
vendors and users. LDAP schemes are versatile
and allow considerable flexibility in the choice
of back-end directory management. Further, the
LDAP client-server protocol is widely imple-
mented and used for supporting a wide range of
directory enabled applications. However, there is
a number of shortcomings of LDAP that must be
clearly understood by implementers, such as
lack of asynchronous notification, replication

support, security, referential integrity, support

for “templates”, and limitations of query lan-

guage. Some of these shortcomings, such as

asynchronous notification, may be addressed by

defining specialised protocols between func-

tional entities. LDAP is further described in

[RFC2251].

5.6.3 SNMPv3

The original SNMPv1 was a lightweight man-

agement protocol that was sufficient for small

networks offering a best effort service. Its capa-

bility was generally limited to the monitoring

of network element operation and performance

rather than performing intrusive management

operations.

As data networks and their applications have

grown, so has the realisation that they must be

able to offer similar quality, availability and

scalability guarantees as are provided for classi-

cal networks. Consequently, SNMPv3 is being

developed to meet these requirements. Further-

more, SNMP usage has become more strategi-

cally important for operators as IP technology is

deployed in their networks. SNMPv3 is further

described in [RFC2570], [RFC2571],

[RFC2572] and [RFC2574].

An IETF SNMP working group is to elaborate,

among other things, some QoS MIB modules to

describe management objects for the control of

DiffServ policy in co-ordination with the effort

currently taking place in the DiffServ WG.

In addition, the DiffServ WG is producing an

MIB designed according to the DiffServ imple-

mentation conceptual model. The purpose of the

DiffServ MIB is to allow the setting up of Multi-

Field and Behaviour Aggregate traffic classifica-

tion filters and queues; to monitor whether or not

a traffic flow is within its profile; and finally to

perform some action on the traffic depending on

whether or not it is in profile (shaping, policing,

(re-)marking). SNMP is the protocol used to

implement the DS MIB. The MIB is composed

of six basic elements:

• Behaviour Aggregate Classification table –
  stores DSCPs in order to enable identification
  of tagged streams of traffic. Could be part of
  the Classifier Table, but for extensibility rea-
  sons is kept as a separate table. Note that a
  new draft of the DiffServ MIB has merged
  this filter with the Multi-field now described.


• Multi-Field Classification table – used to
  define MF Classifiers. Similar to the BA Clas-
  sification Table, this could be part of the Clas-
  sifier Table but it has not been specified in
  that way. This permits other proprietary filters
  to be specified, bringing the need for just one