rfc3052.txt

最新的RFC

   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: [e-mail]


   Sid Nag
   PO Box 104
   Holmdel, NJ 07733

   EMail: [e-mail]









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]