|
|
|
|
|
|
IETF RFC 3052
Service Management Architectures Issues and Review
Last modified on Saturday, January 27th, 2001
 Permanent link to RFC 3052
 Search GitHub Wiki for RFC 3052
 Show other RFCs mentioning RFC 3052
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 © 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 © 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
Service Management Architectures Issues and Review
RFC TOTAL SIZE: 31859 bytes
PUBLICATION DATE: Saturday, January 27th, 2001
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
