As per Relevance of the word framework, we have this rfc below:
Network Working Group M.
Request for Comments: 3052
Category: Informational S.
January 2001
Service Management Architectures Issues and
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
Many of the support functions necessary to exploit the mechanisms
which differing levels of service can be provided are limited
scope and a complete framework is non-existent. Various efforts
such a framework have received a great deal of attention
represent a historical shift in scope for many of the
looking to address this problem. The purpose of this document is
explore the problems of defining a Service management framework
to examine some of the issues that still need to be resolved
1.
Efforts to provide mechanisms to distinguish the priority given
one set of packets, or flows, relative to another are well
and in many modern IP networks, best effort service will be just
of the many services being offered by the network as opposed to
being the only service provided. Unfortunately, many of the
functions necessary to exploit the mechanisms by which network
service can be provided are limited in scope and a complete
is non-existent. Compounding the problem is the varied
of exactly what the scope of "service" is in an IP network. IP,
contrast to connection oriented network technologies, will not
able to limit the definition of service management simply to end
end connectivity, but will combine service management with regards
transport with the service requirements of the actual
and how they are using the network. The phenomenal growth in
networks as well as the growth in application bandwidth usage has
the consequence that the existing methods of management are
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
problem facing the networks of the future. This realization is
significant motivating factor in various efforts within the
community which has been traditionally reluctant to take on issues
this type [1]. The purpose of this document is to explore
problems of developing a framework for managing the network
services and to examine some of the issues that recent efforts
uncovered
2. The Problem of Management
Network and service level issues traditionally are handled in
networks by engineering the network to provide the best
possible for a single class of service. Increasingly there is
desire that IP networks be used to carry data with specific
constraints. IP networks will require a tremendous amount
management information to provision, maintain, validate, and bill
these new services. The control and distribution of
information in complex communications networks is one of the
sophisticated tasks a network management framework must resolve.
is compounded by the likelihood that devices in IP networks will
varied and have differing management capabilities, ranging
complex computing and switching platforms to personal hand
devices and everything in between. Scaling and
requirements will make the task of defining a single
framework for these networks extremely complex
In the past standardization efforts have suggested a simplified
for management on the hypothesis that it can be extrapolated to
complex systems. This premise has often proved to be without
because of the difficulty of developing such a model that meets
the operators heterogeneous, multi-vendor need and network
vendors specific needs. At the center of efforts to devise
standard management model are attempts to develop an architecture
framework to control the management information. The same
operator vs. vendor forces are present in the effort to establish
common framework architecture as are in the efforts to develop
common information model
Network operators requirements call for a framework that will
centralized management of the network and require the
resources to operate and maintain while still providing
flexibility in choice of equipment and creativity of
services [2]. Operators may be less able to support change in
Operational Support Systems (OSS) then they are in the
infrastructure because the OSS is tightly integrated into
Eder & Nag Informational [Page 2]
RFC 3052 Service Management Architectures January 2001
organizations business practices. The need for flexibility, and
other desires identified above, operators expect to have meet
having equipment vendors support open and common interfaces
Device manufactures have a need for management that will
represent the features and capabilities of the equipment they
developing and any management solution that hinders the ability
the equipment vendors to efficiently bring innovation to the
is contrary to their objectives
The common framework for solving the management needs of
and equipment vendors has been based on a centralized approach with
the manager agent architecture. While providing a
straightforward approach to the problem of information management
this approach, and its variations, has not proved to scale well
allowed the flexibility required in today's modern data networks
Scaling and flexibility are especially a problem where there are
sophisticated network devices present. Methods of control must
found that work and scale at the same speeds as that of the
plane of the network itself if a major concern of the
system is with the dynamic control of traffic in a network
Increasingly it is a requirement that customers at the edge of
network be able to have access to management functionality.
centralized management approach may not provide the most
architecture to allow this capability
Frameworks based on a decentralized approach to the
architecture have gained momentum in recent years, but must
the possibility of having redundant management information
the network. A decentralized framework may have advantages
regards to scaling and speed of operation, but information and
management becomes complex in this approach, resulting in
complication in developing such systems
The complexity of managing a network increases dramatically as
number of services and the number and complexity of devices in
network increases. The success of IP networks can be
traced to the successful separation of transport control
from the complexity of service management, including billing. As
trend in IP is to allow for classes of traffic that will have
transport and service dependencies it has become apparent that
of the management problems are becoming more complex in nature
are starting to resemble those of the traditional telecom
service environment. In the telecom environment no such
exists between transport control mechanisms and service. The
community has struggled for years to come up with a standard
for the problem in national and international standardization
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
interdependencies between service and transport will be
questionable use to the IP community because of the much more
concept of service in the telecommunications environment
Rules based management has received much attention as a method
reduce much of the overhead and operator intervention that
necessary in traditional management systems. The potential
that a rules-based system could reduce the rate at which
information is increasing, but given the tremendous growth in
information, the problems with the control of that information
continue to exist. Rules add additional issues to the complexity
managing a network and as such will contribute to the
control problem
2.1. IP QoS
Much of the current management efforts are focused on solving
issues for IP QoS [3]. A number of open questions exist with the
QoS architecture which will make it difficult to define a
architecture until they are resolved. These are well documented
"Next steps for the IP QoS architecture" [4], but from the
perspective warrant emphasizing
Current IP QoS architectures have not defined if the service will
per-application or only a transport-layer option. This will
significant impact both from a control perspective and from a
and service assurance one
The assumption is that the routing best effort path will be used
both best effort traffic and for traffic of a different
level. In addition to those issues raised in [4], best effort
routing may not be able to identify the parameters necessary
identify routes capable of sustaining distinguished service traffic
In any architecture where a premium service will be offered it is
strong requirement that the service be measurable and sustainable
Provisioning that service will require a coherent view of the
and not just the device management view that is currently
in most networks
2.2. Promise of rules-based
Management standardization efforts in the IP community have so
been concerned primarily with what is commonly referred to
"element management" or "device management" [5]. Generally there
agreement as to the scope of element management. Once outside
domain efforts to divide that task along clear boundaries have
Eder & Nag Informational [Page 4]
RFC 3052 Service Management Architectures January 2001
elusive with many of the terms being used having their roots in
telecommunications industry and as such being of potentially
use for IP management [1]. Confusion resulting from the
associated with what functions compose management beyond
intended for the element, is compounded by the broad scope for
network and service management standards apply. Terms such
business goals, service management, and application management
not sufficiently defined to insure there will not be disagreement
to the actual scope of the management functions needed and to
extent interrelationships will exists between them
It is within this hazy domain that much of the recent efforts
rules-based management have been proposed as a potential solution
Efforts to devise a framework for policy management is an example
one of the most popular recent activities. Proposed requirements
policy management look very much like pre-existing network
requirements [2], but specific models needed to define policy
and related to the definition of policy to control DiffServ and
based QoS are under development
2.3. Service Management
Efforts to define the requirements for a service management
are hindered by the different needs of network operators. In
industry where much has been written about the trend
convergence there still exist fundamental differences in the
needs of operators
2.3.1.
The management requirements from both the operations and the
perspective have some interesting characteristics in the
environment when compared to the public network. In the
end to end traffic management is implemented without the burden
complex tariff issues. Service Level Agreements, while increasing
the enterprise, do not have the same operations impact as in
public network. The high costs associated with implementing non
reputable auditing systems are usually not present. This results
a substantial reduction in the number of expressions necessary
represent a particular networks business model
In the world of best effort service, rules-based management
the possibility to give the IT department a tool the make the
appear to not be overloaded by prioritizing traffic. This is done
prioritizing delay sensitive traffic (Web browsing) from traffic
is not delay sensitive (Email) or by prioritizing the traffic from
particular location or source. This will, depending on the
of an enterprises traffic, increase the useful life of the
Eder & Nag Informational [Page 5]
RFC 3052 Service Management Architectures January 2001
without adding additional capacity. This does not come
tradeoffs. Both the purchase and management costs associated
the system must be calculated as well as the cost of the
complexity of adding additional control information to the network
2.3.2. Service
It has for a long time been a goal of service providers to have
centralized management system. While the motivation for this is
straightforward there exist some fundamental obstacles in
this goal. Service providers often do not want to be tied to
single vendor and certainly do not want to be limited to only
model of any single vendors equipment. At the same time bottom
costs are of paramount importance which often result in networks
being as heterogeneous as operators would like.
management implies a scalable system able to manage potentially
heterogeneous pieces of equipment. The amount of data necessary
achieve this is contrary to the scalability requirement. In
to this problem it has been attempted many times to identify
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
amounts of device specific data thus defeating the purpose. For
a management model to be successful at the service level,
services being modeled must be standardized. This is
intuitive to the competitive model of which the service
operates. To be successful speed to market has become a key
that differentiates one service provider from another.
placed on equipment manufacturers and the management
by a centralized management system are also detrimental to this goal
While for a limited set of well defined services a central
approach is feasible, such a system can very quickly become a
contributor to the very problems it was intended to solve
3. Network and Service
Currently many of the efforts to define a framework for
are described in very implementation independent terms. In
fact the implementation of that framework directly affects for
situations the management system will be most beneficial. While
past attempts to define a common management framework have failed
may be in the area of service management that such efforts
gain industry acceptance. It may be in the domain of
management that information models can be defined that
sufficiently specific to be useful and at that same time not have
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
with regards to a service management framework to meet
requirements of the modern IP network
Some of the key concerns looking at a management system
include
- The management interface and models
- The management system
- Where and how functionality is
3.1. Architecture for information
Networks will consist of network elements that have existed prior
efforts to define a standard information model, rules-based
otherwise, and elements deployed after. This problem has
addressed by some of the recent efforts in policy management.
elements that take into account policy are termed policy aware
those that do not are termed policy unaware. The distinction
made that aware devices can interpret the policy information model
schema. These issues apply equally to other standard
information. In reality it is unlikely that any device will be
policy aware for long, as the policy information model evolves,
devices will be only policy aware for those aspects of the model
had been defined at the time. Key to success of any
framework is ability to handle revision and evolution. A
methods exists provide this functionality. One is designing
information models so that it can be extended but still
practically used in their original form. A second is to provide
adaptation or proxy layer. Each has advantages and disadvantages
Methods that attempt to extend the original model often
constrain themselves. Where the existing model cannot be
new branches must be formed in the model that contain core
functionality
Adaptation methods can create performance and scalability
and add complexity to the network by creating additional
elements. A similar situation exists if the management framework
so flexible as to allow network elements to store locally
or choose to have information stored remotely. From a
perspective, the criteria will be if the device can afford the
based on other requirements it is designed to meet, and if
information can be retrieved in such a way as to support
performance and scalability requirements that are the subject of
information. A dichotomy exists where there will be information
for reasons of performance and scalability will be
directly to the network elements in some situations, and in
Eder & Nag Informational [Page 7]
RFC 3052 Service Management Architectures January 2001
situations, will exist in the management plan. IP management
have left the level of detail needed to define the actual location
the management information to the implementation. In a
management framework it may be necessary to achieve the
results to supply a more complete framework along the lines of
provided by the ITU-T telecommunications management network
where the interfaces and functionality across interfaces has
clearly defined
Information will need to exist in multiple locations
in any network architecture. As the quantity and complexity of
information increases limitations quickly develop. Changes in
information may need to be propagated in close to real time,
adding to the complication
3.1.1. Rules-based
A network management framework can be viewed as being divided
two essential functions. The first deals with the aspects
managing the management information while the second deals with
aspects of transferring that management information into the network
The fundamental difference between rules based management
existing network management standards is that the
information is expressed as rules that reflect a desired level
service from the network as opposed to device specific
information. Many of the information management requirements
traditional management systems still apply in a rules-
environment. The network is composed of specific devices and it
at the point where rules are conveyed as device specific
information that this form of management will encounter some of
greatest challenges. A necessary component of a solution to
problem will be a generic information model to which rules can
applied and a framework architecture for distributing
throughout the network. The task of finding the proper generic
that is not too great a burden to implement and yet provides a
of detail sufficient to manage a network has proved to
historically extremely difficult. In many ways the degree to
rules based management will be able to solve management problems
dependent on the success of efforts to define a generic model
have it be widely implemented [1].
One concept often discussed along with policy deals with
integration of legacy devices into the policy framework.
presumption is that legacy devices would be able to participate
the policy decision by having policy information translated into
native management interface. For this to succeed a device would
to support a functionality for which policy would be specified.
would limit the usefulness of this approach to only
Eder & Nag Informational [Page 8]
RFC 3052 Service Management Architectures January 2001
logically abstracted to the native interface of the device.
that existing standard management interfaces do not support
functionality, all such devices would need to have a
interface implemented. The interface being based on the
interface supported by the device would potentially not have
scaling capabilities needed for a policy management system. Unlike
standard network management interface, were management
can be distributed between the adaptation layer and the
element, rules based management information may not be so
distributed
The framework for integrating rules based management system
existing network devices is not readily apparent and further study
needed. The problem exists further when one considers that
will be early policy aware devices that may not be aware as
policy models are extended. The partially policy aware devices
represent additional architectural issues as it may not be
to expect consistency in what aspects of policy a given
implements if there does not exist formal sets of
functionality with clear evolution paths. It is paramount if
policy management framework is going to able to evolve to
the ever-increasing number of services likely to be supported by
networks of the future that an evolution path be built into
framework
3.2. Policy
The need for a policy protocol is important in the context of
policy aware element that is performing a certain 'service'. It
important to note here that not all elements will be aware of
service policies related to every service at all times. Therefore
makes sense for an element to be aware of a certain service policy
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
down, a notion of a 'policy protocol' may become necessary. The
of a 'policy protocol' that runs in a multi-service network
multi-service policies. For example; consider two arbitrary
nodes having multiple routing paths between them. Let's then
that a certain path carries a certain service based on some
bandwidth reservation technique. Let's also then deduce that
elements along that path have some element specific policy
that have been configured on them to support that requirement.
now at any given instance any link or any element were to
unavailable along that path, the 'policy protocol' should
initiated to automatically go and configure the same service-
Eder & Nag Informational [Page 9]
RFC 3052 Service Management Architectures January 2001
on the elements along another routed path connecting the very
end points, so that there is no disruption in service and so that
human/operator intervention is required
The association of policy with the policy target is an area
considerable study may need to be done. Some issues are if
needs to be explicitly done or if the policy can be so written that
common description of the target is also included? Allowing a
target to retrieve those policies that are relevant to it
4.
Understanding the set of problems facing IP network management
general will be key in defining a comprehensive
architecture that meets the needs of operators. Additional risks
created by applying new management techniques to the management of
networks. The consequence of implementing management
based on architectures that may not be compatible with
management systems will still need to be explored
Given that many network devices in IP networks are making
decisions based on information received via routing protocols
seems sensible that they also make QoS decisions in a
fashion
Historically the broader the scope of a network
standardization effort the less likely it has been to succeed
Management standardization efforts must be careful to have
defined goals and requirements less they to experience the same
as previous such efforts
As IP continues to extend it's concept of service beyond that of
effort to include, among other things, differentiate treatment
packets, it will become increasingly necessary to have
capable of supporting these extensions. Efforts to define a
management model and framework have proven to be
elusive. Information models, whether they be traditional or rules
based, must address these past problems. The desire to keep
competitive advantage, and the reality that a common model, to
truly common, will not provide sufficient detail to fully manage
device, has often slowed the acceptance on the part of
vendors to this approach
As IP continues to extend it's concept of service beyond that of
effort to include, among other things, differentiate treatment
packets it will become increasingly necessary to have
capable of supporting these extensions
Eder & Nag Informational [Page 10]
RFC 3052 Service Management Architectures January 2001
5. Security
The exchange of management information in a network is one of
most sensitive from a security perspective. Management
must address security to insure the integrity of the data.
management architecture must provide for security considerations
its inception to insure the authenticity of the information
and that the security mechanisms not be so cumbersome as to make
not feasible to implement
6.
[1] Michael Eder, Sid Nag, Raj Bansal, "IP Service
Framework", Work in Progress, October 1999.
[2] Hugh Mahon, Yoram Bernet, and Shai Herzog, "Requirements for
Policy Management System", Work in Progress
[3] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
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
Network Management of TCP/IP-based internets" RFC 1156, May 1990.
7. Authors'
Michael
5 Wayside
Burlington, MA 01803
EMail: michael.eder@nokia.
Sid
PO Box 104
Holmdel, NJ 07733
EMail: thinker@monmouth.
Eder & Nag Informational [Page 11]
RFC 3052 Service Management Architectures January 2001
8. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Eder & Nag Informational [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
