diff options
Diffstat (limited to 'doc/rfc/rfc3052.txt')
-rw-r--r-- | doc/rfc/rfc3052.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3052.txt b/doc/rfc/rfc3052.txt new file mode 100644 index 0000000..dd5b33d --- /dev/null +++ b/doc/rfc/rfc3052.txt @@ -0,0 +1,675 @@ + + + + + + +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. + +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 the + + + + + +Eder & 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 proved + + + +Eder & 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 network + + + +Eder & 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 realized + +3.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 other + + + +Eder & 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 information + + + +Eder & 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-policies + + + + + +Eder & 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 2001 + + +5. 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.com + + + + + + + + + +Eder & Nag Informational [Page 11] + +RFC 3052 Service Management Architectures January 2001 + + +8. 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] + |