rfc3052.txt

RFC 的详细文档！


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