Network management policies can be simple resource allocations such as the following:
Other network management policies can be in the form of NE configuration information, such as
Each of these ultimately translates into some action or set of actions at an NE. Policies allow a far more abstract view of the network than is possible with NMS that simply allocate virtual connections. With abstraction comes increased operational power because it is then possible to express complex rules, such as those above, and to combine these into business objects such as service level agreements. This is a type of fly-by-wire way of running a network, and it is entirely possible for policies to conflict ”for example, two policies that attempt to allocate the same bandwidth twice or erroneously assign an unsupported forwarding behavior. The power of PBNM must be used with caution. High-level policies, such as those above, will generally be reflected in some type of NE configuration changes:
Communication of policies to PEPs can be made using SNMP, COPS, telnet, and so on. Once the policies have been installed in the PEP, they can then be locally executed when the associated conditions have been met. The Common Open Policy Service Protocol (COPS)COPS [RFC2748] is a simple client/server protocol for the communication of policies between policy clients and servers. A policy client is also called a PEP, and a policy server is also called a PDP. PEPs may request policy provisioning configuration data (using REQ messages) from the PDP. (PDPs may also autonomously send policies.) The PDP replies with DEC (ision) messages, as shown in Figure 4-5. These exchanges are made using TCP. In Figure 4-5 we see NEs that are policy-enabled ; that is, they can directly host COPS policies. This need not be the case. Policies can be expressed in any NE technology; the standard is COPS-based, but even SNMP tables can be used if required (as we'll see below). This is particularly the case if existing NE products already use SNMP. SNMP uses SMIv2 for the following:
The COPS equivalent to Structure of Management Information (SMI) is called Structure of Policy Provisioning Information (SPPI) and is based on SMI. Apart from notifications, SPPI uses all items in the list above to create Policy Information Bases (PIBs) [RFC3084]. PIBs are very similar to MIBs: They specify a name space that is common to both the PDP and PEP (MIBs specify a name space common to both managers and agents ). A PIB is a tree-structured name space containing provisioning classes and provisioning instances. PIB module definitions [RFC3159] provide a starting point for PBNM. Because PIBs and MIBs are based on SMI, it is relatively easy to convert a PIB into a MIB. An extension to COPS ”called COPS-PR ”is used to configure policies on NEs. Network ProcessorsNetwork communication is increasingly a problem not of bandwidth but of managing mixed traffic types. Network management is driven by the need to be able to manipulate network resources so that all traffic types receive the required forwarding treatment. This is assisted by the development of network processor products from organizations such as Intel and IBM. These are network- facing devices that support advanced features such as the following:
Network processors form an important part of the migration towards the use of policy. PBNM systems can define networkwide policies for connection management, QoS, and traffic engineering, and then push these onto all relevant devices in the network (including network processors). Typically, devices such as routers and switches can be equipped with the new-generation network processors. |