doc: Add RFC documents

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]
+