Network Working Group M. Eder Request for Comments: 3052 Nokia Category: Informational S. Nag January 2001 Service Management Architectures Issues and Review Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractMany of the support functions necessary to exploit the mechanisms by which differing levels of service can be provided are limited in scope and a complete framework is non-existent. Various efforts at such a framework have received a great deal of attention and represent a historical shift in scope for many of the organizations looking to address this problem. The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved.
The network and service management issue is going to be a major problem facing the networks of the future. This realization is a significant motivating factor in various efforts within the IP community which has been traditionally reluctant to take on issues of this type . The purpose of this document is to explore the problems of developing a framework for managing the network and services and to examine some of the issues that recent efforts have uncovered. 2]. Operators may be less able to support change in their Operational Support Systems (OSS) then they are in the network infrastructure because the OSS is tightly integrated into the
organizations business practices. The need for flexibility, and the other desires identified above, operators expect to have meet by having equipment vendors support open and common interfaces. Device manufactures have a need for management that will best represent the features and capabilities of the equipment they are developing and any management solution that hinders the ability of the equipment vendors to efficiently bring innovation to the market is contrary to their objectives. The common framework for solving the management needs of operators and equipment vendors has been based on a centralized approach with a the manager agent architecture. While providing a very straightforward approach to the problem of information management, this approach, and its variations, has not proved to scale well or allowed the flexibility required in today's modern data networks. Scaling and flexibility are especially a problem where there are many sophisticated network devices present. Methods of control must be found that work and scale at the same speeds as that of the control plane of the network itself if a major concern of the management system is with the dynamic control of traffic in a network. Increasingly it is a requirement that customers at the edge of the network be able to have access to management functionality. A centralized management approach may not provide the most convenient architecture to allow this capability. Frameworks based on a decentralized approach to the management architecture have gained momentum in recent years, but must address the possibility of having redundant management information throughout the network. A decentralized framework may have advantages with regards to scaling and speed of operation, but information and state management becomes complex in this approach, resulting in additional complication in developing such systems. The complexity of managing a network increases dramatically as the number of services and the number and complexity of devices in the network increases. The success of IP networks can be partially traced to the successful separation of transport control mechanisms from the complexity of service management, including billing. As the trend in IP is to allow for classes of traffic that will have both transport and service dependencies it has become apparent that many of the management problems are becoming more complex in nature and are starting to resemble those of the traditional telecom provisioned service environment. In the telecom environment no such separation exists between transport control mechanisms and service. The Telecom community has struggled for years to come up with a standard solution for the problem in national and international standardization bodies and achieved a debatable amount of industry acceptance.
Unfortunately, the hard learned lessons of how to manage the interdependencies between service and transport will be of questionable use to the IP community because of the much more limited concept of service in the telecommunications environment. Rules based management has received much attention as a method to reduce much of the overhead and operator intervention that was necessary in traditional management systems. The potential exists that a rules-based system could reduce the rate at which management information is increasing, but given the tremendous growth in this information, the problems with the control of that information will continue to exist. Rules add additional issues to the complexity of managing a network and as such will contribute to the information control problem. 3]. A number of open questions exist with the IP QoS architecture which will make it difficult to define a management architecture until they are resolved. These are well documented in "Next steps for the IP QoS architecture" , but from the management perspective warrant emphasizing. Current IP QoS architectures have not defined if the service will be per-application or only a transport-layer option. This will have significant impact both from a control perspective and from a billing and service assurance one. The assumption is that the routing best effort path will be used for both best effort traffic and for traffic of a different service level. In addition to those issues raised in , best effort path routing may not be able to identify the parameters necessary to identify routes capable of sustaining distinguished service traffic. In any architecture where a premium service will be offered it is a strong requirement that the service be measurable and sustainable. Provisioning that service will require a coherent view of the network and not just the device management view that is currently implemented in most networks. 5]. Generally there is agreement as to the scope of element management. Once outside that domain efforts to divide that task along clear boundaries have proved
elusive with many of the terms being used having their roots in the telecommunications industry and as such being of potentially limited use for IP management . Confusion resulting from the ambiguity associated with what functions compose management beyond those intended for the element, is compounded by the broad scope for which network and service management standards apply. Terms such a business goals, service management, and application management are not sufficiently defined to insure there will not be disagreement as to the actual scope of the management functions needed and to what extent interrelationships will exists between them. It is within this hazy domain that much of the recent efforts in rules-based management have been proposed as a potential solution. Efforts to devise a framework for policy management is an example of one of the most popular recent activities. Proposed requirements for policy management look very much like pre-existing network management requirements , but specific models needed to define policy itself and related to the definition of policy to control DiffServ and RSVP based QoS are under development.
without adding additional capacity. This does not come without tradeoffs. Both the purchase and management costs associated with the system must be calculated as well as the cost of the added complexity of adding additional control information to the network.
This section will discuss some of the issues that need to be resolved with regards to a service management framework to meet the requirements of the modern IP network. Some of the key concerns looking at a management system architecture include: - The management interface and models supported - The management system architecture - Where and how functionality is realized
situations, will exist in the management plan. IP management efforts have left the level of detail needed to define the actual location of the management information to the implementation. In a service management framework it may be necessary to achieve the desired results to supply a more complete framework along the lines of detail provided by the ITU-T telecommunications management network efforts where the interfaces and functionality across interfaces has been clearly defined. Information will need to exist in multiple locations simultaneously in any network architecture. As the quantity and complexity of that information increases limitations quickly develop. Changes in the information may need to be propagated in close to real time, further adding to the complication. 1]. One concept often discussed along with policy deals with the integration of legacy devices into the policy framework. The presumption is that legacy devices would be able to participate in the policy decision by having policy information translated into the native management interface. For this to succeed a device would have to support a functionality for which policy would be specified. This would limit the usefulness of this approach to only information
logically abstracted to the native interface of the device. Given that existing standard management interfaces do not support such functionality, all such devices would need to have a proprietary interface implemented. The interface being based on the existing interface supported by the device would potentially not have the scaling capabilities needed for a policy management system. Unlike a standard network management interface, were management information can be distributed between the adaptation layer and the network element, rules based management information may not be so easily distributed. The framework for integrating rules based management system with existing network devices is not readily apparent and further study is needed. The problem exists further when one considers that there will be early policy aware devices that may not be aware as the policy models are extended. The partially policy aware devices may represent additional architectural issues as it may not be possible to expect consistency in what aspects of policy a given devices implements if there does not exist formal sets of mandatory functionality with clear evolution paths. It is paramount if the policy management framework is going to able to evolve to accommodate the ever-increasing number of services likely to be supported by IP networks of the future that an evolution path be built into the framework.
on the elements along another routed path connecting the very same end points, so that there is no disruption in service and so that no human/operator intervention is required. The association of policy with the policy target is an area where considerable study may need to be done. Some issues are if this needs to be explicitly done or if the policy can be so written that a common description of the target is also included? Allowing a policy target to retrieve those policies that are relevant to it.
 Michael Eder, Sid Nag, Raj Bansal, "IP Service Management Framework", Work in Progress, October 1999.  Hugh Mahon, Yoram Bernet, and Shai Herzog, "Requirements for a Policy Management System", Work in Progress.  Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.  Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.  McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets" RFC 1156, May 1990.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.