Policy-based Network Management for Enriched-Experience Networks N. B. Sheridan-Smith, J. Soliman, D. Colquitt, J. R. Leaney, T. O’Neill, M. Hunter {nigelss, jacquiw, dcolquit, jrleaney, toneill}@eng.uts.edu.au Institute for Information and Communication Technologies University of Technology, Sydney Abstract- Service Providers must increasingly differentiate their services as competition increases commodification and progressively consumes their profit margins. However, NextGeneration Networks are not yet a safe-haven as value-added services are still too complex and expensive to build and manage. To increase service diversity and profitability it is necessary to strike a balance between maximising the satisfaction of the users and the expected costs. But how does one know what services will provide the most Return on Investment? Quality of Experience may offer guidance through the deeper understanding of emotive user behaviour such as the user’s purpose and needs. Thus, it may be possible to determine which future services are valuable and important to users and build an Enriched-Experience Network that fulfills such needs. However, without automated, adaptive and evolvable management systems that support diversification and evolving network architectures, it will be difficult to manage the escalating network puzzle. Policy-based Network Management has the potential to solve many of these problems but it currently has many limitations. These systems must have a service-oriented focus and an architecture that has emergent qualities that can match or exceed existing carrier-class systems to ensure that they scale to support millions of users. We use Architecture-based Engineering approaches to understand and measure these qualities, and apply architecture principles to the design of the next generation of management systems.
I. INTRODUCTION Service Providers, faced with increasing competition, find it hard to differentiate themselves from competitors, turning many telecommunication services into commodities and driving down profit margins [1]. Furthermore, the cost of building and operating value-added services is too high, in part due to management costs. Whilst IP-based Next-Generation Networks (NGNs) have promised to reduce costs and increase convergence of services, it is often found that value-added services are too difficult to operate profitably since they have additional complexity which raises operational expenses. The diversity of services offered by Service Providers is severely limited as costs become prohibitive. Furthermore, service components are often supported by diverse management and Operational Support Systems (OSS) that are not tightly integrated together [2]. This means that management is often piece-meal and intensely human-driven. Consequently, management systems and processes are unable to support the management of millions of users and services simultaneously (in the order of 107). As it becomes more critical for Service Providers to manage the entire service from the application server to the user’s appliances and networks [3], the scale of the problem snowballs. It is contended that higher levels of automation may help in reduce operator involvement and operational costs. Management systems also need to be more adaptable – in allowing new valueadded services to be operated with minimal effort, in increasing Service Provider agility to react to market conditions, and in responding to individual user needs to facilitate diversification. Newer management techniques allow services to be provided in an
[email protected] Alcatel Australia
‘on-demand’ fashion, with networks reconfigured in accordance with individual user requirements and resource availability. Our UTS-Alcatel research group seeks to understand and manage large-scale complex networks, where large scale means millions of entities and users. Firstly, we are investigating the efficacy of Policy-Based Network Management (PBNM) to reduce the complexity of the management task, augmented by advanced simulation to predict effects. Secondly, we are exploring the needs, wants and expectations of users to better understand and accommodate them, under the banner of Quality of Experience (QoE). Thirdly, we are modelling, developing and visualising the evolving system using the approach of Architecture-based Engineering to ensure the realisation of a system design which will achieve its functional and non-functional qualities. Following this section, this paper is organised into three parts. Section II discusses management system problems in controlling more complex, value-added services. This is followed by a discussion of the concept of Quality of Experience and its importance in selecting services which are valuable to users, leading to our definition of an Enriched-Experience Network based on these principles. We then discuss necessary management system improvements, and the way that Architecture-based Engineering can help in meeting the non-functional requirements. In section III, we discuss the concept of policy-based management, how it might be helpful in solving problems, and identify improvements that need to be made. Finally, in section IV we discuss some of the areas of our current work in this space. II. A WAY FORWARD FOR SERVICE PROVIDERS Many Service Providers face a number of challenges which are business-oriented, technical and managerial in nature. Firstly, Service Providers are finding it more difficult to offer profitable services due to increasing competition [1]. Secondly, whilst it is desirable to build NGNs to consolidate services into one network and reduce costs, many Service Providers are reluctant to migrate all of their services entirely to these networks because of the higher complexity involved in supporting real-time services. Finally, there are a number of managerial issues which are discussed below. A. Existing management problems Without suitable management systems, building newer, valueadded services that allow differentiation will be difficult, if not prohibitively expensive. For each new service that is added it is often necessary to reconfigure many devices spread across the network. This significantly limits the agility of the Service Providers to react to different market conditions which could arise at any time. Furthermore, it is difficult to give real-time performance assurances to users, as Quality of Service (QoS) mechanisms are often not completely managed from end-to-end with integrated admission control and resource management. We consider the following to be significant problems with the existing management systems:
1) Disparity – many management components act independently and are unique for each vendor, product or management process (i.e. ‘stovepipe’ systems) [2]. Without tight integration, each task must often be carried out by human operators one-by-one by ‘swivelchair management’ increasing complexity and making end-to-end consistent management without configuration errors difficult. 2) Focus on device management – there is too much focus on managing individual devices [4] rather than the logical service aspects. This burdens operators with ensuring service fulfilment. 3) Increased management complexity and burden – increasing service complexity leads to increasing management burden through more devices and functions to support. Add in the management of customer networks (including IADs and appliances) and the total number of devices, users and services is in the order of millions. 4) High operational costs and lack of autonomy – with 45% of operational costs due to configuration management [5], automation will contribute immensely to reducing costs. Repetitive processes can be done with minimal human intervention. 5) Poor Service-Level Management – there is no strict definition of a Service Level Agreement (SLA), and few management systems allow service performance measurement to ensure conformance. 6) Limited interactions between Service Providers – Service Providers will increasingly need to partner with third parties to strengthen their service capabilities and source content. Currently there are no standards for peering between management systems. 7) Reaction to network failures – Many management systems only facilitate fault identification and rely on operator resolution. To ensure high quality for SLAs, it is desirable that management systems could solve most faults without operator intervention. 8) Minimal resource management – most NGNs have limited resource management to ensure adequate service quality levels. Further work needs to be done to integrate improved resource management and admission control mechanisms into the network. These problems limit the selection of services that can be offered by Service Providers on a large scale. IP connectivity and VPNs are common amongst most Service Providers, but these services only have marginal value to the user. Other services such as VoIP and video streaming are typically only offered to specific market segments such as large enterprises, except in some countries where market and environmental conditions are substantially different. To understand what services will be of most value to the user, it is necessary to examine and understand how these services are used to assist in meeting each individual’s needs and purpose in communicating and collaborating with others, and this will be discussed below. B. Understanding the user: Quality of Experience What has become increasingly clear (especially with the slow uptake of 3G and broadband technologies in many countries) is that customers and users are not driven by the availability of technology on its own. Rather, technologies need to provide for specific and individual end-user needs at price-points that align with the customer’s perception of the value to them. Furthermore, Service Providers wish to ascertain which services will drive revenues with maximum Return on Investment (ROI). Thus, it is essential for Service Providers to understand which services are the most desirable and valuable to the users, and the suitable prices to make them affordable, attractive and profitable.
However, previous attempts to understand which services might be most desirable and valuable to the users have been limited in their effectiveness [6]. The advent of the NGN and value-added services has necessarily introduced an increased awareness of the user perspective. Unfortunately, there is little consensus on what QoS is [7], and existing definitions proclaim QoS to simultaneously be ‘a state, a cause, an effect, a measurement, and a subjective experience’ [8]. The extant literature provides a variety of understandings of the user-network relationship, with the view that if performance quality is high, then the user is satisfied. Inherent in this view is a blurred distinction between the user and the application [9]. The literature discusses the term Quality of Experience (QoE) [10, 11], but provides no clear or precise definition. It has been argued that these attempts have failed because of a tendency to ‘feature the technical capabilities of the infrastructure…a Field of Dreams approach – build it and they will come’ [6]. This myopic tendency neglects to address the full problem. It fails to separate the user from the application, and consequently, allows for the user experience to be quantified in terms of how big and well-formed the bit-pipe is. Accordingly, a QoE perspective needs to go beyond the application to first consider the experiences of the user, and then design the applications to reflect this experience. We understand QoE to be service quality as understood from the user’s viewpoint. Their experience may be partially influenced by QoS parameters, but the defining factor is expected to be the purpose for which they engage with the technology. The usage of communications technology cannot be separated from the user’s lifestyle and preferences; the user needs to live with technology, not just use it [12]. Living with, as opposed to just using, is what is currently defining of QoE. Furthermore, living with technology ‘introduces a diversity of subjective, emotional, pleasure and identity based criteria’ [12]. To make sense of QoE, these criteria must be taken into consideration. Currently, there is no consistent and adequate understanding of QoE that considers these criteria. Further work needs to be done to come to attain this understanding of QoE, which is being done as part of the Management of Enriched-Experience Networks (MEEN) project at UTS. An overview of this work is necessary however, to explain what we have coined EnrichedExperience Networks (EENs) [13], and how we consider them to be fundamentally different from Next-Generation Networks (NGNs). An EEN is basically a recognition that QoE resides with the people, not with the network. The network can only influence and shape QoE, not create it. At this stage we consider that there are several factors that might significantly contribute to QoE. Firstly, accessibility, usability and simplicity must be improved so that users can access any service (anything), from anywhere, at any time and from any appliance (anyhow) [14]. Secondly, the services need to converge and be closely integrated to make user tasks easier. Finally, services should be personalized to increase user choice between different features and pricing levels to match their desired price-point and their individual needs. Indeed, many Service Providers are already thinking about the user experience, personalisation and convenience [3, 15]. Some of the key questions left to answer are: What services are valuable to the users? What price are they willing to pay? Can the services be offered to them profitably? Can the services be adapted to become more valuable, profitable or vertically and horizontally diversified? What will make the user experience better, with consideration for costs?
Whilst the understanding of QoE may assist in creating the requisite service differentiation to attract users to purchase and use services, there are still many technical issues associated with implementing these services in a manner that positively shapes the QoE. In particular, there are significant managerial challenges, which will be discussed in the following section. C. Improvements to management systems Once a better understanding of QoE is attained, how then might one go about the management of diversified services for 107 users with minimal human resources and low operational costs? It is anticipated that EENs will require regular and instantaneous interactions between network components and users to deliver ‘ondemand’ services that can meet ever-changing user needs. We believe that a number of key aspects of management systems need to evolve in order to support EENs: 1) Automated, adaptive, and on-demand – automated and integrated management systems will allow the configuration of endto-end services quickly on-demand and with consideration of the user’s individual preferences and situation. Complex decisions that manipulate components involved in services must be made quickly and with minimal operator involvement. 2) Service management – Rather than controlling individual devices, it is desirable for the management systems and operators to clearly understand the relationships between the services that are offered at each layer, and their impact on individual users. This also facilitates automated decision-making at multiple layers that reflect user needs better. For example, if a user migrates between access networks, edge device configurations can be modified. 3) Integrate the management of broader service components – the management scope must be broadened to all components participating in services - from application servers to appliances across multiple domains. Value-added features may be added over time, by introducing additional functional components as required. 4) Consistent behaviour – the behaviour of distributed service aspects must be co-ordinated, governed by unambiguous networkwide goals, especially when services re-route during disruptions. {Customer “Acme” has users “Joe”, “Carl” and “Tim”; Acme has access to all stations [1-15, 20]}
{“Carl” does not have sound on his PDA}
Customer Knowledge
Customer Preferences
{DSLAM dsl57 supports multicast}
Network Knowledge
Service Knowledge
{Service “TV” requires DSLAM to be configured for multicast; 100 MBps reserved from broadcast server to each DSLAM} {“Joe” is logged in to MAC address 00:00:e0:f8:27:31, DSLAM dsl57 interface 7 and IP address 192.168.52.5}
Decision-making and management functions
Customer/service interactions; Network events
{“Joe” from “Acme” requests login from MAC address 00:00:e0:f8:27:31; “Carl” changed TV channel from “5" to “9"}
State information
Configuration and monitoring
{dsl57.Multicast = enabled; if any queue > 80% full then notify management}
Managed devices
Fig. 1. The automated decision-making function
5) Information Systems integration – users must be associated with the consumed services and the devices/resources that are utilised. Knowledge from a number of sources can be utilised to adapt each user’s experience to their specific needs or preferences (see Figure 1). These sources might be customer knowledge (who has access to which services; where are users located; what are they allowed to do), network knowledge (available resources, topology and capabilities), service knowledge (what services are offered and how are the services related to the available network elements), customer preferences (how do I want this service tailored to me?), and dynamic customer and service interactions (a user logs in, changes devices, moves location, etc). Furthermore, the management system will need to remember some user and service specific state (i.e. the current MAC/IP address, resource usage, etc). This knowledge might be obtained from external repositories such as credential, authorisation, location and identity frameworks. This knowledge can be applied at all management layers, to ensure consistent and rapid responses to different situations that arise. With these improvements, management systems will respond quickly and intelligently to the needs of its users. Automation will help Service Providers to adapt better to needs on varied time-scales. D. Non-functional qualities of management systems The above sections indicate what we believe is a necessary and a fairly significant increase in management system complexity because management systems will need take a more active role in the real-time day-to-day operation of services in an EEN. Decisions are made quickly to facilitate the provisioning, adaptation and monitoring of each individual service. Since many of these services will be short-lived, users will not find extraneous delays acceptable. In addition, if the management systems are unreliable, then service availability will be affected. The scalability of the management systems to support the increasing load must be carefully addressed, so that it may support in the order of 107 users, services and devices. For these reasons, the management systems that are designed or purchased must be able to meet these qualities to a satisfactory standard. However, it is not possible to achieve all of these qualities simultaneously to the highest possible levels because different qualities must often be balanced against one another. We seek to understand the trade-offs that exist between these qualities which are present within the architecture of the management systems. We are using an Architecture-based Engineering approach [16] in the design and evaluation of the management systems and networks. By using abstract models of different views of the system, we can evaluate the most significant non-functional qualities before the system is completely designed or implemented. The use of these techniques is invaluable because system architects can trade-off different architectures and designs at an early stage and understand the implications of design decisions. This minimizes the cost of building the system to meet all of its functional and non-functional specifications. We have conducted work to examine published management systems architectures and to understand the drivers in management system design. Using the Architecture Trade-off Analysis Method (ATAM) developed by the Software Engineering Institute (SEI), the most important qualities were elicited and ranked. The key quality attributes were found to be growth (scalability, evolvability, adaptability), available (availability, reliability, robustness, stable), open (openness, interoperability, portability), timely performing (performance, throughput), maintainable (maintainability, autonomy, self-healing) and secure (security, isolation) [17] and these are shown in Figure 2.
III. POLICY FOR MANAGEMENT OF ENRICHED-EXPERIENCE NETWORKS One fundamental aspect of the MEEN project that is also the focus of this paper is Policy-based Network Management (PBNM). Policy is considered to be an approach that may allow automated, adaptive and reactive ‘on demand’ management, and may help to reduce the complexity of management tasks. For this reason, it is been investigated thoroughly and is discussed in detail in the following sections. Miscellaneous Secure
6%
7%
Growth 27%
Maintainable 9%
Timely Performance 13%
Available 20% Open 18%
Fig. 2. Elicited qualities from ATAM process
A. What is policy? Policy-based Management is the application of the concepts of organizational policy to the governance of computer-based systems. Thus, computer-based policies are a method of declaring and formalizing the behaviour of the system [18] by guiding, constraining and enforcing the behaviour of the entities which are being controlled. In particular, Policy-based Network Management (PBNM) refers to the use of policy in facilitating network management activities. Sloman [19] defined two categories of policies –authorisation policies (e.g. security - who is allowed to perform tasks) and obligation policies (e.g. management duties – who should perform tasks). When policy is used in autonomous systems, the obligation policies determine the responsibilities of management agents and motivate them to perform actions which will achieve goals. The major advantage of using this approach in automating systems and processes is that the policies are separated from the coding of the management agents, making the agents effectively programmable [19]. If the behaviour of the system needs to be changed, then the operator or administrator can simply modify the policies and let the system continue running, without modifying the code of the management agent itself.
B. Behavioural abstraction and translation Policies can vary in their level of abstraction [21]. They can be abstract by specifying a goal, objective or constraint (i.e. ‘what’ needs to be done, not ‘how’). These abstract policies can be difficult to achieve by an automated system, because it is not obvious how to go about achieving a goal. Typically, some other knowledge combined with intelligence is required to act on them. Alternatively, policies can be concrete by specifying a process or procedure to follow. Usually, these policies are easier to achieve, because they are specific and detailed. Policies are also considered to be hierarchical in nature, with high-level abstract policies or goals translated into progressively smaller objectives, and eventually procedural steps which are concrete. The level of abstraction chosen is reflected in the representational (or policy) models that are used to represent the environment and systems under control. However, important decisions are made when these representational models are formulated. Firstly, some behavioural properties of the system are accessible or ‘declared’ and are able to be adapted, whilst others are not (‘hidden’ or ‘fixed’ policies). Secondly, the level of abstraction determines whether translation is required since most systems are not able to interpret highly-abstract policies directly. These choices are crucial to the performance and scalability of the policy system, since increasing the levels of adaptability is likely to lessen management system performance. Thus, care must be taken to ensure that representational models are designed appropriately. As the abstraction of the representational models increases up the hierarchy, so does the power of the specification. Thus, the choice of abstraction of the models used is crucial, because it determines the manner in which the policies can be specified. This is explained further in Table 1 where the relative advantages and disadvantages of each approach are compared. TABLE 1 COMPARISON OF ABSTRACT AND CONCRETE POLICIES
More abstract policies
More concrete policies
Advantages
Disadvantages
− Can apply to more entities, or the whole system − Easier to read and comprehend; fewer − Easier to write − Can be applied to more general (or aggregated) properties of the system − Can be specific about what needs to be done − Can apply to a subset of the entities within the system
− Cannot be specific about how the goal should be achieved − Difficult to check for consistency
− Difficult to read − Complex to write − Cannot be applied easily to heterogeneous entities − Less meaningful across administrative boundaries
C. Translation from service models to device models
Fig. 3. Early Policy-Based system by Sloman. Source: [20]
In EEN management, it is advantageous to describe the associations between the users and the services that they have purchased and that are in use through service models. Service descriptions could also be used to describe what the services are and provide information about how those services might be managed in a real network. By taking this approach, it is a simple matter to change who has access to the services, what services are available, and how those services may be controlled and monitored to satisfy each user’s requirements. For example, two requirements might be:
John has access to the high quality Video on Demand service The high quality Video on Demand service must have higher priority than other best-effort traffic on the network
These requirements might be captured in service models and service descriptions, which help to formalise this information in a form that could be readily understood by the management system: Service model: John.Services = [HighQualVoD] Service description: HighQualVoD.priority > BestEffort.priority
The management system can then use this declarative knowledge, as well as other information (such as device capabilities, service descriptions, resource/network availability, customer preferences and environmental conditions) to ascertain how the management system should actually carry out its control and monitoring tasks over time. To use a Differentiated Services example, the following pieces of knowledge: John.IPAddress = 192.168.0.1 HighQualVoD.Port = 1024 HighQualVoD.DiffServCodePoint = AssuredForwarding11 AssuredForwarding11.DSCP = 001010b AssuredForwarding11.Scheduling = PriorityQueuing EdgeRouters = [192.168.1.1, 192.168.5.1] CoreRouters = [192.168.2.1, 192.168.3.1, 192.168.4.1]
might be used by the management system to create concrete policies or devices commands such as: For all [EdgeRouters] If UDPPacket.DestIPAddress = 192.168.0.1 and UDPPacket.Port=1024 Then UDPPacket.DSCP = 001010 binary For all [CoreRouters] If IPPacket.DSCP = 001010 binary Then Queue1.Enqueue (IPPacket)
Ideally, this should be done in a manner that allows the service descriptions to change over time, so that Service Providers can add more value-added features, alter the operation of the services over their lifetime, or create entirely new services from scratch without altering the hard-coded components that are contained within the management system. Furthermore, as different events occur during the operation of the services, it may be necessary to re-evaluate how the services are configured and managed in accordance with new user requirements or environmental conditions. Almost all of the existing PBNM systems rely on assumptions, very limited service and representational models and/or specific translation and refinement patterns in order to achieve user requirements. In addition, they are also limited to the use of particular technologies or network capabilities and particular types of services. Our goal is to eliminate these restrictions, through the use of the service descriptions that provide enough information for the PBNM system to determine what needs to be done. This contributes immensely to adaptability and growth. D. How does policy benefit EEN management The benefits of using policy in EEN management will now be specifically identified: 1) Automation – policy describes to the management system what management activities are required and how they might be achieved. This helps to automate management tasks [22], and helps in achieving the tasks that are too costly or numerous to be performed by human operators [23].
2) Flexible and adaptable – policies can be written in a manner that takes advantage of knowledge that is contained in the management systems to deliver customised and personalised services and that may help in improving user experiences. 3) On-demand and reactive – PBNM systems allow the instantaneous behaviour of the network and the services to be adapted to different environmental conditions or requirements [24]. These changes can occur at any time during the lifetime of the service, facilitating on-demand service fulfilment and assurance. 4) Consistent behaviour – translation will create concrete and specific policies but the end-to-end behaviour of the entire network will remain consistent and predictable. 5) Complexity and scale of management tasks – these are significantly decreased through the association of policies with logical groups or roles, controlling many entities simultaneously. Furthermore, abstraction simplifies the policy specification [4], improving device- and vendor-independence, inter-operability, and policy readability. 6) Evolvability and growth – policy allows the behaviour of the management systems and processes to evolve over time as requirements change [25], increasing Service Provider agility. 7) Higher level goals and objectives – policies allow the management systems to focus on achieving higher-level objectives, such as service management [4]. Service Level Agreements (SLAs) can also be used by the PBNM system in formulating management activities for assurance. 8) Constraints on network usage – policies can also be used to limit how the network is utilised (e.g. resource allocations, unstable network configurations). Policy may also help to capture network operator knowledge and improved security of both management systems and networks. E. How does policy need to be extended for EEN management? Policy-based Management is not a panacea for all of the management woes of Service Providers, as there are many specific areas which are in need of improvement. Furthermore, the new challenges posed by EENs increase the complexity of the PBNM system and the scale of management tasks significantly. The following aspects need to be addressed through further research before policy will be completely usable and versatile: 1) Service models and descriptions – PBNM systems must be extended with service models that identify high-level requirements (e.g. user A has access to service B with parameters [C, D, E]) and service descriptions which indicate how services are operated through control/monitoring actions over time. This provides adaptable service delivery and allows the management systems to grow with the available services. 2) Translation – as identified above, translation is crucial to interpreting high-level user and service requirements into specific management activities. These requirements may also be driven from agreements with other Service Providers. Without consideration of these high-level requirements, networks are configured at a lowlevel without fully understanding who the users are, how to identify them and what their needs are. The management of different technologies and capabilities should be done through the use of logical network and service modelling.
3) Knowledge and IS integration – too few PBNM systems take advantage of the available knowledge in decision-making. Decisions can incorporate individual needs or environmental conditions, potentially improving the user experience. 4) Policy representational models – PBNM systems need to broaden their scope beyond the security and QoS policies which dominate most research and commercial systems. Policy models need to be expanded to include the management of devices outside of the edge and core networks, and into the home and access networks for cohesive end-to-end management. This includes user appliances, application servers and intermediate gateways. 5) Policy languages – languages facilitate readability and authoring and aid in efficient interpretation and conflict detection. Most current PBNM systems rely on condition-action models, more complex and specific language primitives may simplify expressions for managing services. 6) Monitoring – policy should also be used to ensure that services are meeting their QoE requirements. Measurements can then be used as feedback, so that services can be automatically tuned if requirements are not being met. Very few PBNM systems utilise feedback [2] or provide sufficient monitoring capabilities. 7) Policy consistency and conflicts - Many policy advocates discuss the need for validation and conflict detection within policies, due to contradictions in the chosen actions. Moffett [26] and Lupu [27] categorise conflicts into modality conflicts (contradiction between types of policies) and application-specific conflicts (due to model-specific inconsistencies or limitations). Precedence relationships are often used to resolve many conflicts automatically. However, more work needs to be done in incorporating conflict management into network management, particularly with concern for the dynamic properties of the environment which can introduce conflicts at any time, and in enforcing constraints due to device capabilities, resource utilisation and network limitations. 8) Scalability, distribution and coordination – it is highly probable that a distributed PBNM system will cope better with the demands of 107 users and services. PBNM systems can deploy policies to a number of management nodes simultaneously, increasing scalability. However, in some situations the actions of those management nodes to be coordinated to ensure consistent network-wide behaviour. As policies and knowledge change over time, management activities must be adjusted with some coordination across all management nodes and with minimal disturbance to operational services. 9) Inter-domain management – as Service Providers increasingly collaborate to provide services, it will be necessary for management systems to interact across multiple, independent domains. Interfaces need to be standardised so that the obligations of each Service Provider are clearly identified. Negotiation could also be used to establish SLAs between two Service Providers or between a Service Provider and a user [21]. However, a more generalised serviceexchange process will increase adaptability (e.g. allowing users to select on-demand services through portals and have them delivered instantly; peering between Service Providers for global roaming) but should be done cautiously, since many stakeholders will wish to maintain control over what can and can’t be done on their behalf. The PBNM system could use the results of these interactions to determine the course of action needed to support the services.
10) Configuration management – many PBNM systems need to support the configuration management of the network (like in systems developed by Intelliden and GoldWire Technology) so that operators can test different service configurations and introduce new services without the fear of a catastrophic network failure. Whilst not all of these properties are essential, the development of PBNM systems in these directions will help networks to evolve so that they are capable of achieving the vision of EENs. F. Will non-functional qualities be satisfied by PBNM systems? Whilst Policy-based Management has been an active research topic for more than 10 years, the concept of Policy-based Network Management (PBNM) was pre-dominantly driven by several standards efforts, from the Directory-Enabled Networks (DEN) adhoc working group, the Distributed Management Task Force (DMTF) and the Internet Engineering Task Force (IETF). In particular, the IETF work consisted of the Policy framework [21]. and the Common Open Policy Service (COPS) leading to the separation of the Policy Decision Point (PDP) from the Policy Enforcement Point (PEP). The most common archetype of PBNM systems (from the IETF) [21] is shown in Figure 4. Policy Management Tool
Policy Repository Policy Decision Point
Policy Enforcement Point
Fig. 4. Reference architecture for PBNM systems
Whilst this is a highly abstract and logical architecture and considered to be only a guideline, it appears that many research and commercial systems have taken this architecture quite literally. However, the IETF has not provided any guidance on how to perform policy validation, conflict detection/resolution and translation, nor have they standardised a language for the conditionaction expressions. Thus, inter-operability is severely limited [4]. Furthermore, the lack of service models and service descriptions in the architecture limits most implementations to simple devicecentric policies only. Before persisting with this architecture for EEN management, it needs to be evaluated to ensure that it will sufficiently meet nonfunctional qualities - timely performance, scalable and available will be considered pre-dominantly here. The IETF standards do have some consideration for nonfunctional qualities. If multiple PDPs are used in different parts of the network then scalability is increased. Additionally, the ability to use both the pull and push models in the COPS protocol enhances scalability, as each individual PEP takes responsibility for its own management. COPS also allows PEPs to switch between redundant PDPs in the event of failure, improving reliability, although there is no guarantee on switch-over time. The use of a Local PDP (LPDP) within the PEP helps to cache earlier policy decisions, alleviating the need for round-trip communication and increasing performance for subsequent decisions. These simple design principles have been somewhat helpful, but more needs to be done to ensure the architecture is carrier-class.
Some researchers have also examined the non-functional qualities of PBNM systems. Hamada, Czezowski and Chujo [11] noted their reservations on scalability and suggested a hierarchical LDAP repository with multicast. With no experimental results though, it is difficult to prove this approach over any other. Law and Saxena [28] improved the scalability of the PDPs through introducing Policy Enforcement Agents (PEAs) that perform load balancing. Ponnappan, Yang, Pillai and Braun [29] measured the response time between the PDP and PEP using the COPS-PR and COPS-RSVP protocols for QoS management. These results show that the performance degrades quickly under heavier loads. Unfortunately, the number of rules was small, and there is a remarkable difference in the response time between the work of [29] and that of [28] that needs to be examined more closely. Given that most existing PBNM systems have unknown nonfunctional qualities and a lack of a service focus, it is doubtful whether they can be used in carrier-class networks at this time. There have not been any that appear to be able to meet Service Providers demands [11] or that have been used in large scale networks and publicized [24] with the exception of Intelliden’s and Metasolv’s products. Indeed, most commercial systems that are available today are simply GUI management consoles for defining static, enterprise QoS and security policies [30]. For this reason, we are working on improving the understanding and capabilities of PBNM systems so that they will be suitable for EEN management. IV. CURRENT WORK Some of the active areas of our work are discussed below. A. Evaluation of PBNM systems The strengths and weaknesses of different PBNM systems and standards have been identified to see if they support EnrichedExperience Networks. Approximately thirty systems have been evaluated (at the time of writing) according to a wide range of general criteria such as the types of policies supported, the structural components of the policies, and the policy language elements. Furthermore, other EEN-specific aspects are investigated, such as the support for service management, reducing management complexity and several non-functional qualities. Another paper is in preparation regarding this work and it will be published shortly.
C. Non-functional qualities Our Architecture-based Engineering approach requires the critical evaluation of existing management system architectures for nonfunctional qualities, and this information is fed into the design process, so that newly constructed or evolving architectures may benefit from previous design experiences. In addition, the design process is cyclic, with architectures refined over several iterations. The use of different simulation techniques help in the evaluation of performance and scalability, and potentially other quality attributes, well before the system is implemented. We are continuing with this process as the design of our PBNM system develops, so that it will be possible to predict some of the characteristics of our architecture. One major concern with PBNM systems, though, is timely performance. By the use of efficient policy models and algorithms for translation, evaluation and conflict detection/resolution, the performance of the system can be remarkably different. These will be addressed in our forthcoming design work. D. Policy distribution and co-ordination It will be necessary to develop approaches to deal with the complexity of decentralizing the decision-making process to increase scalability and maximise the decision throughput. Ideally, policy distribution to several PDPs should happen automatically without any human intervention, even if the policies are changed at a later time by an operator. The ultimate vision is that policies may eventually be distributed to hardware devices for evaluation. It is relatively simple to partition most policies according to the specific areas of the network where they are concerned. Strassner [2] identified the need for neighbourhood (or inter-PDP) conflict detection/resolution, for situations where policies cannot be simply partitioned. In these cases, PDPs must coordinate their actions so that consistent behaviour is realised across the whole network. This is shown in Figure 5 where three policies overlap one particular PEP, thus requiring all four PDPs to coordinate their actions. PDP 1
Policy 2 Policy 1
PDP 2
B. PBNM languages and systems Our experimentation with the Ponder policy framework [24] has shown that using generic Policy-based Management systems for network management is cumbersome, particularly for modelling of complex logical layering. We wish to write policies reflected in multiple logical service layers, and minimise management system modifications through using open, pluggable interfaces for the management components which are hard-coded. Consequently, work has begun on designing a new PBNM system that supports the management of logical services, and allows adaptable service definitions to be created so that Service Providers can modify or add services at suitable business opportunities. Furthermore, the system will be designed so that external knowledge sources can be readily utilised, allowing for more complex policy decisions that may help to improve user experiences. We are considering the use of the Telemanagement Forum’s Shared Information and Data (SID) model as the basis of our PBNM system since it contains the most complete service model that is available at this time. However, SID is still too incomplete and abstract for our needs, and does not yet have the support for multiple Service Provider relationships.
PDP 4
Policy 3
Legend PEP PDP PDP 3
Fig. 5. Cross-PDP policies
If policies were to be changed, then those changes should be put into effect at the same time across the whole network, to minimise inconsistency. It would also be beneficial if the relevant knowledge used in policy decisions was also distributed closer to management nodes, so as to reduce latencies in the decision process. However, it will not be possible to distribute all of the available knowledge, as many management nodes will not have the resources available to keep all of this information locally. These goals will be kept in mind in the design of our PBNM system.
V. CONCLUSIONS
As research into Quality of Experience (QoE) proceeds, Service Providers will have the capability to predict the success or failure of services with greater accuracy through the deeper understanding of the purpose of user collaborations and the needs of individual users and market segments. Service Providers will be able to weigh the potential success of a service and its anticipated revenues against the costs and risks. An Enriched-Experience Network recognises that Quality of Experience resides with the people, not the networks - the networks can only influence it. Thus, it is all about living with technology, not just using it. PBNM systems promise to help Service Providers to find ways of diversifying their services and minimising operational expenses through automation and long-term evolvability. They may also help to improve user experiences through increasing the adaptability and flexibility to deal with individual user needs. However, PBNM systems need to have non-functional qualities that match or exceed existing carrier-class systems must be fulfilled, and Architecture-based Engineering approaches are being used in the MEEN project to evaluation, measure and design management systems that are able to meet these qualities and to trade-off between different architectures and design characteristics. ACKNOWLEDGMENTS
We would like to acknowledge Arnold Jansen and others from Alcatel for providing valuable comments on work leading up to this paper, the anonymous reviewers for their kind assistance, and the generous financial support of Alcatel Australia under the Alcatel Research Partnership Program (ARPP) and the Australian Research Council through Industry Linkage Grant LP0219784. REFERENCES
[1] S. Shepard, Telecommunications convergence : bridging the gap between technologies and services, 2nd ed: McGraw-Hill, 2002. [2] J. Strassner, Policy-Based Network Management: Solutions for the Next Generation: Morgan Kaufmann, 2003. [3] H. Bradlow, "Whither research in telecommunications services?," presented at ATNAC, Melbourne, Australia, 2003. [4] M. L. Stevens and W. J. Weiss, "Policy-based Management for IP Networks," Bell Labs Technical Journal, pp. 75-94, 1999. [5] R. Chadha, Y.-H. Cheng, T. Cheng, S. Gadgil, A. Hafid, K. Kim, G. Levin, N. Natarajan, K. Parmeswaran, A. Poylisher, and J. Unger, "PECAN: Policy-Enabled Configuration Across Networks," presented at POLICY, 2003. [6] R. W. Lucky, "Reflections: Where Is the Vision for Telecom?," Spectrum, IEEE, vol. 41, pp. 72, 2004. [7] A. Vogel, B. Kerherve, G. von Bochmann, and J. Gecsei, "Distributed multimedia and QOS: a survey," Multimedia, IEEE, vol. 2, pp. 10-19, 1995. [8] B. Bauer and A. Patrick, "A Human Factors Extension to the Seven-Layer OSI Reference Model." Self-published discussion paper, Jan 2004 [9] F. Cheong and R. Lai, "QoS specification and mapping for distributed multimedia systems: A survey of issues," Journal of Systems and Software, vol. 45, pp. 127-139, 1999. [10] S. Khirman and P. Henriksen, "Relationship between Qualityof-Service and Quality-of-Experience for Public Internet
[11] [12] [13]
[14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]
Service," presented at Passive and Active Measurement Workshop, 2002. T. Hamada, P. Czezowski, and T. Chujo, "Policy-based Management for Enterprise and Carrier IP Networking," Fujitsu Science and Technology, vol. 36, pp. 128-39, 2000. T. Keinonen, "User experience with communication technology," presented at Telework, 2001. S. Lee, N. Sheridan-Smith, T. O’Neill, J. Leaney, K. Sandrasegaran, and S. Markovits, "Managing the Enriched Experience Network – Learning-Outcome Approach to the Experimental Design Life-Cycle," presented at ATNAC, 2003. M. Perry, K. O'Hara, A. Sellen, B. Brown, and R. Harper, "Dealing with Mobility: Understanding access anytime, anywhere," ACM HCI, vol. 8, pp. 323-47, 2001. B. Levy, "21st Century Network: Services & Solutions," D. Colquitt, J. Leaney, and T. O’Neill "Integrating Architecture-based Trade-off Analysis into the design process through tool-assisted modelling," presented at ECBS, 2004. J. Soliman and T. O'Neill, "Quality Requirements," UTS, MEEN project guidelines Apr 2004. P. Flegkas, P. Trimintzios, G. Pavlou, I. Andrikopoulos, and C. F. Cavalcanti, "Policy-based Extensible Hierarchical Network Management," presented at POLICY, 2001. M. Sloman, "Policy Based Management of Telecommunication Systems and Networks," presented at Programmable Networks and Telecommunications, 1998. M. Sloman, "Policy Driven Management for Distributed Systems," JNSM, vol. 2, 1994. draft-ietf-policy-framework-00.txt, M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, and J. Wheeler, "Policy Framework," 13 Sept 99. D. C. Verma, "Simplifying Network Administration Using Policy-Based Management," IEEE Network, vol. 16, 2002. J. D. Moffett, "Specification of Management Policies and Discretionary Access Control," in Network and distributed systems management: Addison-Wesley, 1994, pp. 455-80. M. Sloman and E. Lupu, "Security and Management Policy Specification," IEEE Network, pp. 10-19, 2002. P. Flegkas, P. Trimintzios, and G. Pavlou, "A Policy-based Quality of Service Management System for IP DiffServ Networks," IEEE Network, pp. 50-56, 2002. J. D. Moffett and M. S. Sloman, "Policy Conflict Analysis in Distributed System Management," Organizational Computing, 1993. E. C. Lupu and M. Sloman, "Conflicts in policy-based distributed systems management," Soft. Eng., vol. 25, 1999. K. L. E. Law and A. Saxena, "Scalable Design of a PolicyBased Management System and its Performance," in IEEE Communications, vol 41, issue 6, June 2003. A. Ponnappan, L. Yang, R. Pillai, and P. Braun, "A Policy Based QoS Management System for the IntServ/DiffServ Based Internet," presented at POLICY, 2002. J. Conover, "Policy-Based Network Management," in Network Computing, 29 November 1999.
URLs are given at http://www.eng.uts.edu.au/~nigelss/urls/ATNAC04.html.
