📄 rfc3052.txt
字号:
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]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -