adanets deliverable d2.1 - laboratoire · web viewadanets analysis of standards on qos...

Distribution : Public Restricted Confidential

ADANETS

ANALYSIS OF STANDARDS ON QOS PROVISIONING ON IP NETWORKS AND PROPOSITION OF QOS MANAGEMENT

FRAMEWORK

Document ID: ADANETS-WP2/T2.1- DELIV/18122002-V1.0

Authors: Arnaud Gonguet, Mark Koops, Linas Maknavičius, Michel Chevanne, Olivier Poupel (Alcatel);

Hakima Chaouchi, Wissam Fawaz, Thi Mai Trang Nguyen (LIP6)

Date of Issue: 18/12/2002

Description: This document contains relevant standards review on QoS provisioning on IP networks, within the scope of ADANETS problem domain, i.e. for transporting QoS-sensitive application flows over large-scale packet-based networks. This in-depth review is used to derive a proposal for QoS management framework.

Table of Contents

1 Problem Statement..............................................................11.1 QoS Provisioning Scope.................................................................1

1.2 Relevant and Targeted Standardization Bodies...............................2

1.3 Document Structure.......................................................................3

2 Standardization Bodies Presentation..................................42.1 Internet Engineering Task Force (IETF)........................................4

2.1.1 Global Presentation.........................................................................42.1.2 QoS Related Activities......................................................................5

2.2 TeleManagement Forum (TMF).....................................................52.2.1 Global Presentation.........................................................................5

2.2.1.1 TM Forum's Strategy.......................................................62.2.1.2 TM Forum's Programs.....................................................6

2.2.2 QoS Related Activities......................................................................72.3 Distributed Management Task Force (DMTF)................................8

2.3.1 Global Presentation.........................................................................82.3.1.1 Mission and Goals............................................................82.3.1.2 Membership.....................................................................82.3.1.3 Working Groups and Committees...................................9

2.3.2 QoS Related Activities....................................................................10

3 IETF and QoS Provisioning..............................................113.1 Integrated Services.......................................................................11

3.2 Differentiated Services.................................................................12

3.3 Multiprotocol Label Switching.....................................................13

3.4 Traffic Engineering (TE)..............................................................143.4.1 Constraint-based routing (CBR).....................................................17

3.5 QoS Signalling.............................................................................17

3.6 Mobile IP related QoS activity.....................................................18

3.7 Policy Framework........................................................................193.7.1 PCIM and PCIMe Models..............................................................19

3.7.1.1 Modelling Policies..........................................................203.7.1.2 Description of the PCIM Model.....................................223.7.1.3 Overview of The PCIM Classes.....................................233.7.1.4 Changes To PCIM defined in PCIMe.............................283.7.1.5 Conformance to PCIM and PCIMe................................35

3.7.2 QPIM Model..................................................................................353.7.2.1 QOS Policy Definition....................................................363.7.2.2 Modeling Abstract QOS Policies...................................373.7.2.3 Design Goals and Their Ramifications..........................383.7.2.4 Class Hierarchy Overview.............................................41

3.8 Resource Allocation Protocol (RAP) WG....................................42Project: ITEA ADANETS

1

3.8.1 COPS-RSVP..................................................................................423.8.2 COPS-PR-DiffServ.........................................................................433.8.3 Other COPS extensions..................................................................46

4 TMF and QoS provisioning..............................................474.1 Enhanced Telecom Operations Map.............................................47

4.2 SLA/QoS Management Team.......................................................49

4.3 Policy-based Management Team..................................................50

5 DMTF and QoS provisioning............................................525.1 Common Information Model........................................................52

5.2 CIM Networks Model...................................................................54

5.3 QoS Device Sub-Model................................................................555.3.1 Introduction...................................................................................555.3.2 QoS Device Sub-Model Overview...................................................56

5.3.2.1 QoSService, its Subclasses and Associations...............565.3.2.2 ConditioningService, its Subclasses and Associations 57

6 Proposition of QoS Management Framework.................606.1 Generic QoS Framework..............................................................60

6.1.1 Network Provisioning Scenario......................................................626.1.2 Service Provisioning Scenario........................................................636.1.3 Traffic Engineering Scenario.........................................................64

6.2 QoS Framework Instantiation.......................................................646.2.1 Introduction...................................................................................646.2.2 Threefold generic scenarios...........................................................656.2.3 QoS Framework Instantiation by PBM for Service Provisioning.....65

6.2.3.1 Policy Manager..............................................................676.2.3.2 Policy Repository...........................................................686.2.3.3 Policy Server..................................................................686.2.3.4 Policy Enforcement Point and Proxy.............................69

7 References...........................................................................70

Project: ITEA ADANETS

2

Table of Figures

Figure 1: QoS mechanisms overview..........................................................................1Figure 2: http://www.ietf.org......................................................................................4Figure 3: http://www.tmforum.org.............................................................................5Figure 4: http://www.dmtf.org.................................................................................... 8Figure 5: RSVP signalling in Intserv domain...........................................................11Figure 6: DiffServ edge router architecture.............................................................12Figure 7: MPLS model.............................................................................................. 13Figure 8: Policy IETF WG framework.....................................................................19Figure 9: Overview of the Policy Rule Class............................................................21Figure 10: Overview of the Policy Group Class.......................................................22Figure 11: PCIM schema........................................................................................... 24Figure 12: „PolicySet“ superclass.............................................................................29Figure 13: SimplePolicyCondition structure............................................................31Figure 14: SimplePolicyAction structure.................................................................32Figure 15: Domain-Level Packet Filters in PCIMe..................................................34Figure 16: Class hierarchy of PCIMe.......................................................................35Figure 17: The QOS Definition Information Flow...................................................36Figure 18: Inheritance Hierarchy of classes in QPIM.............................................41Figure 19: Policy-based management architecture..................................................42Figure 20: Outsourcing model in COPS protocol....................................................43Figure 21: Provisioning model in COPS protocol....................................................44Figure 22: The PIB tree............................................................................................. 45Figure 23: enhanced Telecom Operations Map, Business Process Framework.....48Figure 24: Fulfillment - Assurance - Billing.............................................................49Figure 25: CIM Core Model (partial).......................................................................53Figure 26: CIM Common Networks Model (partial)...............................................54Figure 27: QoS Device Sub-Model Inheritance........................................................55Figure 28: QoSService class and its associations......................................................56Figure 29: ConditioningService class and its associations.......................................57Figure 30: Filter classes and associations.................................................................58Figure 31: Generic ADANETS QoS Framework.....................................................61Figure 32: Service Provisioning Instantiation...............................................................66


3

Document history

Version 1 18/12/2002 QoS framework instantiation LIP6, Alcatel

Draft 06 29/11/2002 Added: QoS framework general description, TMF update, TE add-on

Alcatel

Draft 05 30/08/2002 Problem statement part (§1) added; minor updates in other sections

Alcatel

Draft 04 05/07/2002 Integrated draft version Alcatel

Draft 03 06-26/06/2002

Updates after review meetings and cross-readings (all sections)

Alcatel, LIP6

Draft 02 31/05/2002 Initial draft on IETF standards on QoS (§2.1, §3)

LIP6

Draft 01 27/05/2002 Initial draft on TMF & DMTF standards on QoS (§2.2, §2.3, §4, §5)

Alcatel

Edition Date Change note Originator


4

1 PROBLEM STATEMENT

This section aims at defining the boundaries of what is called QoS provisioning, i.e. quality-of-service delivery control over IP networks.

1.1 QoS Provisioning ScopeIn ADANETS project, it is assumed that the information flow between two or more ADANETS application far-ends will pass over a public network. Therefore, IP packet-based networks are considered as a backbone for those communications and as a basis for ensuring required QoS (Quality of Service). In the research and Internet engineering community, the issue of optimal transport capacity of IP flows with stringent performance requirements (i.e. QoS problem) is being addressed by numerous mechanisms (some of them are still being defined/enhanced and adopted gradually). These mechanisms are depicted in the following figure, with their position over the networking layers.

Figure 1: QoS mechanisms overview

We can make a distinction between two kinds of mechanisms:

Vertical QoS mechanisms between adjacent networking layers, i.e. stacking mechanisms and mutual dependencies, most often materialized by API calls, and

Horizontal QoS mechanisms, i.e. consistent techniques shared by all network nodes, such as signalling, priority labelling, etc.

The most eminent mechanisms will be described in detail in this document.


1

Horizontal QoS mechanisms

Ver

tica

l QoS

mec

hani

sms

QoS over ATM QoS over optics(SDH) QoS over Ethernet QoS over

Frame Relay

MPLS

IntServ /RSVP DiffServ

Layer 2

Layer 3

Layer 4

Upperlayers

Bandwidthbrokers

Application/ system-related QoS: client/server response time,

data backup, srv performance, …

Layer 7

QoSbasedpolicymgmt

(Policyframework,

COPS)

Trafficmgmt

Net-work

elements

QoS routing/CBR

Horizontal QoS mechanisms

Ver

tica

l QoS

mec

hani

sms

QoS over ATM QoS over optics(SDH) QoS over Ethernet QoS over

Frame Relay

MPLS

IntServ /RSVP DiffServ

Layer 2

Layer 3

Layer 4

Upperlayers

Bandwidthbrokers

Application/ system-related QoS: client/server response time,

data backup, srv performance, …

Layer 7

QoSbasedpolicymgmt

(Policyframework,

COPS)

Trafficmgmt

Net-work

elements

QoS routing/CBR

1.2 Relevant and Targeted Standardization BodiesMaking a selection of standardisation bodies or organisation dealing with QoS is not an easy task. Here is a list:

TeleManagement Forum (www.tmforum.org)

Committee T1 (www.t1.org) with 3 projects

European Telecommunications Standard Institute (www.etsi.org) with TIPHON project

European Institute for Research and Strategic Studies in Telecommunications (www.eurescom.de) with 5 projects

Internet Engineering Task Force (www.ietf.org)

International Telecommunications Union (www.itu.int/itu-t) with 9 Study Groups

3rd Generation Partnership Project (www.3gpp.org)

ATM Forum (www.atmforum.org)

ASP Industry Consortium (www.aspindustry.org)

Distributed Management Task Force (www.dmtf.org)

DSL Forum (www.dslforum.org)

Frame Relay Forum (www.frforum.com)

Internet 2 Consortium (www.internet2.edu)

Internet Operators (www.iops.org)

Information Technology Association of America (www.itaa.org)

Alliance for Telecommunications Industry Solutions (www.atis.org)

Open Group (www.opengroup.org)

Some of these organisations are dedicated to a specific technology (Frame Relay, ADSL, IP, ...) and so provide specific QoS solutions, while other fora are related to a specific category of telecommunications actors (ASP, operators, ...).

One can notice more generic organisations like standardisations bodies, such as IETF, DMTF, ITU etc, and industrial consortia/fora like TMF, 3GPP, EURESCOM. So in this document the special attention will be paid to the works of these particular organizations.

[INCLUDE HERE HOW WE MAKE THE CHOICES ... SEE WITH OTHER CONTRIBUTING PARTNERS]

[IDEAS: INFLUENCE, AUDIENCE, TECHNICAL, ...]


2

1.3 Document StructureIn the following sections, we start with a general presentation of relevant standardisation bodies (Part 2). Then we strive to pay in-depth attention to particular QoS-related works developed within each of the considered organizations (Parts 3, 4, 5, Error: Reference source not found), ended up with the comparison of the presented approaches (Part Error: Referencesource not found). Finally, a proposition for QoS management framework will be made (Part 6) in the light of particular QoS requirements and service models to be identified in ADANETS project.

Note that this deliverable is a jointly written document. Its different parts were allocated to these ADANETS partners:

Problem statement, TMF, DMTF and 3GPP review – Alcatel,

IETF review – LIP6,

QoS management framework – both partners.

Note that the parts written up to now were cross-reviewed by the contributing partners (Alcatel and LIP6).


3

2 STANDARDIZATION BODIES PRESENTATION

2.1 Internet Engineering Task Force (IETF)

2.1.1 Global Presentation

Figure 2: http://www.ietf.org

Internet Engineering Task Force (IETF) is an international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet.

The actual technical work of the IETF is done in 129 active working groups, which are organized by topic into 8 areas:

Applications Area

General Area

Internet Area

Operations and Management Area

Routing Area

Security Area

Sub-IP Area

Transport Area

The IETF essentially works on frameworks and protocol specifications for the Internet. Technical documents are published as drafts or RFCs (Request For Comment). Internet-draft is considered as "work on progress" and not a means to publish specification. Specifications are published through RFCs. Much of the work is handled via mailing lists. It is open to any interested individual. The IETF holds meetings three times per year to discuss on drafts and RFCs relevant to working groups.


4

2.1.2 QoS Related ActivitiesMany working groups (WG) in the IETF are relevant to QoS provisioning in the Internet, especially at IP level. Many proposals relating QoS mechanisms and Policy-based QoS management have been published.

In general, four approaches for QoS provisioning in IP network are identified as follows:

Integrated Services (Intserv) developed by Intserv WG / Transport Area. This WG has been concluded.

Differentiated Services (DiffServ) developed by DiffServ WG / Transport Area

MultiProtocol Label Switching (MPLS) developed by MPLS WG / Sup-IP Area

Constraint-based Routing developed by QoS routing WG / Routing Area. This WG has been concluded.

QoS Signalling developed by NSIS (Next Step In Signalling) WG / Transport Area.

QoS in Mobile IP developed by MobileIP WG / Internet Area.

Policy-based QoS management developed by Policy and RAP (Resource Allocation Protocol) WGs / Operations and Management Area

These QoS related works are presented in section 3.

2.2 TeleManagement Forum (TMF)

Figure 3: http://www.tmforum.org

2.2.1 Global PresentationThe TeleManagement Forum (TM Forum) is a non-profit global organization that provides leadership, strategic guidance and practical solutions to improve the management and operation of communications services. Its company membership comprises incumbent and new-entrant service providers, computing and network equipment suppliers, software solution suppliers and customers of communications services.

Since 1988, the TM Forum has provided solutions to many business and technology challenges born of global telecom deregulation and the growth


5

of IP related services. Dedicated to overall excellence in communications and information services management and to solving pressing OSS integration issues, the TM Forum and its member companies collaboratively identify, create, develop, and implement real solutions that automate and streamline information and communications operations.

All of the TM Forum's activities are geared to facilitate the search for common solutions to the information and communications services industry's most pressing operational needs.

2.2.1.1 TM Forum's StrategyTM Forum provides essential leadership to the information and communications services industry on the most effective ways to improve application of communications and information technologies, including services management. TM Forum has already established a common industry-wide strategic vision across a number of key areas such as:

New Generation Operations Systems and Software (NGOSS™)

Business Process Modeling and Automation

Managing Next Generation Network Technologies

Systems Integration and Implementation

Service Management

Web-Based Customer Care (E-Care)

Customer Relationship Management (CRM)

Managing E-Commerce

TM Forum members develop market-based solutions for integrating operational support systems and automating the key process flows.

2.2.1.2 TM Forum's ProgramsTM Forum’s overarching technical program, New Generation Operations Systems and Software (NGOSS™), is the cornerstone of TM Forum’s strategy to enable the industry to automate across end-to-end processes and to make plug and play more of a reality. The NGOSS Business Case, NGOSS Requirements document, NGOSS Roadmap and NGOSS Development and Integration Methodology provide a strong foundation for the ongoing work.

TM Forum's initiatives include seven key components:

Market Center Program allows members with similar business or sector needs and/or issues to collaborate on defining requirements, identifying key issues and challenges for the focus area and for directing work of other Forum teams to address these needs or issues.

NGOSS™ Business Frameworks Program focuses on the development of the business frameworks that service providers require from a process and information standpoint. The Telecom Operations Map is the industry’s ‘de facto’ standard view of


6

information and communication services processes. It has been validated for IP related services, as well as Mobile services. eTOM: The QoS/SLA project’s SLA Handbook is an example of a different kind of business framework definition that has strong interest across TM Forum members.

NGOSS™ Business Application Contracts and the NGOSS™ Shared Data Model ,along with Systems Process Plans, provide the link between service provider business processes and the business system applications and the systems architecture or platform that supports it.

NGOSS™ Systems Frameworks Program focuses on the developing the systems frameworks required for which ‘well behaved’ components/ applications can plug in or out.

NGOSS™ Information/Data Modeling Program is a set of teams that develop business requirements models and information models for specific interfaces, business needs or problems.

Catalyst Program is driven by member companies to validate conclusions reached in the eTOM Business Process Framework and NGOSS™Systems Framework projects to speed industry agreement and the introduction of true "plug and play" products to market, i.e., make products available to service providers.

TeleManagement World Conference is an OSS and BSS conference for the industry. It is a means to keep up with and investigate changes facing industry – a place where service providers, system integrators, suppliers, software developers and network equipment manufacturers can discuss key business issues, view emerging technology trends, and observe real-world solutions in operations and management for the information and communications services industry.

TM Forum Member and Deliverable Marketing provides opportunities for member marketing, e.g., TMW Expo and the TMFCentral.com Web site.

2.2.2 QoS Related ActivitiesWithin the TM Forum, QoS activities are disseminated into several groups:

Telecom Operation Map (eTOM)

Service Level Agreement and QoS Management Team (producer of the SLA handbook)

Policy-based Management Team

IP network management team

Various catalyst projects

These activities are described in section 4.


7

2.3 Distributed Management Task Force (DMTF)

Figure 4: http://www.dmtf.org

2.3.1 Global Presentation

2.3.1.1 Mission and GoalsThe DMTF is the industry organization that is leading the development, adoption and unification of management standards and initiatives for desktop, enterprise and Internet environments. Working with key technology vendors and affiliated standards groups, the DMTF is enabling a more integrated, cost-effective, and less crisis-driven approach to management through interoperable management solutions.

The mission of the DMTF is to lead the development of management standards for distributed desktop, network, enterprise and Internet environment.

The goals are:

Accelerate adoption of management standards

Unify industry management initiatives

Promote interoperability among management solution providers

2.3.1.2 MembershipThe DMTF offers several levels of membership for corporations, industry organizations, and academic institutions. These include Contributing Member, Associate Member, Alliance Partner, and Academic Alliance. These four types of membership offer different levels of responsibility and privilege. Alliance Partner and Academic Alliance membership are at the invitation of the DMTF Board.

Contributing members: receive DMTF specifications and access to DMTF developed standards; full voting privileges and opportunity to lead the definition and development of management through participation and leadership in working groups

Associate members: receive access to DMTF specifications, standards, and tools for development of management and managed products and services; participation in one working group per committee

Alliance Partner members: a way for the DMTF to formalize synergistic relationships with other standards groups; participate in DMTF working groups as a non-voting member, and in the DMTF Marketing Committee, and Technical Committees and the appropriate DMTF Working Groups as a non-voting members


8

Academic Alliance members: participate in DMTF working groups as a non-voting member, and in the DMTF Marketing and Technical Committees as a non-voting member

2.3.1.3 Working Groups and CommitteesTwo top-level committees, the Technical Committee and the Marketing Committee, oversee the operations of DMTF's working groups. Working groups, comprised of DMTF members with specific areas of expertise, develop guidelines for implementing the DMI (Desktop Management Interface) and CIM (Common Information Model) specifications for different products or applications. DMTF working groups are established and dissolved on an as-needed basis.

The Marketing Committee communicates with the industry, the public, and members about the activities of the organization. This committee oversees two working groups:

Web-Based Enterprise Management (WBEM): initiative based on a set of management and Internet standard technologies developed to unify the management of enterprise computing environments. WBEM provides the ability for the industry to deliver a well-integrated set of standard-based management tools leveraging the emerging technologies such as CIM and XML

Customer Advisory Board: works to ensure that DMTF technology directives are meeting current and future industry needs. It acts as a channel for continuous feedback and vision from the end-user community

The Technical Committee develops standards and initiatives for the DMTF. The Technical Committee oversees the following working groups:

Applications: develops DMI definitions of management for Web-based and networked application services

Database: defines the information model that characterizes the common properties and services performed by a database

Desktop Management Interface (DMI): defines and maintains DMI specifications and push the DMI Technology in the Desktop Management arena

Lightweight Directory Access Protocol (LDAP): develops LDAP schemas from CIM models to support industry standard Directory Enabled Networking (DEN)

Networks: uses DEN initiative as a starting point to ensure seamless integration with directory services

Policy (formerly known as the Service Level Agreement Working Group): extends the CIM syntax and metaschema to allow the definition and association of policies, rules and expressions that enables internal and industry communications with respect to service

Pre-OS


9

CIM Support: defines objects and access methods necessary for support information to be shared between service requesters and providers

System and Devices: defines component(static and inventory-related objects and features)and behavioural(events, rules and methods) aspects of the existing high-level System, ComputerSystem, OperatingSystem, LogicalDevice and PhysicalElement classes, and their derived and related objects

CIM User and Security: defines objects and access methods required for principals, where principals include users, groups, consumers, and organizations. Where possible, the working group endeavours to use the existing body of work in this area

WBEM Interoperability: is responsible for defining architectures and mechanisms that enable WBEM implementations to interoperate in an open, standard manner, and for addressing issues that prevent them from doing so

2.3.2 QoS Related ActivitiesThe DMTF is not really dedicated to the study of QoS, but activities like CIM and DEN initiatives can be applied to QoS. Mainly, QoS activities at the DMTF are applications of the CIM Network model.

These activities are described in section 5.


10

3 IETF AND QOS PROVISIONING

3.1 Integrated ServicesThe Integrated services model [2] is characterized by per micro-flow resource reservation in each router. Resource ReSerVation Protocol (RSVP) [5] is a signalling protocol for setting up paths and reserving resources. The signalling process concerns the endpoints and all intermediate routers along the path between end-points.

Figure 5: RSVP signalling in Intserv domain

As illustrated in Figure 5, the sender sends a message PATH through the network towards the receiver. This message contains traffic characteristics of the flow generated by the sender. At each hop, the router analyses the PATH message, creates a path state and forwards the PATH message to the next hop using normal routing. Upon receiving the PATH message, the receiver responds with a RESV message to request the resources in the path fixed by PATH message.

Intserv model proposes two service classes other than Best-effort:

- Guaranteed Service [3] for application requiring fixed delay bound.

- Controlled-Load Service [4] for applications requiring reliable and enhanced best-effort service.

The routers receive RESV message, make Admission Control and Policy Control for this reservation. The Admission Control is locally made in the router. If the router has sufficiently resources for the reservation request, the request is admitted. The Policy Control depends on the resource allocation policy of the domain. If both controls are positive, the router makes reservation for the traffic flow.


11

This model requires flow-specific maintenance in routers along the path which causes the scalability problem. Several ways to reserve resources for aggregation has been proposed [6].

3.2 Differentiated ServicesIn Differentiated Services [10] model, packets are marked differently to create several packet classes. No signalling protocol is needed. Different classes are marked using the TOS (Type Of Service) field in IPv4 header or in TC (Traffic Class) field in IPv6 header.

In contrast of Intserv architecture, DiffServ pushes the complexity to edges routers. Figure 6 presents a DiffServ edge router architecture.

Figure 6: DiffServ edge router architecture

As illustrated in Figure 6, traffic is classified in the Classifier at the edge router to measure the conformity with traffic profile specified in the SLA (Service Level Agreement). The Meter component classes traffic into in-profile or out-profile. The Marker set appropriate DSCP values corresponding to the behaviour the packets receives from the domain. Shaper/Dropper can shape or drop out-profile traffic to ensure the conformity of traffic flow before entering the domain. Core routers only bases on DSCP value of IP packets to treat them with corresponding behaviour call PHB (Per Hop Behaviour). As core routers do not involve in micro-flows, this architecture allows a high scalability.

DiffServ architecture defines two PHBs other than Best-effort:

- Expedited Forwarding (EF): for applications requiring low delays, low jitter as leased line service.

- Assured Forwarding (AF): for applications requiring better reliability than Best-effort service.

In addition to the PHB concept, this working group has also defined the PDB (Per Domain Behaviour). While the PHB defines the behaviour of a DiffServ node corresponding to a DSCP, the PDB defines the behaviour of a DiffServ domain corresponding to an aggregation. A PBD is defined as the expected treatment that an identifiable or target group of packets will receive from "edge-to-edge" of a DiffServ domain. A guideline for PDB


12

specification is provided in [23] but no specific PDB is standardized by this WG until now.

As there is no signalling, network resources in Diffserv domain is provisioned by configuring DiffServ routers. Customer and provider agree upon a service level for the traffic stream. The QoS parameters are specified in the SLS (Service Level Specification) which is the technical part of the SLA. Network resources are provisioned fitting with the SLA by appropriate configuration installed in DiffServ router in the domain. An approach for DiffServ router configuration will be presented in section 3.

As objectives in the charter of this WG has almost completed, this WG will be concluded soon.

3.3 Multiprotocol Label SwitchingMultiProtocol Label Switching [1] is a forwarding scheme. A packet is assigned to a particular FEC (Forwarding Equivalent Class) by adding a label [12] after data link layer header and before network layer header.

As illustrated in Figure 7, label assignment is made once as the packet enters the network. No further header analysis is necessary in subsequent routers. The label is used as an index into a table which specifies the next hop, and a new label. The old label is replaced by the new label. The packet is forwarded to its next hop.

Figure 7: MPLS model


13

This architecture needs a signalling protocol for label distribution to set up LSPs (Label Switched Path). LRSs. Label Distribution Protocol (LDP) [10] and Constraint-based LSP setup using LDP (CR-LDP) [11] are two protocols defined for explicit purpose of distributing labels.

MPLS allows the precedence or class of service to be fully or partially inferred from the label. In this case, the label represents the combination of a FEC and a precedence or class of service. This enables to provide QoS inside an MPLS domain.

3.4 Traffic Engineering (TE)Generally, TE offers relevant resource/performance optimisation functions in network equipment with the goal to provide IP traffic transport in the most reliable, efficient and predictable way.

Within the IETF, the TEWG (Traffic Engineering Working Group) has publishing many internet draft documents that discuss the issues related to traffic engineering, from the problem statement to some particular technical solutions (for using MPLS together with DiffServ…). Particularly two drafts are related to the Intelligent Triggering issues, that deal respectively with the definition of the congestion problem and the means for combating it [TE-PRINC] and with the applicability of MPLS for performing traffic engineering, particularly to deal with congestion problems [TE-MPLS]. An Informational RFC written in 1999 is also available [RFC-2702], that deals with the usage and requirements of MPLS for traffic engineering.

[RFC-2702] describes the major goal of traffic engineering as to facilitate efficient and reliable network operations while simultaneously optimizing resource utilization and traffic performance. The optimization aspects of traffic engineering can be achieved through capacity management and traffic management. Traffic management includes nodal traffic control functions such as traffic conditioning, queue management, scheduling, and other functions that regulate the traffic flow through the network or that arbitrate access to network resources between different packets or between different traffic streams. Capacity management includes capacity planning, routing control, and resource management. Network resources of particular interest include computational resources, buffer space, and link bandwidth. Therefore a central function of traffic engineering is to efficiently manage bandwidth resources. Minimizing congestion is a primary traffic and resource oriented performance objective.

Congestions typically manifest under two scenarios, when network resources are insufficient or inadequate to accommodate offered load, or when traffic streams are inefficiently mapped onto available resources, causing subsets of network resources to become over-utilized while others remain underutilized. Congestion management policies can be categorized based upon the following criteria:

(1) Response time scale;

(2) reactive versus preventive (that is congestion control versus congestion avoidance);


14

(3) supply side versus demand side congestion management schemes [TE-PRINC].

Congestion management based on response time scale:

Long (weeks to months): Capacity planning to expand network capacity based on forecasts of future traffic demand and traffic distribution. Since router and link provisioning take time and are generally expensive, these upgrades are typically carried out in the weeks-to-months or even years time scale.

Medium (minutes to days): Several control policies fall within this category. Adjusting BGP parameters to route traffic away from certain segments of the network; Adjusting some label switched paths in MPLS networks to route some traffic trunks away from possibly congested resources or towards possibly more favorable routes; Re-configuring the logical topology of the network to make it correlate more closely with the spatial traffic distribution. Many of these adaptive medium time scale response schemes rely on a measurement system that monitors changes in traffic distribution and network resource utilization.

Short (picoseconds to minutes): This category includes packet level processing. It includes router mechanisms such as passive and active buffer management. One of the most popular active queue management schemes is Random Early Detection (RED), which supports congestion avoidance by controlling the average queue size. For a router that does not utilize explicit congestion, the marked packets can simply be dropped to signal the inception of congestion to end systems.

Congestion management, reactive versus preventive schemes:

Reactive: reactive (recovery) congestion management policies react to existing congestion problems to improve it. All the policies described in the long and medium time scales above can be classified as being reactive.

Preventive: preventive (predictive/avoidance) policies take proactive action to prevent congestion based on estimates and predictions of future potential congestion problems. Some of the policies described in the long and medium time scales fall into this category. They do not necessarily respond immediately to existing congestion problems. Instead forecasts of traffic demand and workload distribution are considered and action may be taken to prevent potential congestion problems in the future. The schemes described in the short time scale are also used for congestion avoidance since dropping or marking packets before queues actually overflow would trigger corresponding TCP sources to slow down.

Congestion management, supply side versus demand side schemes:

Supply side: supply side policies may expand or augment network capability to better accommodate offered traffic. Supply side policies may also re-allocate network resources by redistributing traffic over the infrastructure.


15

Demand side: demand side policies may restrict access to congested resources and/or dynamically regulate the demand to alleviate the overload situation.

[TE-MPLS] investigates and validates the usage of MPLS to perform network performances optimization. Specifically, it deals with the ability to move traffic away from IGP-selected shortest paths onto alternate LSPs to avoid congestion in the network. [RFC-2702] defines the notion of traffic trunks. These aggregates of traffic flows represent the traffic model that is required to enable traffic engineering over MPLS. They will in fact be implemented as LSPs. Those traffic trunks must be associated with a set of attributes:

Traffic parameters, that indicate the resource requirements of the traffic trunk.

Generic path selection and maintenance attributes, that define the rules for selecting the route taken by the traffic trunk.

Priority, to determine the order path selection is done for traffic trunks at connection establishment.

Preemption, to assure priority of a traffic trunks upon another.

Resilience, the behaviour of the traffic trunk under fault (not reroute, reroute…).

Policing, actions that should be taken when traffic trunk becomes non compliant.

Resource attributes, which are used to constrain the routing of traffic trunks through specific resources. The affinity attribute enables to define class of resources.

[TE-MPLS] gives scenarios where MPLS is applicable to traffic engineering:

Avoidance of congested resources: LSP-tunnels could be created only when necessary to address specific congestion problems. For example, an LSP can be created between two nodes (source and destination) that are known to contribute traffic to a congested network element, and explicitly route the LSP through a separate path to divert some traffic away from the congestion. On the other hand, operators who make extensive use of LSP-tunnels may decide to explicitly route a subset of the LSPs that traverse the point of congestion onto alternate paths.

Resource utilization in network topologies with parallel links: MPLS-based approaches commonly used in practice to deal with parallel links include using LSP bandwidth parameters to control the proportion of demand traversing each link, explicitly configuring routes for LSP tunnels to distribute them across the parallel links, and using affinities to map different LSPs onto different links.

Implementing routing policies using affinities: It is sometimes desirable to restrict certain types of traffic to certain types of links, or to explicitly exclude certain types of links in the paths for some types


16

of traffic. MPLS resource affinities provide a powerful mechanism to implement these types of objectives.

Re-optimization after restoration: After the occurrence of a network failure, it may be desirable to calculate a new set of paths for LSPs to optimize performances over the residual topology.

3.4.1 Constraint-based routing (CBR)Constraint-based routing (CBR) is one of the Traffic Engineering approaches [15]. Constraint-based routing aims at finding routes that are subject to some constraints, such as bandwidth or delay requirements, policy of the domain. The resulting route must satisfy the given constraints and is optimal with respect to selected criterion/criteria (metric pertaining to some network or link characteristic, e.g. hop count, unreserved bandwidth).

To determine a route, constraint-based routing considers network topology, the requirements of the flow, resource availability of the links and policies specified by network administrator. Therefore, this approach allows network traffic to be distributed more evenly. Network utilisation can be improved.

To distribute topology and resource availability information, one approach is extending OSPF (Open Shortest Path First) routing protocol [14, 15]. From there, the route can be computed based on common metrics such as momentary cost, hop count, bandwidth, reliability, delay, and jitter. However, route computation leads to increased communication and computation overhead, increased routing table size and may hurt the stability of the network.

3.5 QoS SignallingQoS signalling is the subject of NSIS (Next Step In Signalling) Working Group which has just been established since 52th IETF at Salt Lake City in December 2001. This WG aims for defining an architecture and protocol for signalling QoS in order to allow users to obtain QoS-aware services, irrespective of underlying mechanisms used.

This working group is still in the beginning stage. A draft of requirements for QoS signalling protocol is under discussion in the group [21]. In general, QoS may be signalled in different parts of the networks such as end-to-edge, end-to-end, end-to-proxy, edge-to-edge,etc. The protocol should be simple and flexible for both per flow and per trunk QoS signalling in both wireless and wired networks.

An analysis of existing signalling protocol, especially RSVP will be the starting point.

3.6 Mobile IP related QoS activityMobile IP [22] is the protocol introduced by the IETF mobileip WG to ensure correct routing of packets to mobile node as the mobile node


17

changes its point of attachment to the Internet. In addition to the connectivity maintenance of a mobile host, there is a need to QoS maintenance when the mobile host changes its point of attachment. An internet draft has been submitted to describe the QoS requirements of Mobile IP protocol [23].

An approach for solving QoS problem in Mobile IP has been suggested in this draft. It is based on four important steps, but the draft describes only the first step. They are as follows:

(1) List the requirements that Mobile IP places on the QoS mechanism,

(2) Evaluate current IP QoS solutions against these requirements,

(3) Decide if current solutions need to be extended, or if new ones need to be defined, and

(4) Depending on the result of step 3, define new solutions or fix the old ones.

The QoS requirements described in this draft are:

- Performance requirements

o Minimize the interruption in QoS at the time of handover

o Localize the QoS (re)establishment to the affected parts of the packet path in the network

o Releasing after handover the QoS state (if any) along the old packet path

- Interoperability requirements

o Interoperability with mobility protocols

o Interoperability with heterogeneous packet paths as regards QoS paradigms

- Miscellaneous requirements

o QoS support along multiple packet paths

o Interactions with link-layer support for QoS

- Standard requirements

o scalability, security,

o conservation of wireless bandwidth, low processing overhead on mobile terminals,

o providing hooks for authorization and accounting,

o and robustness against failures of any Mobile IP-specific QoS components in the network.


18

3.7 Policy FrameworkThe policy framework IETF WG has provided several drafts describing a general framework as illustrated on Figure 8 for representing managing, sharing and reusing policies in a vendor independent, interoperable and scalable manner as well as defining an extensible information model for representing policies (PCIM: Policy Common Information Model) [19] and an extension to this model PCIMe [20] which will be described in the next sections.

The framework defined by the policy WG defines a policy as an aggregation of policy rules. Each policy rule includes a set of conditions and a corresponding set of actions that are intended to be device and vendor independent. Policy rules are of the form: if <condition> then <action>. The condition expression may be compound expression and it may be related to entities such as host, applications, protocols, users, etc. The <action> expression may be a set of actions that specify services to grant or deny or other parameters to be input to the provision of one or more services. The major functional elements introduced by this WG are the policy management tool to enable an entity to define, update and optionally monitor the deployment of policy rules. A policy repository which stores and retrieves policy rules. A policy decision point (PDP) which is a convenient grouping of functions, responsible for acquiring deploying and optionally translating policy rules into a form usable for policy enforcement point (PEP). A PEP is an element whose behaviour is spelled out by policy rules, carrying out the action indicated by policy rule.

Figure 8: Policy IETF WG framework

3.7.1 PCIM and PCIMe ModelsPCIM is the object oriented information model for representing policy information developed jointly in the IETF policy Framework WG as an extension to the Common Information Model (CIM) activity developed in


19

Policy management tool

PDP (Policy Decision Point)

PEP(Policy Enforcement Point)

Policy repository

the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes and association classes. The former represents the policy information and the control of policies; the latter indicate how instances of the structural classes are related to each other. The policy classes and the associations defined in this model are sufficiently generic to represent policies related to different areas. In fact, in the IETF, the initial application was the representation of the policies related to QOS (DiffServ and IntServ) and to IPSec.

PCIMe proposes a number of changes to PCIM; it is an extension model of PCIM. These changes include extensions of PCIM into areas that it did not previously cover, and proposes changes to the existing PCIM classes and associations. Both set of changes are done in a way that preserves interoperability with implementations of the original PCIM model.

Currently PCIMe is an IETF draft version. However PCIM is an RFC.

3.7.1.1 Modelling PoliciesPolicies represent business goals and objectives. A translation must be made between these goals and objectives and their realization in the network. An example of this translation is a Service Level Agreement (SLA), and its objectives and metrics (Service Level Objectives, or SLOs) that are used to specify the service that the network will provide for a given client. The SLA is usually written in a high-level business terminology. SLOs are more specific metrics, which details the objectives of the SLA. These high-level descriptions of network services and metrics must be translated into lower level, but also vendor and device-independent specifications. The Policy Core Information Model (PCIM) classes are intended to serve as the foundation for these lower-level, vendor and device-independent specifications.

The definition of PCIM is generic and is applicable to QOS, non-QOS applications (e.g. DHCP and IPSec) and to non-networking applications (e.g., backup policies, auditing access, etc…). Note also that this information model defines a set of attributes, and a set of entities that contain these attributes. However, it does not define either the algorithm to produce a result using the attributes or an explicit sequence of steps to produce a result. For this reason PCIM is better described by a declarative, and not a procedural approach.

The objective of PCIM model is to present an extensible class hierarchy for defining policy objects that enables application developers, network administrators, and policy administrators to represent policies of different types.

In order to accomplish this goal, the approach taken is to consider the policy-controlled network as a state machine and then use policy to control which state a policy-controlled device should be in or is allowed to be in at a given time. Given this approach, a policy is applied using a set of policy rules, which are represented in the PCIM schema by a class called “PolicyRule”. Each policy rule consists of a set of conditions and a set of actions. Similarly, two classes are used to represent the conditions and the


20

actions parts of the policy rule; they are called “PolicyCondition”, and “PolicyAction”.

The set of conditions in a policy rule can be expressed by an ORed set of ANDed sets of conditions statement or an ANDed set of Ored sets of conditions statement. These combinations are termed, respectively, Disjunctive Normal Form and Conjunctive Normal Form (CNF) for the conditions.

If the set of conditions associated with a policy rule is evaluated to TRUE, then a set of actions is achieved. The actions either maintain the current state of the object or transition the object to a new state. For the set of actions associated with a policy rule, it is possible to specify an order of execution, as well as an indication of whether the order is required or merely recommended. It is also possible to indicate that the order in which the actions are executed is not important.

Policy rules can themselves be prioritized. One common reason for doing this is to express an overall policy that has a general case with a few specific exceptions. It also helps to resolve policy conflicts that occur when several policy conditions of different policy rules evaluate to TRUE and the actions defined within these policy rules cannot be executed simultaneously. By executing the policy with the higher level of priority the conflict can be resolved. For example, a general QOS policy rule might specify that traffic originating from members of the engineering group is to get Bronze Service. A second policy rule might express an exception: the traffic originating from John, who is a specific member of the engineering group, is a Gold Service. Since the traffic originating from John satisfies the conditions of both policy rules, and since the actions associated with the two rules are incompatible, a priority needs to be established. By giving the second rule (the exception) a higher priority than the first rule (the general case), a policy administrator can get the desired effect which the traffic originating from John gets Gold Service, and the traffic originating from all the other members of the engineering group gets Bronze Service.

A policy rule may also be associated with one or more policy time periods, indicating the schedule according to which the policy rule is active and inactive. Figure 9 summarizes what have been said so far about a Policy Rule.

Figure 9: Overview of the Policy Rule Class


21

Policies can either be used in a stand-alone fashion or aggregated into policy groups to perform more elaborate functions. Stand-alone policies are called policy rules; policy groups are aggregations of policy rules, or aggregations of policy groups, but not both.

Policy Groups and their nesting capabilities are shown in Figure 10. Note that a Policy Group can nest other Policy Groups, and there is no restriction on the depth of the nesting in sibling policy groups.

Figure 10: Overview of the Policy Group Class

As a simple example one can think of the highest-level Policy Group (PolicyGroup shown in Figure 10) as a logon policy for US employees of a company. This Policy Group may be called USEmployeeLogonPolicy, and may aggregate several Policy Groups that provide specialized rules per location. Hence, PolicyGroup B may define logon rules for employees on the West coast while another Policy Group might define logon rules for the Midwest (PolicyGroup A), and so on. Note also that the depth of each Policy Group does not need to be the same. In addition, a policy group represents a unit of reusability and manageability in that its management is handled by an identifiable group of administrators and its policy rules would be consistently applied.

These notions presented above (i.e., policy rules, conditions, actions, groups) are the basic concepts to define the different classes comprising the Policy Core Information Model as will be seen in section 3.7.1.3.

3.7.1.2 Description of the PCIM ModelThe following subsections discuss several specific issues related to the Policy Core Information Model (PCIM), these issues are important to clarify before presenting the different classes comprising the Policy Core Information Model:

3.7.1.2.1Reusable versus Rule-specific Conditions and ActionsPolicy conditions and policy actions can be partitioned into two groups: one associated with a single policy rule, and ones that are reusable, in the sense that they may be associated with more than one policy rule. Conditions and actions in the first group are termed “rule-specific”; those in the second group are characterized as “reusable”. The reusable policy are represented


22

by a class called “PolicyRepository”, which is not the Policy Repository component defined within the Policy Framework to store policies in the network.

3.7.1.2.2RolesThe concept of role is central to the design of the entire Policy Framework. The idea behind roles is a simple one. Rather than configuring, and then later having to update the configuration of, hundreds or thousands of resources in a network, a policy administrator assigns each resource to one or more roles, and then specifies the policies for each of these roles. The Policy Framework is then responsible for configuring each of the resources associated with a role in such a way that it behaves according to the policies specified to that role. When network behavior must be changed, the policy administrator can perform a single update to the policy for a role, and the Policy Framework will ensure that the necessary configuration updates are performed on all the resources playing that role. A more formal definition of a role is as follows:

A role is a type of attribute used to select one or more policies for a set of entities and/or components from among a much larger set of available policies.

So in brief a role represents a functional characteristic or capability of a resource to which policies are applied. Examples of roles include Backbone interface, Frame relay interface, web server, firewall, etc… the multiple roles assigned to a single resource are combined to form that resource’s role combination. Role and role combinations are represented in PCIM by values of the PolicyRoles property in the “PolicyRule” class.

3.7.1.3 Overview of The PCIM ClassesAs can be seen from Figure 11, classes of PCIM are based on “ManagedElement” and “System” classes defined in CIM (see Section 5.1). In fact, the hierarchy is rooted by the “ManagedElement” class (defined in CIM), from this class is derived the class “Policy” serving as a base for deriving classes in PCIM, from “Policy” are derived the classes “PolicyRule”, “PolicyGroup”, “PolicyAction”, and “PolicyCondition”; and based on the “System” class defined in CIM is derived “PolicyRepository” Class through the “AdminDomain” (defined in CIM) which derives also from the System class. For this reason we say that PCIM is based on CIM to define its classes and it extends it to define classes related to the policy domain.


23

Figure 11: PCIM schema

This model defines two hierarchies of object classes:

- Structural Classes

- Association Classes

3.7.1.3.1Structural classesThese classes represent policy information and control of policies. Within this category of classes are defined:

a) The Abstract Class “Policy”: This class is the root of PCIM; it collects several properties that may be included in instances of any of the Core Policy classes. It is important to note that we must distinguish between an Abstract class and a Concrete class; the former cannot be instantiated while the latter can be instantiated. This class is derived from the “ManagedElement” Class defined in CIM of the DMTF.

b) The “PolicyGroup” Class: This class is a generalized aggregation container. It enables PolicyRules or PolicyGroups to be aggregated in a single container. This class is used to represent the policy group notion


24

presented previously. This class is derived from the “Policy” Class (see Figure 11).

c) The “PolicyRule” Class: “PolicyRule” class is derived from the “Policy” Class (see Figure 11). This class represents the “If Condition then Action” semantics associated with a policy. A PolicyRule condition, in the most general sense is represented as either an ORed set of ANDed conditions (Disjunctive Normal Form or DNF) or an ANDed set of ORed conditions (Conjunctive Normal Form). The actions specified by a PolicyRule are performed if and only if the PolicyRule condition is evaluated to TRUE. The conditions and actions associated with a policy rule are modeled respectively, with subclasses of the classes “PolicyCondition” and “PolicyAction”.

“PolicyRule” class has several important properties associated with it:

- The Property “Enabled”: the purpose of this property is to allow a policy administrator to enable or disable a policy rule without having to add it to, or remove it from the policy repository. It indicates whether a policy is currently enabled from an administrative point of view.

- The property “ConditionListType”: this property is used to specify whether the list of policy conditions associated with this policy rule is in Disjunctive Normal Form (DNF) or Conjunctive Normal Form (CNF).

- The property “RuleUsage”: is used to provide guidelines on how this policy should be used.

- The property “Priority”: it provides a non-negative integer for prioritizing policy rules relative to each other. Larger integer values indicate higher priority. As presented in section 1 prioritization among policy rules provides a basic mechanism for resolving policy conflicts.

- The property “Mandatory”: this property indicates whether evaluation of a PolicyRule is mandatory or not.

- The Property “SequencedActions”: this property gives a policy administrator the possibility to choose between doing the actions defined within the policy rule in the indicated order or not.

- The Property “PolicyRoles”: this property represents the roles and role combination associated with a policy rule.

d) The abstract class “PolicyCondition”: The purpose of a policy condition is to determine whether or not the set of actions should be executed or not, because it is general, the PolicyCondition class does not itself contain any real conditions. These are presented by properties of the domain-specific subclasses of the PolicyCondition class. This class derives from the “Policy” Class (see Figure 11).

e) The “PolicyTimePeriodCondition” class: This class provides a means of representing the time periods during which a policy rule is valid, i.e., active. At all times that fall outside these time periods, the policy rule has no effect; a PolicyRule is treated as valid at all times if it does not specify a PolicyTimePeriodCondition. This class derives from the “PolicyCondition” Class (see Figure 11).


25

f) The abstract class “PolicyAction”: The purpose of a policy action is to execute one or more operations that will affect network traffic and/or systems, devices, etc.., in order to achieve a desired state. A policy action ordinarily changes the configuration of one or more elements. No properties are defined for this class since it inherits all its properties from policy. The class exists as an abstract super class for domain-specific policy actions, defined in subclasses. This class is derived from the “Policy” Class.

g) The class “VendorPolicyAction”: This class is defined for vendor-specific extensions to the Policy Core Information Model. It is derived from the “PolicyAction” Class.

h) The class “ VendorPolicyCondition”: it is defined for vendor-specific extensions to the Policy Core Information model. It is derived from the “PoilicyCondition” Class.

i) The class “PolicyRepository”: it is a class representing an administratively defined container for reusable policy-related information. This class is derived from the “AdminDomain” Class defined in CIM of the DMTF.

3.7.1.3.2Association ClassesAn association is a CIM construct representing a relationship between two structural classes. The “two” classes may, however, be the same class, as is the case with the “PolicyGroupInPolicyGroup” Association (in Figure 11), which represents the recursive containment of PolicyGroups in other PolicyGroups as explained in section 3.7.1.1 (Modeling policies). It is modeled as a class containing two-object references referring to each of its related classes.

An association includes cardinalities for each of the related classes. These cardinalities indicate how many instances of each class may be related to an instance of the other class. For example, the “PolicyRuleInPolicyGroup” association has the cardinality range “*” (that is, “0..n”) for both the PolicyGroup and PolicyRule classes. These ranges are interpreted as follows:

The “*” written next to “PolicyGroup” (see Figure 11) indicates that a “PolicyRule” may be related to no PolicyGroups, to one PolicyGroup, or to more than one PolicyGroup via the “PolicyRuleInPolicyGroup” association. In other words, a PolicyRule may be contained in no PolicyGroups, in one PolicyGroups, or in more than one PolicyGroup.

The “*” written next to PolicyRule (see Figure 11) indicates that a PolicyGroup may be realted to no PolicyRules to one PolicyRule, or to more than one PolicyRule via the “PolicyRuleInPolicyGroup” association. In other words, a PolicyGroup may contain no PolicyRules, one PolicyRule, or more than one PolicyRule.

Associations within PCIM can be categorized into:

A- Aggregations:


26

An aggregation is a strong form of an association, which usually represents a “whole-part” or a “collection” relationship. For example CIM uses an aggregation to represent the containment relationship between a system and the components that make up the system. Under this category fall the following associations:

The abstract aggregation “PolicyComponent”: serving as the root for this category of associations in PCIM hierarchy, it is a generic aggregation used to establish “part of” relationships between the subclasses of “Policy” abstract Class. This abstract aggregation defines two object references that are overridden in each of the five subclasses PolicyGroup, PolicyRule, PolicyCondition, PolicyAction, and PolicyTimePeriodCondition. The value of this abstract superclass is to convey that all five subclasses have the same “whole-part” semantics, and for ease of query to locate all components of a PolicyGroup or PolicyRule for example. This aggregation relates the abstract class “Policy” to itself (as shown in Figure 11).

The Aggregation “PolicyGroupInPolicyGroup”: enabling policy groups to be nested as said before it is derived from the PolicyComponent class, this class represents the aggregation of PolicyGroups by a higher-level PolicyGroup.

The aggregation “PolicyRuleInPolicyGroup”: a policy group may aggregate one or more policy rules via this aggregation.

The aggregation “PolicyConditionInPolicyRule”: a policy rule may aggregate zero or more instances of the PolicyCondition class, via this aggregation.

The aggregation “PolicyRuleValidityPeriod”: it represents the aggregation of “PolicyTimePeriodCondition” by a “PolicyRule”, if a policy rule is associated with multiple policy time period via this aggregation, then the rule is active if at least one of the time periods indicates it is active. A policy time period may be aggregated by multiple policy rules. A rule that does not point to a policy time period via this aggregation is always active.

The aggregation “PolicyActionInPolicyRule”: a policy rule may aggregate zero or more policy actions via this aggregation. This aggregation has an important property called “ActionOrder” which indicates the relative position of an action in the sequence of actions associated with a policy rule.

B- Dependency

In this category we find the following associations:

The abstract association “PolicyInSystem”: this abstract association is derived from a higher-level CIM association class, Dependency. It is used to establish dependency relationships between policies and the systems that host them.

The association “PolicyGroupInSystem”: this association represents the fact that a PolicyGroup is defined within the scope of a System. This association is derived from the “PolicyInSystem” association.


27

The association “PolicyRuleInSystem”: represents the fact that a PolicyRule is defined within the scope of a System. It is derived from “PolicyInSystem”.

The association “PolicyConditionInPolicyRepository”: represents the inclusion of a reusable PolicyCondition in PolicyRepository. Derived from “PolicyInSystem”

The association “PolicyActionInPolicyRepository”: represents the inclusion of a reusable PolicyAction in a PolicyRepository.

C- Component relationships

In this category the following associations are found:

The aggregation “PolicyRepositoryInPolicyRepository” enables policy repositories to be nested. It derives from the higher-level CIM association, CIM_SystemComponent, describing that Systems contain other ManagedSystemElements.

3.7.1.4 Changes To PCIM defined in PCIMe

3.7.1.4.1Changes to the Class “PolicyRepository”As we have seen in PCIM the class “PolicyRepository” was introduced to represent containers of reusable policy elements, but due to the potential for confusion of with the Policy Framework component Policy Repository. it was decided that “PolicyRepository” was a bad name to represent a container of reusable policy elements. Thus the class “PolicyRepository” is being replaced in PCIMe with the class “ReusablePolicyContainer”, to accomplish this change it was necessary to deprecate the PCIM class “PolicyRepository” and its three associations, and to replace them with a new class “ReusablePolicyContainer” and new associations.

3.7.1.4.2Additional Associations and Additional Reusable ElementsIn PCIM we have seen the two aggregations “PolicyGroupInPolicyGroup” representing the nesting of policy groups by higher-level policy groups, and “PolicyRuleInPolicyGroup” representing the aggregation of policies in groups. These aggregations as well as the “PolicyRuleInPolicyRule” and “PolicyGroupInPolicyRule” aggregations imported from QPIM are all combined in PCIMe into a single aggregation “PolicySetComponent”. These aggregations make it possible to define larger “chunks” of reusable policy to place in a “ReusablePolicyContainer”.

3.7.1.4.3Priorities and Decisions StrategiesAs was presented in Section 3.7.1.3 in PCIM, the “PolicyRule” class has a property called “Priority” indicating the priority of a policy rule relative to other policy rules, drawing from QPIM and ICPM, this “Priority” property has been deprecated in “PolicyRule”, and placed instead on the aggregation


28

“PolicySetComponent” defined in the subsection above. With the removal of the Priority property from “PolicyRule”, a new modeling dependency was introduced. In order to prioritize a PolicyRule/PolicyGroup relative to other PolicyRules/PolicyGroups, the elements being prioritized must all reside in one of three places: in a common PolicyGroup, in a common PolicyRule, or in a common System. In addition to this change done on the “Priority” property of the “PolicyRule” class, a PolicyDecisionStrategy property has been added to the “PolicyGroup” and “PolicyRule” classes. In order to this to be done a new class was defined “PolicySet” from which “PolicyGroup” and “PolicyRule” classes are derived as shown in the following figure:

Figure 12: „PolicySet“ superclass

The PolicyDecisionProperty allows a policy administrator to select one of two behaviors with respect to rule evaluation: either performs the actions for all PolicyRules whose conditions evaluate to TRUE, or perform the actions only for the highest-priority PolicyRule whose condition evaluate to TRUE.

3.7.1.4.4Policy RolesIn PCIM, role (s) are only associated with “PolicyRules” (as presented in section 3.7.1.3 in PCIM). In PCIMe the concept of policy rules is added to PolicyGroups, because it may be desirable to associate roles with groups of policy rules. For example, a network administrator may want to define a group of rules that only apply to “Ethernet” interfaces. A policy group can be defined with a role-combination = “Ethernet”, and all the relevant policy rules can be placed in this policy group, doing that in PCIM was not possible, for this reason this change has been defined in PCIMe, by moving PCIM’s PolicyRoles property up from PolicyRule to the new abstract class “PolicySet” serving as a superclass for both “PolicyRules” and “PolicyGroups” as shown in Figure 12.

It was also observed that in PCIM there is no mechanism for assigning roles to resources. For example while it is possible in PCIM to associate a “PolicyRule” with the role “FrameRelay && WAN”, using the Priority property of this class, there is no way to indicate which interfaces match this criterion. For this reason a new “PolicyRoleCollection” class has been defined in PCIMe, representing the collection of resources associated with a particular role. In this case the linkage between a “PolicyRule” or


29

“PolicyGroup” and a set of resources is then represented by an instance of “PolicyRoleCollection”, equivalent values should be defined in the PolicyRoles property of PolicyRules and PolicyGroups, and in the PolicyRole property in PolicyRoleCollection.

3.7.1.4.5CompoundPolicyConditions and CompoundPolicyActionsThe concept of a CompoundPolicyCondition has also been imported into PCIMe from QPIM, and broadened to include a CompoundPolicyAction. In both cases the idea is to create reusable “chunks” of policy that can exist in a “ReusablePolicyContainer”.

A “CompoundPolicyCondition” class was defined as a “PolicyCondition” representing a Boolean combination of simpler conditions for this reason this class “CompoundPolicyCondition” is a subclass of “PolicyCondition” that introduces the ConditionListType property, used for assigning DNF/CNF (Disjunctive and Conjunctive Normal Form respectively) semantics to subordinate policy conditions.

A “CompoundPolicyActions” is a convenient construct to represent a sequence of actions to be applied as a single atomic action within a policy rule. This class is a subclass of the “PolicyAction” class. In many cases, actions are related to each other and should be looked upon as sub-actions of one “logical” action. An example of such a logical action is “shape & mark” (i.e., shape a certain stream to a set of predefined bandwidth characteristics and then mark these packets with a certain DSCP value). This logical action is actually composed of two different QOS actions, which should be performed in a well-defined order as a complete set. The “CompoundPolicyAction” construct allow creating a logical relationship between a number of actions, and to define the activation logic related with this logical action. The “CompoundPolicyAction” allows the reusability of these complex actions, by storing them in a ReusablePolicyContainer and reusing them in different policy rules.

3.7.1.4.6Simple Policy Conditions and Simple Policy ActionsSimple Policy Conditions

The “SimplePolicyCondition” class has been imported into PCIMe from QPIM as a subclass for the “PolicyCondition” defined in PCIM. This class models elementary Boolean expression of the form: “(<variable> MATCH <value>). The relationship “MATCH”, which is implicit in the model, is interpreted based on the variable and the value. As an example of a SimplePolicyCondition would be, the expression “SourcePort = = 80”, in this example “SourcePort” is a variable, “= =” is the relational operator denoting the equality relationship (which is generalized by PCIMe to a “MATCH” relationship), and “80” is an integer value.

So the “SimplePolicyCondition” class refines the basic structure of the PolicyCondition class defined in PCIM by using the pair (<variable>, <value>) to form the condition. Note that the operator between the variable and the value is always implied in PCIMe: it is not a part of the formal notation. Simple conditions can be used in policy rules directly, or as building blocks for creating compound policy conditions (presented in the


30

previous subsection). Composing a simple condition requires that an instance of the class “SimplePolicyCondition” be created, and that instances of the “Variable” and “Value” classes that it uses also exists (“Variable” and “Value” classes will be presented in the next subsection). Two aggregations are used to create the pair (<variable>, <value>). The aggregation “PolicyVariableInSimplePolicyCondition” relates a “SimplePolicyCondition” to a single variable instance. Similarly, the aggregation “PolicyValueInSimplePolicyCondition” relates a “SimplePolicyCondition” to a single value instance. The following figure depicts a SimplePolicyCondition with its associated variable and value:

Figure 13: SimplePolicyCondition structure

Legends:

“….” Represents the aggregation PolicyVariableInSimplePolicyCondition

“----” Represents the aggregation PolicyValueInSimplePolicyCondition

“___” Represents the association ExpectedPolicyValuesForVariable specifying an expected set of values that can be matched with a variable within a simple condition.

SimplePolicy Actions

The “SimplePolicyAction” defined in PCIMe models the elementary set of operation. “SET <variable> To <value>”, for example the action “set DSCP to EF” can be modeled by a simple action. In this example DSCP is a variable referring to the IP packet header DSCP field. “EF” is an integer or bit string value.

The “SimplePolicyAction” class refines the basic structure of the “PolicyAction” class defined in PCIM by specifying the contents of the action using (<variable>, <value>) pair to form the action. This class can be used in policy rules directly, or as building blocks for creating CompoundPolicyActions.

The following depicts a SimplePolicyAction with its associated variable and value:


31

Figure 14: SimplePolicyAction structure

Legend:

“….” Represents the aggregation PolicyVariableInSimplePolicyAction

“----” Represents the aggregation PolicyValueInSimplePolicyAction

“___” Represents the association ExpectedPolicyValuesForVariable specifying an expected set of values that can be matched with a variable within a simple condition.

3.7.1.4.7Variables and ValuesVariables

The class “Variable” is defined in PCIMe; this class didn’t exist in PCIM. A variable generically represents information that changes and that is set or evaluated by software. In policy, conditions and actions can abstract information as “policy variables” to be evaluated in logical expressions, or set by actions.

PCIMe defines two types of PolicyVariables:

Explicitly bound policy variables, represented by the class “PolicyExplicitVariable” derived from the abstract class “PolicyVariable”. Explicitly bound policy variables are evaluated within the context of the CIM schema and its modeling constructs, the “PolicyExplicitVariable” class indicates the exact model property to be evaluated or manipulated. For example, one can imagine a PolicyCondition testing whether a CIM ManagedSystemElement’s status property has the value “ERROR”, the Status property is an explicitly defined PolicyVariable because it is defined in the context of the CIM Schema, and evaluated in the context of a specific instance.

Policy implicit variables, represented by the class “PolicyImplicitVariable” derived from the abstract class “PolicyVariable” defined in PCIMe. Implicitly bound policy variables are evaluated outside of the context of the CIM schema and its modeling constructs, subclasses specify the data type and semantic of the PolicyVariables. These variables are not defined in the context of CIM, for example a PolicyCondition can make no explicit reference to a model construct that represents a network packet’s source address. In this case an implicit PolicyVariable is defined, to allow evaluation or modification of a packet’s source address. A domain-specific policy information model that extends PCIMe (as an example QPIM) may define additional implicitly bound variables either by deriving them directly from the class PolicyImplicitVariable, or by further refining an existing


32

variable class such as SourcePort for example. When refining a class such as SourcePort, existing-binding rules, type or value constraints may be narrowed.

Values

The abstract class “PolicyValue” defined in PCIMe is used for modeling values and constants used in policy conditions, and actions. The PolicyValue subclasses define three basic types of values: scalars, ranges and sets. For example, a well-known port number could be defined using the PolicyIntegerValue class defining a single value (80 for http), a range (80-88), or a set (80, 82) of ports, respectively.

PCIMe defines the following subclasses of the abstract class PolicyValue:

Classes for general use: “PolicyStringValue”, “PolicyIntegerValue”, “PolicyBooleanValue”, “PolicyBitStringValue”.

Classes for layer 3 network values: “PolicyIPv4AddrValue”, “PolicyIPv6AddrValue”.

Classes for layer 2 network values: “PolicyMACAddrValue”.

3.7.1.4.8Packet FilteringPCIMe contains two mechanisms for representing packet filters:

The most general, termed the domain-level model representing policies consumed by the Polcy Decision Ponit (PDP), expresses packet filters in terms of policy variables and policy values.

The other mechanism, termed the device-level model representing policies consumed by Policy Enforcement Points (PEPs), expresses packet filters in a way that maps more directly to the packet fields to which the filters are being applied.

Domain-level Packet Filters

For packet filtering specified at the domain level, a set of PolicyVariables and PolicyValues are defined, corresponding to the fields in an IP packet header plus the common Layer 2 frame header fields. Domain-level policy conditions that filter on these header fields are expressed in terms of CompounPolicyConditions, built up from SimplePolicyConditions that use these variables and values; this is illustrated in Figure 15. PCIMe proposes a common way to express IP packet filters. The following figure illustrates how packet-filtering conditions are expressed in PCIMe.


33

Figure 15: Domain-Level Packet Filters in PCIMe

Aggregation legend:

“…….” Represents the aggregation PolicyConditionInPolicyCondition

“-------” Represents the aggregation PolicyVariableInPolicyCondition

“_____” Represents the aggregation PolicyValueInSimplePolicyCondition

In Figure 15, each SimplePolicyCondition represents a single field to be filtered on: Source IP address, Destination IP address, Source port, etc. An additional SimplePolicyCondition indicates the direction that a packet is traveling on an interface: inbound or outbound.

The class “CompoundFilterCondition” presented in this figure is a subclass of “CompoundPolicyCondition”.

Device-Level Packet Filters

At the device level, packet header filters are represented by two subclasses of the abstract class “FilterEntryBase” defined in CIM:

“IPHeadersFilter” this concrete class contains the most commonly required properties for performing filtering on IP, TCP or UDP headers.

“8021Filter” this concrete class allows 802.1 source and destination MAC addresses, as well as the 802.1 protocol ID, priority, and VLAN identifier fields to be expressed in a single object.

Instances of these subclasses are not used directly as filters. They are always aggregated into a “FilterList” which is a class defined in PCIMe, by the aggregation EntriesInFilterList.

Sub models of PCIMe may define other subclasses of “FilterEntryBase” in addition to these two; ICPM for example, defines subclasses for IPSec-specific filters.

Here after is a class hierarchy of PCIMe:


34

CompoundFilterCondition

Simple Policy Condition



FlowDirection SrcIP DstIP In addr1 addr2

Figure 16: Class hierarchy of PCIMe

3.7.1.5 Conformance to PCIM and PCIMeBecause PCIM and PCIMe provide the core classes for modeling policies, they are not in general sufficient by themselves for representing actual policy rules. Submodels, such as QPIM and ICPM. They provide the means for expressing policy rules, by defining subclasses of the classes defined in PCIM and PCIMe, and/or by indicating how the PolicyVariables and PolicyValues defined in PCIMe can be used to express conditions and actions applicable to the submodel.

A particular submodel will not, in general, need to use every element defined in PCIM and PCIMe; PCIM and PCIMe themselves define elements that may be of use to submodels, remaining silent on whether implementations are required to support an element, or not.

3.7.2 QPIM Model QoS Policy Information Model (QPIM) [21] is a standard framework for specifying and representing policies that administer, manages and control access to network QOS resources. Such policies are called “QOS policies”. The framework consists of a set of classes and relationships that are organized in an object oriented information model, which is agnostic from any specific PDP or PEP implementation and independent of any particular QOS implementation mechanism. A primary goal of this information model is to assist human administrators in their definition of policies to control QOS resources.

QPIM builds upon PCIM and PCIMe to define an information model for QOS enforcement for DiffServ and IntServ services; this information model is independent of any particular data storage mechanism and access protocol. This enables various data models (directory scheme, relational database scheme, and SNMP MIBs) to be designed and implemented according to a single uniform model.


35

3.7.2.1 QOS Policy DefinitionThis section describes the process of using QPIM for the definition of QOS policy for a policy domain. The following Figure illustrates this Process.

Figure 17: The QOS Definition Information Flow

The process of QOS policy definition is dependent on 3 types of information:

Business requirements are informal sets of rules for specifying the behavior of various types of traffic that may traverse the network. For example the administrator may be instructed to implement policy such that VoIP traffic manifest behavior that is similar to voice traffic over telephone networks. This business rule prescribes specific behavior for this traffic type in terms of minimal delay, jitter and loss. QPIM is used to help map the business rule into a form that defines the requirements for conditioning different types of traffic in the network.

Particular type of QOS methodology used: DiffServ or IntServ methodologies may be used in the QOS policy definition process.

Topology of the network: which consists of an inventory of the network that makes up the network and the set of paths that traffic may take through the network. For example a network administrator may decide to use the DiffServ architectural model and classify devices using the roles “boundary” and “core”. While this is not a topological view of the network, many times it may suffice for the purpose of QOS policy definition.

The three above-mentioned elements are necessary prerequisites for defining traffic conditioning in QPIM [21]. In fact, QPIM enables a set of tools and classes for specifying traffic conditioning policy in a standard manner.

It provides specific classes to enable DiffServ and RSVP conditioning to be modeled. These class definitions are used to create instances of various policy constructs such as QOS actions and conditions that may be hierarchically organized in rules and groups. Examples of Policy actions are rate limiting, jitter control and Bandwidth allocation. Policy conditions are constructs that can select traffic according to a complex Boolean expression.


36

3.7.2.2 Modeling Abstract QOS PoliciesThis section provides a discussion of QOS policy abstractions and the way QPIM addresses this issue.

The main goal of QPIM is to create an information model that can be used to help bridge part of the conceptual gap between a human policy maker and a network element that is configured to enforce the policy. This wide gap implies several translation levels, from the abstract to the concrete; and QPIM is considered one step in this concretization. In fact, at the abstract end are the business QOS policy rules; once the business rules are known, a network administrator must interpret them as network QOS policy using QPIM constructs. QPIM facilitates a formal representation of QOS rules thus providing the first concretization level: formally representing humanly expressed QOS policy.

The translation process goes through the following steps:

Informal QOS Policy is expressed first by a human Policy maker: for example a policy could state: “All executive WEB requests should be prioritized ahead of other employees WEB requests”.

In this second step, a network administrator analyses the policy domain’s topology and based on this analysis; he determines the roles of particular device interfaces (in PCIM and PCIMe the “roles” concept was introduced as a concept used to select policies for a large number of devices from a large set of policies) a role may be assigned to a large group of elements, and then this will result in mapping a particular policy to a large group of interfaces.

The third step; after assigning roles to different network devices, the network administrator models the informal policy expressed in the first step, using the QPIM constructs, thus creating a formal representation of the abstract policy; for example, considering the example given in the first step the formal definition determined in this step will be “ if a packet’s protocol is HTTP and its destination is in the “Executives” user group; then assign IPP7 to the packet header”.

After determining the condition part and the action part of the policy in the third step; the network administrator assigns roles to policy groups created in the previous steps. Such assignment follows the objective of matching the network element’s roles assigned in step number 2 above.

In the fifth step a PDP translates policy constructs created in step number 3 into a device-specific configuration commands for all devices affected by the new policy (i.e., devices that have interfaces that are assigned a role matching the new policy construct’s roles). In this process, the PDP consults the particular device’s capabilities to determine the appropriate configuration commands implementing the policy.

For each PEP in the network, the PDP issues the appropriate device-specific configurations necessary to enforce the policy.

In the steps presented above; QPIM, PCIM and PCIMe are used in step number 3. So by presenting these different steps it is obvious what is the


37

position of QPIM in the translation process from high-level business rules into device configuration.

3.7.2.3 Design Goals and Their RamificationsBefore representing the Classes defined in QPIM it is necessary to explain the QPIM design goals, and how these goals are met in the information model classes defined.

3.7.2.3.1Policy definition orientedThe primary design goal of QPIM is to model policies controlling QOS behavior in a way that as closely as possible reflects the way humans tend to think about policy therefore QPIM is designed to address needs for policy definition and management but not device/network configuration. How this goal does is met in the information model design? In fact, there are several ramification of this design goal:

QPIM uses rules to define policies, based on PCIM and PCIMe. In fact Policy is best described using rule-based modeling due to the fact that humans tend to simplify problems by decomposing them into a condition part and an action part. In this approach a QOS policy is structured as a condition clause and an action clause. The semantic is simple: if the condition part evaluates to TRUE then a set of QOS actions are executed. The approach taken in QPIM did not subclass the “PolicyRule” class defined in PCIM in stead it defines subclasses of the following classes: “Policy”, “PolicyAction”, “SimplePolicyAction”, “PolicyImplicitVariable”, and “PolicyValue” presented in PCIMe and PCIM.

QPIM uses hierarchical organization of policies and policy information. This hierarchical design decision is based on the realization that it is natural for humans to organize policy rules in groups. Breaking down a complex policy into a set of simple rules is a process that follows the way people tend to think and analyze systems. QPIM utilizes the “PolicySetComponent” aggregation defined in PCIMe to provide an arbitrarily nested organization of policy information. So a policy group functions as a container of policy rules and/or policy groups. A Policy rule can also contain policy rules and/or groups using this aggregation.

Third QPIM does not force the policy writer to specify all the implementation details; rather it assumes that configuration agents PDPs interpret the policies and match them to suit the needs of device specific configuration. For example, a valid policy may include only a single rule that specifies that bandwidth should be reserved for a given set of traffic flows. The rule does not need to include any of the various other details that may be needed for implementing a scheduler that supports this Bandwidth allocation. It is assumed that a PDP or PEP would fill in these details using their default queue length settings. The policy writer need only specify the main goal of the policy, making sure that the preferred application receives enough bandwidth to operate adequately.


38

3.7.2.3.2Policy Domain ModelAn important design goal is to provide a means for defining policies that span numerous devices. In other words, QPIM [21] is a domain-level model not a device-level information model. A device-level information model is designed for modeling policy that controls a single device, its mechanisms and capabilities unlike QPIM. How does this goal is met in QPIM design?

This design goal has several ramifications:

QPIM uses the concept of roles defined in PCIM to define policies across multiple devices; this use enables a policy definition to be targeted to the network function of a network element rather than to the element’s type and capabilities. For example, network interface cards are categorized as “core” interfaces can be assigned the role name “core-interface”; this enables the administrator to design policies to configure all interfaces having the role “core-interface” independent of the actual physical devices themselves.

Second, QPIM models policy in a way designed to be independent of any particular device or vendor. This enables networks made up of different devices that have different capabilities to be managed and controlled using a standard set of policies. This makes QPIM really a Domain model.

QPIM allows the central management of global concepts, due to the ability present in QPIM to reuse all policy building blocks such as: variables, values, conditions, actions, traffic profiles, and policy groups and policy rules. This provides the flexibility to manage large set of policy rules over large policy domains. An example will illustrate this idea: consider a certain number of policy rules making use of an object named “FinanceSubnet” representing the subnet of the Finance department in an enterprise which is a value defined and maintained in a reusable objects container. Given the above policy rules, whenever business needs require a change in the subnet definition of the organization, all that’s required is to change the reusable value FinanceSubnet centrally and all referencing rules are immediately affected, without the need to modify each rule individually. Without this capability, the repository that is used to store the rules would have to be searched for all rules that refer to the finance subnet and then matching rule’s condition would have to be individually updated, which is more prone to error and less efficient.

3.7.2.3.3Enforceable PolicyAn important goal of QPIM is that Policy defined by its class constructs should be enforceable. This means that a PDP can use QPIM’s Policy definition in order to make the necessary decisions and enforce the required policy rules. For example, RSVP admission decisions should be made based on the policy definitions specified by QPIM.

QPIM is designed to be independent of any particular, vendor-dependent technology. However, QPIM’s constructs were designed having in mind that they should be always interpreted so that policy-compliant behavior can be enforced on the network on management. Therefore three fundamental requirements were to be satisfied in QPIM:


39

1. Policy specified by QPIM must be able to be mapped to actual network elements.

2. Policy specified by QPIM must be able to control QOS network functions without making reference to a specific type of device or vendor.

3. Policy specified by QPIM must be able to be translated into network element configuration.

How does QPIM satisfy these requirements? The answer is that QPIM satisfies requirements number 1 and 2 stated above by using the concept of roles (specifically, the PolicyRoles property, defined in PCIM). By matching roles assigned to policy groups and to network elements, a PDP can determine what policy should be applied to a given device. Requirement number 2 is also satisfied by making QPIM domain-oriented. And requirement number 3 is satisfied by modeling QOS conditions and actions that are commonly configured on various devices.

3.7.2.3.4QPIM Covers both Signaled and Provisioned QOSThe two predominant standards-based QOS methodologies developed so far are Differentiated Services (DiffServ) and Integrated Services (IntServ).

QPIM provides actions and conditions that control the classification, policing and shaping done within the Differentiated domain boundaries, using the classes “QOSPolicyAdmissionAction”, “QOSPolicyPoliceAction”, “QOSPolicyShapeAction” defined later. QPIM provides also actions that control the per-hop behavior within the core of the DiffServ network using the class “QOSPolicyPHBAction” and its associated subclasses “QOSCongestionControlAction” and “QOSPolicyBandwidthAction”.

Integrated services, together with its signaling protocol (RSVP), provide a way for end nodes to request QOS from the network. QPIM provides actions that control the reservation of such requests within the network, using the classes “QOSRSVPAdmissionAction” and “QOSPolicyRSVPSimpleAction” defined in the next section.

3.7.2.3.5Interoperability for PDPs and Management ApplicationAnother design goal of QPIM is to facilitate interoperability among policy systems such as PDPs and Policy Management Application. QPIM accomplishes this interoperability goal by standardizing the representation of Policy. Producers and consumers of QOS Policy needs only rely on QPIM based schemata to ensure mutual understanding and agreements on the semantic of QOS Policy.

3.7.2.4 Class Hierarchy Overview

3.7.2.4.1QOS ActionsQOS actions are policy enforced network behaviors that are specified for traffic selected by QOS conditions. QOS actions are modeled using the


40

classes “PolicyAction” (defined in PCIM), “SimplePolicyAction” (defined in PCIMe) as can be seen from the following picture:

Figure 18: Inheritance Hierarchy of classes in QPIM

QPIM provides an information model for specifying a set of rules that allow the network administrator to control both the selection of the flows that need to be provided with a preferred forwarding treatment, as well as specifying the specific set of preferred forwarding behaviours.

As mentioned before, QPIM is used with two technologies:

IntServ: in this case QOS actions defined through QPIM allow a PDP or a PEP to determine which RSVP requests should be admitted, and this is represented in QPIM by the class “QOSPolicyRSVPAdmissionAction” shown in Figure 18 and that will be illustrated later when presenting the different classes of QPIM.

DiffServ: in this case QOS actions allow controlling the edge enforcement including Policing, shaping and marking; using respectively the classes “QOSPolicyPoliceAction”, “QOSPolicyShapeAction” and “SimplePolicyAction” shown in Figure 18, and it allows controlling the Per Hop behaviors used in the network core using the classes “QOSPolicyPHBAction” and its subclasses “QOSPolicyBandwidthAction”, “QOSPolicyCongestionControlAction” shown in Figure 18.

It is important to note that admission control action (presented by the class “QOSPolicyAdmissionAction”) determine whether a flow or class of flows should be admitted. This is done by specifying an appropriate traffic profile using the “QOSPolicyTrfcProf” class and its subclasses given in Figure 18.

Refer to [21] to have more details about the QPIM classes.

3.8 Resource Allocation Protocol (RAP) WGThis section presents the contribution of Resource Allocation Protocol (RAP) working group in QoS provisioning. This working group has proposed the Policy-based management framework [7] and COPS


41

(Common Open Policy Service) protocol [8] as illustrated in the following picture.

Figure 19: Policy-based management architecture

A simple explication for this architecture is that network administrator can manage the network through creating policies in a human friendly manner thanks to the Policy Management Tool component. These policies are then stored in the Policy Repository. The Policy Decision Point (PDP) retrieves policies from the Policy Repository to apply at the Policy Enforcement Point (PEP) where these policies need to be enforced. Thus, network operation can be driven by policies created by network administrator.

COPS is a generic protocol designed to convey policy information between the PDP and the PEP. It specifies 10 messages and 29 generic objects and two models to convey policies in any area. For each specific policy area policy, we have an extension specification defining the format for appropriate objects used in the extension. For example, COPS-RSVP is a COPS extension used for Policy Control in RSVP. COPS-PR-DiffServ is another extension for Diffserv router configuration, etc.

3.8.1 COPS-RSVPIn the Intserv/RSVP model presented in Section 3.1, the Policy Control block in RSVP router corresponds to the Policy Enforcement Point (PEP) and the policy server corresponds to the Policy Decision Point (PDP). Policy information is conveyed between them using COPS protocol. When a router receives an RSVP message, it sends a COPS-RSVP [9] request to the policy server to obtain the policy applied to this request.

The policy control model used in COPS-RSVP is called outsourcing model [16]. The arrival of RSVP message is considered as an event of resource request. When an event occurs, the PEP cannot decide at once. It "outsources" a COPS request (REQ) to the PDP. Upon receiving the decision (DEC), the policy will be applied to this event. Finally, a report (RPT) is sent by the PEP to inform the policy enforcement result. This model is illustrated in the following figure:


42

Figure 20: Outsourcing model in COPS protocol

For example, when an RSVP router receives an RESV message, it retrieves necessary RSVP object and encapsulates them into COPS request (REQ) message to send to the PDP. Upon receiving the decision (DEC) message from the PDP, the RSVP can make or reject the reservation for this resource reservation request. Additional information such as priority can be also driven by the policy.

3.8.2 COPS-PR-DiffServCOPS is used in DiffServ model [16] to facilitate the router configuration process. As there is no signalling in DiffServ model, the needs of traffic flows are specified in the SLA. Network resources are appropriately provisioned before the customer starts traffic.

In DiffServ, the arrival of a DiffServ packet is considered as an event of resource consuming. The outsourcing model is not appropriate because the PEP cannot "outsource" a REQ message to PDP for each DiffServ packet arrival. The key problem in DiffServ is how to appropriately configure different traffic conditioning blocks presented in Section 3.2, as well as queues and schedulers. Therefore, the provisioning model has been proposed in COPS protocol to configure DiffServ routers. In this model, the PEP request for the policies at its start-up and installs appropriate configuration. When an event occurs, no request is sent for this event. The PEP applies directly the policies installed to this event. In case of policy changes, new policies will be applied upon receiving the new decision from the PDP. This model is illustrated in the following figure.


43

Figure 21: Provisioning model in COPS protocol

COPS protocol in this model is known as COPS-PR (COPS usage for Provisioning). COPS-PR defined a proper data format, a.k.a. PIB (Policy Information Base) to convey policy information. In contrast to built-in message approach in which the semantic of information conveyed by the protocol is defined by the protocol itself, the PIB separates information semantic definition and protocol operation specification. This is a strong point of COPS-PR which motivate the use of this model in many policy area. The main task in applying COPS-PR into a specific area is defining the PIB for the corresponding extension.

PIB is a named data structure organized in classes (Provisioning Classes - PRC) and can be conceptually described as a tree namespace as illustrated in following figure.

Figure 22: The PIB tree


44

The PRC defines the syntax and semantics of its attributes. Each PRC can have many instances called PRI (Provisioning Instance). RAP WG defines FRAMEWORK-PIB [17] with common classes which can be used by any policy areas of COPS-PR.

The first area and also the original area to use COPS-PR is COPS-PR for DiffServ. DiffServ WG defines DIFFSERV-PIB [18] with classes and attributes allowing building different traffic conditioning blocks in DiffServ router configuration. For example, the following class in DIFFSERV-PIB defines the scheduler using ASN.1 syntax:

qosSchedulerEntry OBJECT-TYPE

SYNTAX QosSchedulerEntry

STATUS current

DESCRIPTION

"An entry in the Scheduler Table describing a single instance of a scheduling algorithm."

PIB-INDEX { qosSchedulerPrid }

UNIQUENESS { qosSchedulerNext,

qosSchedulerMethod,

qosSchedulerMinRate,

qosSchedulerMaxRate }

::= { qosSchedulerTable 1 }

This class defines the scheduler using 5 attributes:

• qosSchedulerPrid is used to identify different instances of this classes.

• qosSchedulerMethod may points to the next traffic conditioning block of DiffServ router.

• qosSchedulerMethod indicates the Scheduling algorithm used by the scheduler such as Priority queuing, Weighted Round Robin or Weighted Fair Queuing.

• qosSchedulerMinRate and qosSchedulerMaxRate defines different parameters used by the scheduling mechanism.

3.8.3 Other COPS extensionsTo date, only COPS-RSVP and COPS-PR are standardized as RFC. Many other proposals have been proposed in QoS area, as well as in other area such as Security and AAA. However, these proposals are works in progress and published as individual or working group document. Among them, many COPS extensions can be cited:

• COPS-IP-TE for IP Traffic Engineering

• COPS-SLS for Service level negotiation


45

• COPS-UMTS for UMTS Go interface

• ……


46

4 TMF AND QOS PROVISIONING

As mentioned in section 2.2.2 the TM Forum has the following QoS related activities:

Telecom Operations Map document

SLA/QoS management team

Policy-based management team

TMF is more concerned with OSS and service management issue than with implementation or network architecture.

As such TMF work is useful to:

Understand the operator’s business process into which the QoS management must fit

Understand the customer relationship aspect of the QoS management

4.1 Enhanced Telecom Operations MapAs all documents from the TM Forum, the Enhanced Telecom Operation Map, hereafter called eTOM, is a document written by people from several companies: Telcordia Technologies, CASEwise, Nortel Networks, TTC, MetaDolv, Sonera Ltd., MSAF, Orange PCS, Motorola, Mannesmann Mobilfunk GMBH, SMART COM and Rational Management Group Inc.

The eTOM is a new version of a previous initiative called Telecom Operation Map (TOM).

The purpose of the eTOM is to continue to set a vision for the industry for competing successfully through the implementation of process driven approaches to operations management. This includes ensuring integration among all vital operations support systems concerned with service delivery and support. The focus of the Telecom Operations Map document is on the business processes used by service providers, the linkages between these processes, the identification of interfaces, and the use of Customer, Service, Network, and other information by multiple processes.

The eTOM describes the processes and their points of interconnection that make up the end-to-end process flows for Fulfillment, Assurance and Billing across the process layers of the TOM. It identifies the major processes and interfaces that make up an end-to-end process. Service providers need this common map of processes to enable doing business efficiently and effectively with other entities and to enable the development and use of third-party software without the need for major customisation.

The following QoS definition is given:

"Quality of Service is the measure of service quality defined for a service and provided to a customer. Quality of Service is the definition of the performance parameters used to assess service quality. The parameters are usually associated with a specific service or service type. Traditionally, the


47

term QoS is used to refer to performance related parameters. Some use QoS to mean the quality of service for all aspects of the service, e.g., network performance measures and Completion On Time, Call Pick-up Time, etc. QoS can be subjective, e.g., is a call easy to hear? for voice, or objective, e.g., Cell Error Ratio for ATM. Defining QoS is easiest with digital circuits. QoS for IP Services is getting a lot of attention, since it is a connectionless service that is hard to measure and since QoS for IP Services came from the IT arena, i.e., the “best effort” delivery model. In the TOM, QoS is used to mean all the measures of service quality."

Figure 23: enhanced Telecom Operations Map, Business Process Framework

Starting from the ITU-T TMN layering model, the TOM divided the Service Management layer into two parts: Customer Care and Service Development and Operations Processes (Figure 23). It particularly reflects the customer oriented view of the processes described in the TOM.

Figure 24 shows the split of the three layers into three parts to reflect the end-to-end process flow in the delivery of services: Fulfillment, Assurance and Billing.


48

eTOM Business Process FrameworkLevel 1 Operations View

Operations Fulfillment Assurance Billing

Operations Support & Readiness

Supplier/Partner Relationship Managx

Customer Relationship Management

Service Management & Operations

Resource Management & Operations

CRM OperationsSupport &ProcessManagement

SM&O Support &ProcessManagement

Retention & Loyalty

OrderHandling

Problem HandlingMarketingFulfillmentResponse

Selling

Customer QoS/SLAManagement

Billing &CollectionsManagement

Customer Interface Management

ServiceConfiguration& Activation Service Quality Analysis,

Action & Reporting

Service ProblemManagement Service &

SpecificInstance Rating

ResourceProvisioning &Allocation toService Instance

Resource ProblemManagement

Resource DataCollection,Analysis &Control

ResourceRestoration

RM&OReadiness

RM&O Support &ProcessManagement

Sales & ChannelManagement

S/PRMOperationsReadiness

S/PRM OperationsSupport & ProcessManagement

S/P PurchaseOrderManagement

S/P Interface Management

S/P Settlements& BillingManagement

S/P Problem Reporting &Management

S/P PerformanceManagement

S/PBuying

CRM OperationsReadiness

SM&OReadiness

Customer Customer

For this document we will focus on the fulfillment part.

Figure 24: Fulfillment - Assurance - Billing

[HERE, IT IS POSSIBLE TO DETAIL ALL THE FULFILLMENT BOXES, BUT WE ARE NOT SURE IT IS USEFUL]

The document also gives a list of examples to describe the information flow between boxes.

4.2 SLA/QoS Management TeamThe SLA and QoS Management team aims at producing a document addressing the SLA and QoS Management problem space: the second version of the SLA Management Handbook.

The following companies have participated to the elaboration of the SLA Management Handbook: Sodalia SpA, Nortel Networks, Verizon, GMD FOKUS, ACTERNA, Tivoli, Sonera, NASA, Lightsey Enterprises.

The scope of the Handbook is to provide a tool to be used by both the Customer and the SP in developing the SLA content and structure applicable to specific services. Assignment of specific values to any parameter is part of a specific contract negotiation and is beyond the scope of the Handbook. The term Customer refers to the business that consumes a service; the Customer may also be another SP. An end user is considered to be an individual within the Customer organization.

The Handbook focuses on SLA Management from the perspective of the Customer to SP interface including QoS issues. It does not prescribe QoS management from a network or service implementation perspective.

For defining QoS, the document uses the ITU-R recommendation E.800:


49

QoS is "the collective effect of service performances which determine the degree of satisfaction of the a user of a service. Note that the quality of service characterised by the combined aspects of service support performance, service operability performance, service integrity and other factors specific to each service".

This definition is clearly customer oriented and even customer perception of the quality of the service.

The document gives the requirements for SLA Management by explaining the potential benefits for service provides and customers. The requirements are listed for fulfillment, assurance and billing.

In order to illustrate the definition of QoS, the document lists and classifies parameters, first by determining the QoS perceived by the user: serveability, operability, integrity and support. Then the serveability is detailed with network performance parameters. But the distinction between QoS, a user oriented concept, and network performance, a provider oriented concept, is made along the document. The document also addresses the role of traffic engineering, the different classes of QoS, the dependency between parameters, the network specific parameters, the difference between performance measures and user perception.

Note that the previous comments are based on the SLA Management Handbook V1.5 from June 2001. According to the project charter, a draft version 2 is planned soon.

4.3 Policy-based Management TeamThis NGOSS group, lead by Cisco System, Inc. started during the TeleManagement World event in May 2001. This team is no more listed as an active team and is provided here for information purpose only.

Due to the fact that Policy-based management is a generic solution, the group (PBM) has many links with other TM Forum groups: eTOM, IP Network Management, TNA, TSA, SLA/QoS, and Security. The PBM WG also plans to participate to NGOSS Catalyst project.

All these collaborations with the existing groups will allow the definition of policy rules from high level to specific ones.

The work plan detailed in the Terms of Reference document V3.0 in April 2001, foresaw short term, mid term and long term actions:

Short term action was to build a coherent team in order to fully develop the Policy-based concept

Mid term activities are focusing on general and specific Policy Specification, combining all three aspects of Business Goals specification, High level Policies/Goals, and Translation from Business Goals to Policies. Mainly, the group will analyse various Policy-Based detailed mechanisms and tools, the focused target being constraints, conflicts and temporal parameters, as well as different methods to express such features (hierarchical policy framework, policy languages, policy actions and plans, policy rules,


50

policy constraints, simple, complex and combined policies, policy conflict detection and resolution mechanisms)

Long term phase consists of deployment guidelines, enhancement and application in various services of Policy-based mechanisms (editing, syntax checks, semantic checks, policy feedback). This phase will be synchronised with other TM Forum groups.

A first demo has been shown during the TeleManagement World event in May 2002: it concerned only billing policies which was the easiest to implement.


51

5 DMTF AND QOS PROVISIONING

The QoS provisioning activities at DMTF are part of the CIM model. First, we will introduce CIM concept and then we will focus on the CIM Network Model and the QoS Device Sub-Model in particular.

5.1 Common Information ModelThe Common Information Model (CIM) is a conceptual information model for describing management that is not bound to a particular implementation. This allows for the interchange of management information between management systems and applications.

There are two parts to CIM: The CIM Specification and the CIM Schema.

The CIM Specification describes the language, naming, Meta Schema and mapping techniques to other management models such as SNMP MIBs, and DMTF MIFs etc. The Meta Schema is a formal definition of the model. It defines the terms used to express the model and their usage and semantics. The elements of the Meta Schema are Classes, Properties, and Methods. The Meta Schema also supports Indications and Associations as types of Classes and References as types of Properties.

The CIM Schema provides the actual model descriptions. The CIM Schema supplies a set of classes with properties and associations that provide a well-understood conceptual framework within which it is possible to organize the available information about the managed environment.

The CIM Schema itself is structured into three distinct layers:

1- Core Schema - an information model that captures notions that are applicable to all areas of management. In a partial view of the Core Schema centered on the ManagedElement abstract class (Figure 25) we can distinguish the LogicalElement abstract class an the Service abstract class. These two abstract classes are of particular interest as they are starting points for the QoS Device Sub-Model inheritance hierarchy.


52

Figure 25: CIM Core Model (partial)

2- Common Schema - an information model that captures notions that are common to particular management areas but independent of a particular technology or implementation. The Core and Common models together are expressed as the CIM schema. The common areas are systems, applications, databases, networks, and devices. There are currently five Common Schema areas:

Systems: this model describes the various top-level system objects that make up the managed environment.

Devices: this model is a representation of the discrete logical units on the system that provide the basic capabilities of the system, such as storage, processing, communication and input/output functions.

Applications: this model is an information model designed to describe a set of details that is commonly required to manage software products and applications.

Networks: this model represents the various aspects of the network environment.

Physical: this model provides a representation of the actual physical environment.

3- Extension Schemas - represent technology-specific extensions of the Common schema. These schemas can be specific to environments, such as operating systems (for example, UNIX or Microsoft Windows).


53

5.2 CIM Networks ModelThe CIM Networks Model includes the topology of the network, the connectivity of the network, and the various protocols and services necessary to drive and provide access to network. Hereafter is a partial view of the Network Model centered on the ProtocolEndpoint class ().

Figure 26: CIM Common Networks Model (partial)

In this model the classes ProtocolEndPoint and ForwardingService are of particular interest, as they are starting points for the QoS Device Sub-Model inheritance hierarchy.

5.3 QoS Device Sub-Model

5.3.1 IntroductionThe purpose of the model is three-fold:


54

To describe the existence, configuration and operation of QoS-related services and sub-services.

To establish a common and device-independent understanding of these services to allow policy to operate on them.

To enable business rules to be associated QoS services, and to associate these services with a common set of device-independent QoS mechanisms.

Figure 27: QoS Device Sub-Model Inheritance

Basic "QoS Device" Sub-Model concepts were taken from two IETF Internet-Drafts, "A Conceptual Model for DiffServ Routers" and "Information Model for Describing Network Device QoS Mechanisms". The "QoS Device" Sub-Model currently is focused on modeling DiffServ capabilities of network devices. IntServ capabilities will be added in a future version of the Network model.

This model is about defining qualities of service (such as Olympic, Precedence, DiffServ and Priority Services) that exist at a network level, and associated device services (such as Traffic Conditioning Services, Schedulers and Filters) that are part of providing the quality of service.


55

5.3.2 QoS Device Sub-Model Overview

5.3.2.1 QoSService, its Subclasses and Associations

Figure 28: QoSService class and its associations

The QoSService class is a concrete class that enables a QoSService to be represented as a set of coordinated sub-services (through the use of the QoSSubService aggregation). This enables a high-level service to be abstracted into a set of lower-level services. It also serves as a way to consolidate relationships between different types of QoSServices and the set of ConditioningServices that arte used in building a particular instance of QoSService (through the QoSConditioningSubService aggregation).

QoSService represents a specific type of forwarding of network traffic using a particular model. Three such models are supported: Precedence, DiffServ and 802.1P Services. Consequently three subclasses are defined as some technologies are only available on certain types of devices:

PrecedenceService class is used when network traffic is to be forwarded based on the value of the "Type of Service" (TOS) byte of a packet. It defines a single property, PrecedenceValue, which is a 8-bit unsigned integer which carries the value of the TOS marking.

DiffServService class is used when network traffic is to be forwarded based on the value of the DS byte of a packet. It defines a single property, DSCP, which is a 8-bit unsigned integer which carries the value of the Differentiated Services Code Point.


56

8021Pservice class is used when network traffic is to be forwarded based on the value of the 802.1P priority field. It defines a single property, PriorityValue, which is a 8-bit unsigned integer which carries the notion of priority as specified in 802.1P implementations.

QoSService conceptually represents how different types of services that use QoS (e.g. DiffServ, Precedence and 802.1P) are implemented using a common set of QoS mechanisms.

5.3.2.2 ConditioningService, its Subclasses and Associations

Figure 29: ConditioningService class and its associations

The class ConditioningService and its subclasses describe how traffic is handled (i.e. "conditioned") in the data forwarding path of a network device, to maintain specific qualities of service for the various types of network traffic. Subclasses address each of the following types of ConditioningService (while further subclassing defines the individual parameters of the algorithms used):

Classifying of packets based on predefined filters.


57

Figure 30: Filter classes and associations

Metering of packets to determine the level of conformance of each packet with respect to pre-established traffic profiles.

Marking of packets to identify traffic that should get a particular QoS according to a particular discipline.

Dropping of packets to avoid or manage congestion.

Queuing of packets for later removal by a Scheduler, that determines which traffic to transmit in which order. QueuingServices require some kind of backing store in which to store packets for subsequent forwarding or dropping. Also, queues need to be emptied. These concepts are described via classes associated with QueuingService - BufferPool and PacketSchedulingService. The associations tying the classes together are QueueAllocation and SchedulerUsed respectively.

Different devices have different sets of conditioning mechanisms. This model abstracts these services into into a common set of modular building blocks that can be used, regardless of device implementation, to model the forwarding decisions internal to the device. The Sub-Model does not dictate ordering, or a first or last ConditionService. Instead, it ties together the various ConditioningServices using the NextService association. And it allows ingress/egress to be described via the association ConditioningServiceOnEndpoint.


58


59

6 PROPOSITION OF QOS MANAGEMENT FRAMEWORK

6.1 Generic QoS FrameworkThe architecture described hereafter is the ADANETS QoS framework. It is independent of any kind of network technology, whether it is ATM, IP, radio or optical network, running any kinds of technologies or protocols. This architecture addresses both the access and core networks. This architecture concentrates on the network management functionalities that are required to provide QoS. This ADANETS QoS framework aims at defining network management functional blocks, and the relations between them, to ensure that a service required QoS will actually be provided.

To perform QoS is to provide a service (video, voice…) in good conditions. The parameters to appreciate QoS (delay, jitter…) are negotiated in a SLS. Those parameters are measurable, and provide a way to compare the negotiated service with the actually provided service. Those parameters can also be used to define a particular treatment to apply to the service flows.

Generally speaking, to provide QoS is done by avoiding network congestion. Additionally some resources can be reserved or priority allocated. The network must be configured to support those differentiated behaviors. The services can then be mapped to pre-configured network behaviors with regards to the awaited QoS performances. The QoS provisioning is thus performed in three steps, that are described in more details in the next sections:

Avoiding network congestion is the goal of Traffic Engineering.

Reserving or prioritizing resources for a service is done by affecting a service to a pre-defined network class of service.

Defining and configuring on the network the classes of service is the goal of the initial network provisioning.

The ADANETS QoS framework (Figure 31) is divided in the three legacy management layers.


60

Figure 31: Generic ADANETS QoS Framework

The Service Management Layer (SML) manages the SLS negotiation, the service reporting and billing, the network load forecast and the SLS storage. Those functionalities don’t contribute to actually provide the awaited service QoS on the network. However some data that are stored or computed at this level are used by the ADANETS QoS framework. The corresponding functional blocks are described above:

Service Management: SLS negotiation, service reporting and billing to users. This block is out of the scope of the ADANETS QoS framework.

SLS Database: storage place for the SLS describing the services. Those SLS are used by the NML to adapt a service provisioning to the QoS requirements.

Traffic Forecast: this block aims at planning the network load and usage thanks to negotiated SLS and business analysis. It is long term planning that will be used by the NML to configure the principal network tunnels and the classes of service.

The Network Management Layer (NML) manages the initial provisioning of the network, the service to network mapping, the network optimization, and it also performs QoS problem detection. Those functionalities are performed by the functional blocks described bellow:

Network Configuration Management: makes use of the SML SLS and Traffic Planning to define the appropriate network configuration. Performs service to network mapping, that is translates the network configuration needs into network configuration commands.


61

Network Inventory Topology/State: maintains network topology and usage information that are used in support of other NML functions computations.

Traffic Engineering: detects QoS problems thanks to alarms and measurements coming from EML and network usage forecast from SML. Performs network optimization, including bandwidth management, in support of the Network Configuration Management computations.

The Equipment Management Layer (EML) manages the adaptation of NML configuration requests to NE commands, report alarms to NML and perform measurements for NML. The corresponding functional blocks are described bellow:

Element Manager: adapts NML configuration requests to NE commands.

Data Collector: collects measurements and alarms from the NEs, correlates alarms and performs traffic measurements analysis. Reports those collected data to NML or SML.

In the following subsections, we describe the QoS Framework in terms of three distinct use cases, or scenarios.

6.1.1 Network Provisioning Scenario


62

The network provisioning step aims at pre-configuring routers and tunnels on the network. It is a long term configuration maintained on a per month basis. It enables to provision services on the network on a scalable way, by mapping the service provisioning on already existing tunnels and classes of service. No heavy network configuration is needed.

6.1.2 Service Provisioning Scenario

The service provisioning step aims at provisioning a service on the network with regard to the user required QoS, that was defined on a SLS. This is done punctually by affecting the service transport to pre-defined tunnels, and sometimes by mapping the service to a pre-defined class of service to obtain resources priority. It is possible that some minor network configurations are performed, keeping in mind to not disturb the network processes. Once a service is provisioned, its flows are aggregated on the network with other services flows. The network computations for Traffic Engineering does not distinguish them any more.

6.1.3 Traffic Engineering Scenario


63

The Traffic Engineering loop is a permanent network management process that aims at ensuring that no network congestion will occur (preventive) or that manages faults (reactive). This is done by getting measurements or other data from the network and analyzing them to raise QoS current or future problems. Then the network can be partially re-configured to deal with those problems. At this level, for scalability reasons, the network traffic is considered as a whole and not on a per service basis. The classes of service can be considered, but this will probably make the process too complex.

6.2 QoS Framework Instantiation

6.2.1 IntroductionThe service management for operators consists of creating, operating, and maintaining the services they offer to end users. Service provisioning is a critical part of this activity: the operator needs to supply the service according to what have been negotiated for in the SLA. In order to reach this objective, the configuration of the devices of the network is performed based on what is stated in the SLA.

An SLA (Service Level Agreement) is a business-oriented documentation as a result of the negotiation between customer and provider specifying


64

business conditions and service performance parameters [26]. An SLS is the technical part of the SLA and is intended as an operational guide to the implementation of the service. It includes the individual metrics and operational data needed to achieve the agreed upon quality measures for network traffic.

Further SLA/SLS definitions and details, management processes and SLS assurance part is presented in ADANETS deliverable D2.2 [27]. Dynamic SLS negotiation (protocol-based) is defined in the deliverable D2.3 [28].

Therefore the main driving part of service provisioning process is SLSs that result from service level negotiation. These SLSs describing services are stored in the SLS database. However, there is a big gap between high-level service definition stated in the SLS and the possibility of its implementation in network element level [26]. As a result, Policy Based Management architecture can be viewed as a mean to bridge this gap making the translation from SLSs parameters into network element configuration feasible. In the context of a BGP/MPLS core network, this means configuring the edge devices to map services into existing tunnels pre-provisioned during the network provisioning scenario.

6.2.2 Threefold generic scenariosAs described in the previous sections, QoS Framework may be seen by three different use cases (scenarios). The first one, Network Provisioning covers LSP (traffic flow) configuration based on service planning, i.e. the standard CoS (Classes of Service) are set and the core (backbone) network is “activated” to carry traffic. In the second scenario, Assurance/Traffic Engineering, monitoring and automated network reconfiguration are performed. These processes are described in detail in [27]. Finally, in the Service Provisioning scenario, a focus is made on mapping of particular service on already provisioned resources (CoS) and on configuring (if needed) additional resources, usually at the edge of the network. This scenario is described in detail in the following sections.

6.2.3 QoS Framework Instantiation by PBM for Service ProvisioningInstantiating the QOS framework using the Policy based Management building blocks and taking into consideration a core network deploying the BGP/MPLS technology will result in the following architecture:


65

Figure 32: Service Provisioning Instantiation

The main idea behind these different building blocks is that the SLS is the goal to be put into effect within the network in the most automated and flexible way. Policy Based Management (PBM) spotlights a particular way of service provisioning. The basic idea of Policy Based Management is to be able to model the functional behavior of the core network by means of high-level business rules or policy rules that describe which resources are made available in the network for particular applications and users in a particular time-period. These high-level policies are then broken down into elementary policy rules that define the behavior of the individual network elements (IP routers, cross-connects, etc.) that are involved in providing the service and are needed to enforce these policies.

In other words, policy is the facilitator and is derived from the SLS part; this derivation is performed by the Policy Manager functional block presented in the Figure 1. After this translation process, the policy is stored in a policy repository and then pushed down into network elements by the Policy Server. However, in order to reach the goal defined in high-level SLS, more refinement will be needed into a format that can be understood by the Network Element (NE), this refinement is possible due to the use of a proxy part of the policy enforcement point (PEP).

The following subsections will provide an exhaustive description of the functional blocks presented in the instantiation figure, these blocks include:

The policy manager (the policy management tool).

The policy repository.

The policy server (the Policy Decision Point).

The Policy Enforcement point.


66

6.2.3.1 Policy ManagerThe Policy Manager has as input the negotiated SLS; based on this input, it translates the SLS into policy rules and then performs several validation tests (as resource request validation). The resulting policy rules should comply with “policy templates”, this concept will be illustrated later in more details. The relation between these policy rules and different devices that will execute them is created by assigning different roles to the obtained policy rules. The concept of “role” is explained in more detail later in this paragraph.

The policy manager needs to perform the following functions:

Validate that the service requirements parameters being entered in the SLS can be satisfied given the network’s resource and constraints. In fact, there might be several physical limitations that can prohibit the acceptance of an SLS and as a result the translation process. For example an SLS specifying a Bandwidth not available in the network should not be translated into device configuration. In order for such kind of validation to be made, an interaction between the policy manager and a Bandwidth manager is needed. It is clear that the validation process requires interaction between the policy manager and other types of managers like a bandwidth manager as illustrated in the previous example, and a connectivity manager. Interaction with the connectivity manager is needed for example to validate that an LSP connecting the source and destination specified in the SLS already exists. The connectivity manager has an access to the inventory topology database and therefore such validation is possible.

Translate the SLS into policy rules using policy templates. A policy template is defined as a general high-level information structure that describes certain kinds of information required for the SLS translation process [26]. The main idea is that the policy manager does not generate templates, it generates policies but the structure of these policies should comply with the policy templates. For example if an SLS states that between source A and destination B the Bandwidth should be 5 Mb/s, using a policy template of the form: “If Source =? And Destination =? Then Bandwidth =?” will result in a policy rule sating: “If Source = A And Destination = B Then Bandwidth = 5 Mb/s. This example is used for illustration purposes only and a real case would be different from what was presented. Those templates are related to the policy information model definition (for BGP/MPLS networks, QPIM, transport info models, …); the reason is that the policy information model provides the guidelines to build the Condition part as well as the action part of these templates. As was presented in this deliverable, the QPIM (QOS Policy Information Model) defined at the policy working group of the IETF provides classes used to build policies related to IntServ and DiffServ environments, similarly The BGP/MPLS information model defines classes to be used in constructing policy rules related to BGP/MPLS networks.


67

Store the policies in the policy repository either by a direct access to the repository or through the policy server. In the later case, the policy manager communicates the policy rules to the policy server that stores them in the repository.

6.2.3.2 Policy RepositoryThe policies are stored in the Policy Repository and retrieved by the Policy Server (and the Policy manager). Several types of repositories can be used ranging from an LDAP directory to a relational database. However, regardless of the type of repository selected, the policy stored in the repository needs to conform to specific conventions [29]. These conventions are specified as the information model for policy specification, in this case it is the BGP/MPLS policy information model. When developing systems, this information model must be mapped to a real system. If the data repository is a relational database, it will be mapped into descriptions of specific types of records in the database, specifying the fields in each record, and so on. For LDAP-based directories, the information model must be expressed in terms of directory schema, which enumerates the types of objects and fields that can be stored in the directory.

6.2.3.3 Policy ServerThe Policy Server needs to perform the following functions:

Retrieve policies from the policy repository.

Detect conflicts that can exist between policies. Two policies conflict with each other when all their conditions are satisfied, but the actions defined within these policy rules can not be executed simultaneously. The actions of two policies present a conflict when they cause different operations to be applied to the same resource. For example if policy A specifies that traffic should be forwarded for a particular source IP address, but Policy B specifies that traffic should be denied for that same source IP address. These policies will conflict with each other if their conditions are all satisfied [30]. As another example Policy A could state that “all engineering managers are provided Gold Service” and Policy B states “Anyone that is running FTP is provided with Bronze service”.

Resolve Policy Conflict. As soon as conflict has been detected, it must be resolved. A common way to resolve the conflict is by prioritizing policies. By doing so, the policy rule with the highest priority level is executed first.

Configure the PEPs (MPLS routers). COPS-PR is used to configure the edge routers using Framework and Adanets BGP/MPLS PIB modules.

Translate rules into device commands, distribute rules, compute policy decisions.


68

6.2.3.4 Policy Enforcement Point and ProxyThe PEP is responsible for executing policies obtained from the Policy Server. In order to do so, the PEP must translate the information communicated by the PDP into a format that can be understood by the NE. The PEP consists of a Proxy and the NE (Figure 1).

In fact, a proxy is inserted between the PDP and the NE in cases where the NE does not speak the same protocol that the PDP speaks [30]. In ADANETS, the policy is provisioned into network devices using COPS-PR and Adanets BGP/MPLS PIB.

However, currently there are almost no policy-aware Nes on the market. For this reason a proxy is used to translate the policy rules into MIBs or CLI commands or other formats, depending on the implementation. After this translation process, it will be possible to configure different interfaces of the NE to meet the policy rule objective.


69

7 REFERENCES

Nota: IETF RFCs and Internet Drafts may be retrieved from http://www.ietf.org/.

[1] “MPLS Architecture”, RFC 3031.

[2] “Integrated Services in the Internet Architecture: an Overview”, RFC 1633.

[3] “Specification of Guaranteed Quality of Service”, RFC 2212.

[4] “Specification of the Controlled-Load Network Element Service”, RFC 2211.

[5] “Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification”, RFC 2205.

[6] “Aggregating RSVP-based QoS Requests” – Internet Draft.

[7] RFC 2753.

[8] RFC 2748.

[9] RFC 2749.

[10] “LDP specification”, RFC 3036.

[11] “Constraint-based LSP Setup using LDP”, RFC 3212.

[12] “MPLS Label Stack Encoding”, RFC 3032.

[13] “A framework for QoS-based routing in the Internet”, RFC 2386.

[14] RFC 2676.

[15] RFC 3272.

[16] RFC 3084.

[17] “Framework Policy Information Base”, Internet Draft.

[18] “Differentiated Services Quality of Service Policy Information Base”, Internet Draft.

[19] RFC 3060.

[20] “Policy Core Information Model extentions”, Internet Draft.

[21] Y. Snir, Y. Ramberg, J. Strassner, R . Cohen, “Policy QOS Information Model”, Internet Draft.

[22] "Requirements for QoS signaling Protocols", Internet Draft.

[23] Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086.

[24] Mobile IP: “IP Mobility Support for IPv4” - RFC 3220, “Mobility Support in IPv6” – Internet Draft.

[25] “Requirements of a QoS Solution for Mobile IP” – Internet Draft.

[26] T.H.Jonatan, “SLA Enforced By Policy”, Thesis, June 2001Project: ITEA ADANETS

70

http://www.ietf.org/

[27] ITEA ADANETS project deliverable D2.2 “Assurance of SLS & QoS commitments”, December 2002.

[28] ITEA ADANETS project deliverable D2.3 “QoS negotiation over multiple network domain”, December 2002.

[29] Dinesh C. Verma, “Policy Based Networking Architecture and Algorithms”, New Riders, Nov 2000.

[30] Strassner, John. Directory Enabled Networks. Indianapolis: Macmillan Technical Publishing, 1999.


71

adanets deliverable d2.1 - laboratoire · web viewadanets analysis of standards on qos...

Documents