RFC 3052

Service Management Architectures Issues and Review

📅 published January 2001, from ietf

Service Management Architectures Issues and Review 🎀

okay bestie, this is RFC 3052, titled Service Management Architectures Issues and Review ✨ It was written by M. Eder from Nokia and S. Nag 💖 It's an Informational doc, which means it's just sharing info with the Internet community. It does not specify a standard. It's dated January 2001, and the header doesn't list anything it obsoletes or updates 🧚

Status of this Memo 📜

ok so this memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🦋

okay so the big tea here is that a lot of the support functions you need to actually use the mechanisms that give different levels of service are super limited in scope, and there's no complete framework at all 💀 People have tried building one, and it's gotten a ton of attention and is a huge shift for a lot of the orgs trying to fix this. This doc is here to explore the problems of defining a service management framework and look at some of the issues that still need sorting out 🔥

1. Introduction ✨

so efforts to let one set of packets, or flows, get priority over another are already well underway 🏃‍♀️ In lots of modern IP networks, best effort service is just one of many services the network offers, rather than the only one 💅 The annoying part is that many of the support functions needed to use those network-level service mechanisms are limited in scope, and there's still no complete framework 😭 It's also compounded by everyone having a different idea of what "service" even means in an IP network 🤷‍♀️ Unlike connection oriented network technologies, IP can't just limit service management to end to end connectivity. It has to combine transport management with the service requirements of the actual applications and how they use the network 🧠 On top of that, data networks have grown like crazy, and so has application bandwidth usage. That means the existing management methods just aren't enough for the scale and complexity we're dealing with now 📈

Network and service management is going to be a major problem for the networks of the future 🔮 Realizing this is a big reason why various efforts in the IP community are happening, even though that community has traditionally been reluctant to take on issues like this [1] 💜 So this doc explores the problems of developing a framework for managing the network and its services, and looks at some of the issues recent efforts have uncovered 🫶

2. The Problem of Management Standards 🎀

okay so traditionally, IP networks have handled network and service level issues by engineering the network to give the best possible service for a single class of service 🌈 But people increasingly want IP networks to carry data with specific QoS constraints 👑 To provision, maintain, validate, and bill for these new services, IP networks will need a huge amount of management information 📚 Controlling and distributing management information in complex communications networks is one of the most sophisticated jobs a network management framework has to handle. It's made harder by the fact that devices in IP networks will be really varied, with different management capabilities. They range from complex computing and switching platforms all the way down to personal hand held devices, and everything in between 📱 Scaling and performance requirements make defining one single management framework for these networks extremely complex 🥵

Standardization efforts in the past have suggested a simplified model for management, based on the idea that it could be extended to solve complex systems 🙃 That premise has often not worked out, because it's really hard to build a model that meets both the operators' heterogeneous, multi-vendor needs and the specific needs of network equipment vendors 💀 Right at the center of efforts to devise a standard management model are attempts to develop an architecture or framework for controlling management information 🧩 The same conflicting operator vs. vendor forces show up in the effort to establish a common framework architecture, just like they do in efforts to develop a common information model ⚔️

Network operators need a framework that permits centralized management of the network. It should require minimal resources to operate and maintain, while still offering a ton of flexibility in choosing equipment and creativity in defining services [2] 💅 Operators may be less able to support change in their Operational Support Systems (OSS) than they are in the network infrastructure, because the OSS is tightly integrated into the organization's business practices 🏢 Operators expect to meet the flexibility and other desires listed above by having equipment vendors support open and common interfaces 🔓

Device manufacturers need management that best represents the features and capabilities of the equipment they're developing 🛠️ Any management solution that gets in the way of equipment vendors bringing innovation to market efficiently goes against their goals 🙅‍♀️

The common framework for solving the management needs of operators and equipment vendors has been based on a centralized approach with a manager agent architecture 🧃 It's a super straightforward way to handle information management, but this approach and its variations haven't scaled well, and they haven't allowed the flexibility today's modern data networks need 😩 Scaling and flexibility are especially a problem where there are lots of sophisticated network devices. If management is mainly about dynamically controlling traffic in a network, the methods of control have to work and scale at the same speeds as the network's own control plane ⚡ On top of that, customers at the edge of the network increasingly need access to management functionality, and a centralized approach may not be the most convenient architecture for that 🌐

Decentralized frameworks have gained momentum in recent years, but they have to deal with the possibility of redundant management information throughout the network 🔁 A decentralized framework can have advantages for scaling and speed of operation. But information and state management gets complicated in this approach, which makes building these systems more complicated too 🧶

The complexity of managing a network goes up dramatically as the number of services and the number and complexity of devices in the network go up 📈 The success of IP networks can be partly traced to how well transport control mechanisms were separated from the complexity of service management, including billing 🏆 But IP traffic is trending toward classes of traffic with both transport and service dependencies. Because of that, a lot of the management problems are getting more complex and starting to look like those of the traditional telecom provisioned service environment 📞 In the telecom environment, there's no separation at all between transport control mechanisms and service. The Telecom community has struggled for years to come up with a standard solution in national and international standardization bodies, and it has achieved a debatable amount of industry acceptance 😬

Unfortunately, the hard-learned lessons about managing the interdependencies between service and transport will be of questionable use to the IP community. The reason is that the telecommunications environment has a much more limited concept of service 🙄

Rules based management has gotten a lot of attention as a way to reduce much of the overhead and operator intervention that traditional management systems needed 🧹 A rules-based system could potentially slow the rate at which management information is growing. But given how huge that growth already is, the problems of controlling that information will keep existing 📦 Rules also add complexity to managing a network, so they'll contribute to the information control problem too 🫠

2.1. IP QoS Management 🎯

Much of the current management effort is focused on solving control issues for IP QoS [3] 💖 There are a number of open questions about the IP QoS architecture, and those will make it hard to define a management architecture until they're resolved 🚧 They're well documented in "Next steps for the IP QoS architecture" [4], but from the management perspective, they're worth emphasizing 📣

Current IP QoS architectures haven't defined whether the service will be per-application or only a transport-layer option 🤔 That's a big deal, since it will significantly affect control, billing, and service assurance 💰

The assumption is that the routing best effort path will be used for both best effort traffic and traffic with a different service level 🛣️ On top of the issues raised in [4], best effort path routing may not be able to identify the parameters needed to find routes that can sustain distinguished service traffic 🕵️‍♀️

In any architecture where a premium service is offered, it's a strong requirement that the service be measurable and sustainable 💎 Provisioning that service requires a coherent view of the network, not just the device management view that's currently implemented in most networks 👀

2.2. Promise of rules-based Management 🌟

Management standardization efforts in the IP community have so far been mainly concerned with what's commonly called "element management" or "device management" [5] 🧸 There's general agreement about the scope of element management. Once you go outside that domain, though, dividing the task along clear boundaries has been really elusive 😵‍💫 A lot of the terms being used have roots in the telecommunications industry, so they may have limited use for IP management [1] 🫥 The ambiguity about which functions make up management beyond what's intended for the element gets worse because the broad scope of network and service management standards is so big 🌀 Terms like business goals, service management, and application management aren't defined well enough to make sure there won't be disagreement about the actual scope of the needed management functions, or about how far the interrelationships between them will extend 🙈

This hazy domain is where much of the recent work on rules-based management has been proposed as a potential solution 🫧 Developing a framework for policy management is one of the most popular recent activities 🔥 Proposed requirements for policy management look a lot like pre-existing network management requirements [2] 👯‍♀️ But the specific models needed to define policy itself, and to relate that definition to controlling DiffServ and RSVP based QoS, are still under development 🚧

2.3. Service Management Requirements 🎀

okay so figuring out the requirements for a service management system is lowkey hard, bestie, because network operators all have different needs 💅 Everyone's talking about convergence, and yet operators still have fundamentally different business needs. It's a whole thing 🙈

2.3.1. Enterprise 🏢

The management needs from both the operations side and the network side look kinda different in an enterprise than on a public network 👀 In an enterprise, end to end traffic management happens without the huge headache of complicated tariff issues. Service Level Agreements are showing up more and more in enterprises, but they don't hit operations as hard as they do on a public network. The high costs of running non-reputable auditing systems usually aren't there either 🙌 Result? The number of expressions needed to describe a particular network's business model drops a LOT. So iconic 💖

In a world of best effort service, rules-based management gives the IT department a tool to make the network appear not overloaded by prioritizing traffic ✨ You can prioritize delay sensitive traffic (web browsing) over traffic that isn't delay sensitive (email), or prioritize traffic from a particular location or source. Depending on the mix of an enterprise's traffic, this can stretch the useful life of the network without adding capacity 🌸 But it's not free, no cap. You have to count both the purchase and management costs of the system, plus the cost of the extra complexity from adding control information to the network 😭

2.3.2. Service Provider 🌍

Service providers have wanted a centralized management system for ages 🧚 The motivation is super straightforward, but there are some real obstacles. Service providers often don't want to be tied to one vendor, and they definitely don't want to be stuck with just one model of any single vendor's equipment 🙅‍♀️ Meanwhile bottom line costs matter most, which often leaves networks less heterogeneous than operators would like. Centralized management means a scalable system that can manage potentially many heterogeneous pieces of equipment. The amount of data needed to pull that off works against the scalability requirement, which is so frustrating 😩 People have tried again and again to find the common model that covers the subset shared by all devices. Unfortunately that set is usually either too complex (raising the cost of devices) or too limited, so you end up needing tons of device-specific data and the whole point is gone 💀 For a management model to work at the service level, the services being modeled have to be standardized. That's counterintuitive, since service providers compete with each other 🥊 Speed to market has become the key thing that sets one service provider apart from another ⭐ Constraints that a centralized management system puts on equipment manufacturers and the management infrastructure hurt that goal too. For a limited set of well-defined services, a central approach is feasible, but it can very quickly become a major contributor to the very problems it was supposed to solve 🫠

  1. Network and Service Management 🦋

Lots of efforts to define a management framework are described in very implementation-independent terms. Honestly though, how the framework is implemented directly affects which situations the management system will actually help 💅 Plenty of past attempts at a common management framework have failed, but service management might be the area where these efforts finally get industry acceptance 🎉 It may also be in service management that information models can be defined specific enough to be useful, without hurting the business needs of equipment or service providers 🧁

This section talks about some issues that need to be sorted out for a service management framework to meet the requirements of the modern IP network 🌈

Some of the key concerns when 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 are made of network elements that existed before anyone tried to define a standard information model, rules-based or otherwise, plus elements deployed afterwards 🕰️ Policy management efforts have looked at this problem. Elements that take policy into account are called policy aware, and those that don't are called policy unaware 👀 The distinction is that aware devices can interpret the policy information model or schema. The same issues apply to other standard management information too. Realistically, no device will stay fully policy aware for long. As the policy information model evolves, early devices will only be policy aware for the parts of the model that existed when they were built 😩 Handling revision and evolution is the key to success for any management framework, and there are a few ways to do it. One is designing the information models so they can be extended but still be practically used in their original form. A second is providing an adaptation or proxy layer. Each has pros and cons 💅

Methods that try to extend the original model often box themselves in way too much. When the existing model can't be extended, new branches have to be formed in the model that contain core management functionality 🌳

Adaptation methods can cause performance and scalability problems, and they add complexity to the network by creating extra network elements 🙃 A similar situation comes up if the management framework is so flexible that network elements can store information locally or choose to have it stored remotely. From a device perspective, the questions are whether the device can afford the logic based on its other requirements, and whether the information can be retrieved in a way that supports the performance and scalability requirements for that information 🤔 There's a dichotomy here: some information, for performance and scalability reasons, will be transferred directly to the network elements in some situations, and in other situations it will live in the management plan. IP management efforts have left the level of detail needed to define where the management information actually lives up to the implementation 🫣 For a service management framework to get the results it needs, it may be necessary to provide a more complete framework, along the lines of the detail in the ITU-T telecommunications management network efforts, where the interfaces and the functionality across them are clearly defined 📐

Information will need to exist in multiple locations at once in any network architecture. As the quantity and complexity of that information grows, limitations pop up fast 🚧 Changes to the information may also need to be propagated in close to real time, which adds even more complication ⏱️

3.1.1. Rules-based Management 📜

A network management framework can be split into two essential functions 💖 The first deals with managing the management information, and the second deals with 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, instead of device-specific management information 🎯 Lots of the information management requirements from traditional management systems still apply in a rules-based environment. The network is made of specific devices, and it's at the point where rules get conveyed as device-specific management information that this approach hits some of its biggest challenges 😤 A key part of a solution will be a generic information model that rules can be applied to, plus a framework architecture for distributing rules throughout the network. Finding the right generic model, one that isn't too much of a burden to implement but still gives enough detail to manage a network, has historically been extremely difficult 😭 In many ways, how well rules-based management solves management problems depends on whether efforts to define a generic model succeed and that model gets widely implemented [1] 🌟

One concept often discussed alongside policy is integrating legacy devices into the policy framework. The idea is that legacy devices would take part in policy decisions by having policy information translated into their native management interface 🔄 For this to work, a device would have to support the functionality the policy is specified for. That would limit this approach to only the information logically abstracted to the device's native interface 🙃 Since existing standard management interfaces don't support that kind of functionality, all such devices would need a proprietary interface implemented. An interface built on the one the device already supports might not have the scaling capabilities a policy management system needs 📉 Unlike a standard network management interface, where 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 a rules-based management system with existing network devices isn't readily apparent, and further study is needed 🔍 The problem gets worse when you consider that there will be early policy aware devices that may stop being aware as the policy models are extended 😵 Partially policy aware devices may create additional architectural issues, since it may not be possible to expect consistency in which aspects of policy a given device implements, unless there are formal sets of mandatory functionality with clear evolution paths 📋 It is paramount that the policy management framework be able to evolve to accommodate the ever-increasing number of services likely to be supported by IP networks of the future, so an evolution path has to be built into the framework 🚀✨

3.2. Policy Protocol

okay so this is where it gets spicy 🌶️✨ A policy-aware element is only doing its job when it's running a certain 'service', and here's the tea: not every element needs to know about every service policy at every moment. 💅 So it's honestly lowkey smart for an element to only care about a service policy when it's actually needed for that service at that instant 🫶

Now, networks are chaotic bestie. Elements and links go up and down all the time 😭 which is why a notion of a 'policy protocol' might become necessary. It's the idea of a 'policy protocol' running in a multi-service network that needs multi-service policies, and it's giving main character energy 👑

Picture this: two end nodes with multiple routing paths between them 🦋 Let's say one path is carrying a certain service based on some Intserv bandwidth reservation technique. The elements along that path have element-specific policy statements configured on them to support that requirement 🌸 Now, if at any moment a link or an element on that path becomes unavailable, the 'policy protocol' should be initiated to automatically configure the same service-policies on the elements along another routed path connecting the very same end points 🧚 That way there's no disruption in service and no human or operator intervention is required. iconic, honestly 💖

Associating a policy with its policy target is an area where considerable study may need to be done ✨ Some open questions: does this need to be done explicitly, or can the policy be written so that a common description of the target is also included? And could a policy target retrieve the policies that are relevant to it? Big brain stuff 🧠🎀

4. Conclusions ✨

Understanding the set of problems facing IP network management in general is going to be key to defining a comprehensive framework architecture that meets the needs of operators 💅 Applying new management techniques to the management of IP networks creates additional risks 😬 The consequences of implementing management operations on architectures that may not be compatible with existing management systems will still need to be explored 🔍

Since many network devices in IP networks make 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 experience the same fate as previous efforts 🙈

As IP continues to extend its concept of service beyond best effort, to include (among other things) differentiated treatment of packets, it will become increasingly necessary to have mechanisms capable of supporting these extensions 🚀 Defining a common management model and framework has historically been elusive 😭 Information models, whether 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 equipment vendors' acceptance of this approach 🙄

As IP continues to extend its concept of service beyond best effort, to include (among other things) differentiated treatment of packets, it will become increasingly necessary to have mechanisms capable of supporting these extensions ✨

5. Security Considerations 🔐

🚨 bestie, this is the serious part, so listen up 🚨

The exchange of management information in a network is one of the most sensitive things from a security perspective 😱 Management protocols must address security to ensure the integrity of the data 🫶 A management architecture must provide for security considerations from its inception, to ensure the authenticity of the information provider, and the security mechanisms must not be so cumbersome that they're not feasible to implement 💀 No cap, security that nobody can actually deploy is basically security theatre 🎭

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

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 🫶

📦 where this page comes from