summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3052.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3052.txt')
-rw-r--r--doc/rfc/rfc3052.txt675
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]
+