Movatterモバイル変換

Network Working Group                                            M. EderRequest for Comments: 3052                                         NokiaCategory: Informational                                           S. Nag                                                            January 2001Service Management Architectures Issues and ReviewStatus 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.Abstract   Many 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.1. Introduction   Efforts to provide mechanisms to distinguish the priority given to   one set of packets, or flows, relative to another are well underway   and in many modern IP networks, best effort service will be just one   of the many services being offered by the network as opposed to it   being the only service provided.  Unfortunately, many of the support   functions necessary to exploit the mechanisms by which network level   service can be provided are limited in scope and a complete framework   is non-existent.  Compounding the problem is the varied understanding   of exactly what the scope of "service" is in an IP network.  IP, in   contrast to connection oriented network technologies, will not be   able to limit the definition of service management simply to end to   end connectivity, but will combine service management with regards to   transport with the service requirements of the actual applications   and how they are using the network.  The phenomenal growth in data   networks as well as the growth in application bandwidth usage has had   the consequence that the existing methods of management are not   sufficient to handle the growing demands of scale and complexity.Eder & Nag                   Informational                      [Page 1]

RFC 3052            Service Management Architectures        January 2001   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 [1].  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. The Problem of Management Standards   Network and service level issues traditionally are handled in IP   networks by engineering the network to provide the best service   possible for a single class of service.  Increasingly there is a   desire that IP networks be used to carry data with specific QoS   constraints.  IP networks will require a tremendous amount of   management information to provision, maintain, validate, and bill for   these new services.  The control and distribution of management   information in complex communications networks is one of the most   sophisticated tasks a network management framework must resolve. This   is compounded by the likelihood that devices in IP networks will be   varied and have differing management capabilities, ranging from   complex computing and switching platforms to personal hand held   devices and everything in between.  Scaling and performance   requirements will make the task of defining a single management   framework for these networks extremely complex.   In the past standardization efforts have suggested a simplified model   for management on the hypothesis that it can be extrapolated to solve   complex systems.  This premise has often proved to be without merit   because of the difficulty of developing such a model that meets both   the operators heterogeneous, multi-vendor need and network equipment   vendors specific needs.  At the center of efforts to devise a   standard management model are attempts to develop an architecture or   framework to control the management information. The same conflicting   operator vs. vendor forces are present in the effort to establish a   common framework architecture as are in the efforts to develop a   common information model.   Network operators requirements call for a framework that will permit   centralized management of the network and require the minimal   resources to operate and maintain while still providing tremendous   flexibility in choice of equipment and creativity of defining   services [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 theEder & Nag                   Informational                      [Page 2]

RFC 3052            Service Management Architectures        January 2001   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.Eder & Nag                   Informational                      [Page 3]

RFC 3052            Service Management Architectures        January 2001   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.2.1. IP QoS Management   Much of the current management efforts are focused on solving control   issues for IP QoS [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" [4], 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 [4], 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.2.2. Promise of rules-based Management   Management standardization efforts in the IP community have so far   been concerned primarily with what is commonly referred to as   "element management" or "device management" [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 provedEder & Nag                   Informational                      [Page 4]

RFC 3052            Service Management Architectures        January 2001   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 [1].  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 [2], 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.2.3. Service Management Requirements   Efforts to define the requirements for a service management system   are hindered by the different needs of network operators.  In an   industry where much has been written about the trend towards   convergence there still exist fundamental differences in the business   needs of operators.2.3.1. Enterprise   The management requirements from both the operations and the network   perspective have some interesting characteristics in the enterprise   environment when compared to the public network.  In the enterprise   end to end traffic management is implemented without the burden of   complex tariff issues.  Service Level Agreements, while increasing in   the enterprise, do not have the same operations impact as in the   public network.  The high costs associated with implementing non-   reputable auditing systems are usually not present.  This results in   a substantial reduction in the number of expressions necessary to   represent a particular networks business model.   In the world of best effort service, rules-based management presents   the possibility to give the IT department a tool the make the network   appear to not be overloaded by prioritizing traffic.  This is done by   prioritizing delay sensitive traffic (Web browsing) from traffic that   is not delay sensitive (Email) or by prioritizing the traffic from a   particular location or source.  This will, depending on the composite   of an enterprises traffic, increase the useful life of the networkEder & Nag                   Informational                      [Page 5]

RFC 3052            Service Management Architectures        January 2001   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.2.3.2. Service Provider   It has for a long time been a goal of service providers to have a   centralized management system.  While the motivation for this is very   straightforward there exist some fundamental obstacles in achieving   this goal.  Service providers often do not want to be tied to a   single vendor and certainly do not want to be limited to only one   model of any single vendors equipment.  At the same time bottom line   costs are of paramount importance which often result in networks not   being as heterogeneous as operators would like. Centralized   management implies a scalable system able to manage potentially many   heterogeneous pieces of equipment.  The amount of data necessary to   achieve this is contrary to the scalability requirement.  In response   to this problem it has been attempted many times to identify the   common model that represents the subset common to all devices.   Unfortunately all too often this set is either too complex,   increasing the cost of devices, or too limited to preclude large   amounts of device specific data thus defeating the purpose. For such   a management model to be successful at the service level, the   services being modeled must be standardized.  This is counter   intuitive to the competitive model of which the service provider   operates.  To be successful speed to market has become a key element   that differentiates one service provider from another.  Constraints   placed on equipment manufacturers and the management infrastructure   by a centralized management system are also detrimental to this goal.   While for a limited set of well defined services a central management   approach is feasible, such a system can very quickly become a major   contributor to the very problems it was intended to solve.3. Network and Service Management   Currently many of the efforts to define a framework for management   are described in very implementation independent terms.  In actual   fact the implementation of that framework directly affects for what   situations the management system will be most beneficial.  While many   past attempts to define a common management framework have failed it   may be in the area of service management that such efforts finally   gain industry acceptance.  It may be in the domain of service   management that information models can be defined that are   sufficiently specific to be useful and at that same time not have a   negative impact on the equipment or service providers business needs.Eder & Nag                   Informational                      [Page 6]

RFC 3052            Service Management Architectures        January 2001   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 realized3.1. Architecture for information management   Networks will consist of network elements that have existed prior to   efforts to define a standard information model, rules-based or   otherwise, and elements deployed after.  This problem has been   addressed by some of the recent efforts in policy management.  Those   elements that take into account policy are termed policy aware while   those that do not are termed policy unaware.  The distinction being   made that aware devices can interpret the policy information model or   schema.  These issues apply equally to other standard management   information.  In reality it is unlikely that any device will be fully   policy aware for long, as the policy information model evolves, early   devices will be only policy aware for those aspects of the model that   had been defined at the time.  Key to success of any management   framework is ability to handle revision and evolution.  A number   methods exists provide this functionality.  One is designing the   information models so that it can be extended but still be   practically used in their original form.  A second is to provide an   adaptation or proxy layer.  Each has advantages and disadvantages.   Methods that attempt to extend the original model often overly   constrain themselves.  Where the existing model cannot be extended   new branches must be formed in the model that contain core management   functionality.   Adaptation methods can create performance and scalability problems   and add complexity to the network by creating additional network   elements.  A similar situation exists if the management framework is   so flexible as to allow network elements to store locally information   or choose to have information stored remotely.  From a device   perspective, the criteria will be if the device can afford the logic   based on other requirements it is designed to meet, and if the   information can be retrieved in such a way as to support the   performance and scalability requirements that are the subject of the   information.  A dichotomy exists where there will be information that   for reasons of performance and scalability will be transferred   directly to the network elements in some situations, and in otherEder & Nag                   Informational                      [Page 7]

RFC 3052            Service Management Architectures        January 2001   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.3.1.1. Rules-based Management   A network management framework can be viewed as being divided into   two essential functions.  The first deals with the aspects of   managing the management information while the second deals with the   aspects of transferring that management information into the network.   The fundamental difference between rules based management and   existing network management standards is that the management   information is expressed as rules that reflect a desired level of   service from the network as opposed to device specific management   information.  Many of the information management requirements of   traditional management systems still apply in a rules-based   environment.  The network is composed of specific devices and it is   at the point where rules are conveyed as device specific management   information that this form of management will encounter some of its   greatest challenges.  A necessary component of a solution to this   problem will be a generic information model to which rules can be   applied and a framework architecture for distributing rules   throughout the network.  The task of finding the proper generic model   that is not too great a burden to implement and yet provides a level   of detail sufficient to manage a network has proved to be   historically extremely difficult.  In many ways the degree to which   rules based management will be able to solve management problems is   dependent on the success of efforts to define a generic model and   have it be widely implemented [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 informationEder & Nag                   Informational                      [Page 8]

RFC 3052            Service Management Architectures        January 2001   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.3.2. Policy Protocol   The need for a policy protocol is important in the context of a   policy aware element that is performing a certain 'service'.  It is   important to note here that not all elements will be aware of all   service policies related to every service at all times.  Therefore it   makes sense for an element to be aware of a certain service policy if   that element is required for a given service at any instant in time.   With the dynamics of a network where elements and links go up and   down, a notion of a 'policy protocol' may become necessary.  The idea   of a 'policy protocol' that runs in a multi-service network requiring   multi-service policies.  For example; consider two arbitrary end   nodes having multiple routing paths between them. Let's then assume   that a certain path carries a certain service based on some Intserv   bandwidth reservation technique.  Let's also then deduce that the   elements along that path have some element specific policy statements   that have been configured on them to support that requirement.  If   now at any given instance any link or any element were to be   unavailable along that path, the 'policy protocol' should be   initiated to automatically go and configure the same service-policiesEder & Nag                   Informational                      [Page 9]

RFC 3052            Service Management Architectures        January 2001   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.4. Conclusions   Understanding the set of problems facing IP network management in   general will be key in defining a comprehensive framework   architecture that meets the needs of operators.  Additional risks are   created by applying new management techniques to the management of IP   networks.  The consequence of implementing management operations   based on architectures that may not be compatible with existing   management systems will still need to be explored.   Given that many network devices in IP networks are making routing   decisions based on information received via routing protocols it   seems sensible that they also make QoS decisions in a similar   fashion.   Historically the broader the scope of a network management   standardization effort the less likely it has been to succeed.   Management standardization efforts must be careful to have clearly   defined goals and requirements less they to experience the same fate   as previous such efforts.   As IP continues to extend it's concept of service beyond that of best   effort to include, among other things, differentiate treatment of   packets, it will become increasingly necessary to have mechanisms   capable of supporting these extensions.  Efforts to define a common   management model and framework have proven to be historically   elusive.  Information models, whether they be traditional or rules-   based, must address these past problems.  The desire to keep a   competitive advantage, and the reality that a common model, to be   truly common, will not provide sufficient detail to fully manage a   device, has often slowed the acceptance on the part of equipment   vendors to this approach.   As IP continues to extend it's concept of service beyond that of best   effort to include, among other things, differentiate treatment of   packets it will become increasingly necessary to have mechanisms   capable of supporting these extensions.Eder & Nag                   Informational                     [Page 10]

RFC 3052            Service Management Architectures        January 20015. Security Considerations   The exchange of management information in a network is one of the   most sensitive from a security perspective.  Management protocols   must address security to insure the integrity of the data.  A   management architecture must provide for security considerations from   its inception to insure the authenticity of the information provider   and that the security mechanisms not be so cumbersome as to make them   not feasible to implement.6. Reference   [1] Michael Eder, Sid Nag, Raj Bansal, "IP Service Management       Framework", Work in Progress, October 1999.   [2] Hugh Mahon, Yoram Bernet, and Shai Herzog, "Requirements for a       Policy Management System", Work in Progress.   [3] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for       Policy-based Admission Control",RFC 2753, January 2000.   [4] Huston, G., "Next Steps for the IP QoS Architecture",RFC 2990,       November 2000.   [5] McCloghrie, K. and M. Rose, "Management Information Base for       Network Management of TCP/IP-based internets"RFC 1156, May 1990.7. Authors' Addresses   Michael Eder   Nokia   5 Wayside Road   Burlington, MA  01803   EMail: michael.eder@nokia.com   Sid Nag   PO Box 104   Holmdel, NJ 07733   EMail: thinker@monmouth.comEder & Nag                   Informational                     [Page 11]

RFC 3052            Service Management Architectures        January 20018. Full Copyright Statement   Copyright (C) The Internet Society (2001).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Eder & Nag                   Informational                     [Page 12]