Side_1_360

• Retrieve QoS performance data from network
  elements;


• Collect and process usage data;


• General QoS reports – trend analysis of key
  QoS parameters;


• Audit/analyse collected QoS parameters
  against expected values.

These are typically distributed on functionality
in the network elements, element management
system and network management system.

5.3 Policy Actions

Three types of actions are defined in order to
control QoS enforcement:

• Signalling used to interact with RSVP. Sig-
  nalling-related policies are related to admis-
  sion control (e.g. whether to accept or reject
  a request arriving by RSVP), controlling the
  forwarding behaviour (e.g. set appropriate
  marking) and the signalling procedures (e.g.
  setting and modifying values in the RSVP
  messages).

In order to utilise RSVP, a few additional

updates of objects have been described, ref.

[RFC2750]. They are called policy data

objects. The Filter_spec and Scope objects

describe the associated senders and prevent

loops. RSVP_hop identifies the neighbour

policy-capable router, both an originating and

a destination may be given. The Integrity

object may provide a secure communication

channel between non-adjacent PEPs, i.e. with-

out involving Policy-Ignorant Nodes (PINs).

The Policy_refresh object can be used to set

values for when the policy association has to

be refreshed, e.g. for authentication.

• Provisioning used to enforce differentiated
  service policies including marking, policing
  and shaping. Meters measure the temporal
  properties of a flow (or flow aggregate) of
  packets selected by a classifier against a traffic
  profile. Meters measure flows matching the
  rule condition per flow, per interface, per role
  within a device, per device or per role across
  all devices. Traffic can be classified as con-
  forming, excess or violating. The measure-
  ment value may possibly also be compared
  against a profile. For instance, a shaper,
  policer and re-maker compare a traffic profile
  against a meter. Common parameters seen
  refer to rate (e.g. in kbit/s), normal burst (e.g.
  in byte) and excess burst (e.g. in byte).

Markers are used to assign a DSCP to a

packet. This could be done based on the state

of the meter referring to the traffic flow that

the packet belongs to. A shaper is used for

delaying packets in a traffic flow to bring the

flow into conformance with a profile. Drop-

pers are used to discard some of the packets

in a traffic flow, commonly to bring the flow

in conformance with a profile (frequently

referred to as policing). These are recognised

from the functional elements described for

DiffServ.

An example of a policy is

i) if “traffic flow within profile X” then

“mark packet with DSCP = AF1”

ii) if “traffic flow out of profile Xand within

profile Y” then “mark packet with DSCP

= AF2”

iii) if “traffic flow out of profile Y” then “drop

packet”

where profile Xcan mean rate is less or equal

to 64 kbit/s, and profile Ycan mean rate is less

or equal to 128 kbit/s.

This could be done more efficiently when

condition ii) is only checked if i) fails; condi-

tion iii) is only checked if ii) fails.

• Per-Hop-Behaviour (PHB) used to enforce the
  behaviours across a DiffServ domain. PHB
  actions are used to represent the requirements
  on PHBs and also giving details enabling
  mapping onto configuration parameters for
  configuring queues, schedulers, droppers and
  other mechanisms, i.e. including attributes
  related to DiffServ MIBs. These involve set-
  ting bandwidth to be allocated, delay and jitter
  parameters, use of dropping algorithm with
  corresponding values, etc. These can be speci-
  fied as hierarchical policies, i.e. when certain
  rules are valid for an aggregate (e.g. all pack-
  ets on a given interface) while further rules
  are to be obeyed for traffic flows within the
  aggregate (e.g. for TCP packets on the same
  interface).

All these types may be included in a single

action/rule.

The IETF Policy Working Group is standardis-

ing the basic framework of policy-based man-

agement systems for IP networks. It focuses on

representing, managing and sharing policies in a

vendor independent, interoperable and scalable

manner.

The Policy WG co-ordinates the development

of the QoS schema with the Policy Information

Base (PIB) and the Management Information