RFC 3387

RFC 3387: Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network 🎀

Okay bestie, here's the header rundown. This is an Informational doc from the Network Working Group, so it's not a standard, just a useful read 📖. It was written by M. Eder, H. Chaskar, and S. Nag, all from Nokia 💼. It's dated September 2002 🍓. It doesn't obsolete anything and doesn't update anything either. It's its own thing 💅

Status of This Memo 📜

This memo is for information only, so the Internet community can read it 💜. It doesn't specify an Internet standard of any kind, so don't treat it as one! Distribution is unlimited, so share it with everyone 🫶

Copyright Notice 🔒

Copyright (C) The Internet Society (2002). All Rights Reserved. The Internet Society owns it, obviously 🌈

Abstract 🌸

Okay so the original design of IP management was built on two big ideas: simplicity, and no centralized control ✨. Best effort service basically came out of those management principles, and it worked the other way around too 🦋. People are now working on new ways to give one set of packets or flows different treatment than another, which is so exciting 🔥. BUT, as IP networks grow, the old management style might not fit the QoS-capable network some folks are dreaming about for later 🌙. This doc looks at some of the areas QoS is likely to affect when it comes to management, and raises some questions that still need answers 💭

1. Introduction ✨

Simplicity above all else was one of the main guiding principles when IP networks were designed 🎀. Still, as IP networks evolve, the idea of what a "service" even means in IP is evolving too 🦋. The old strategies might not work for the full-service QoS-capable network that some people imagine for the future 🔮. In the IP community there's a lot of push for the idea that if IP is going to live up to its promise, networks will need to offer a bigger variety of services 👑. Defining those new services has made it clear we have to rethink the control mechanisms IP networks currently use 😭. People are working hard on ways to give one set of packets or flows different treatment from another, but a lot of the support functions needed to actually use those mechanisms are pretty limited, and a complete framework doesn't exist yet 💀. It gets messier because many of these new services will probably need a billing framework alongside the control one, which is totally new territory for IP 💅

This doc is here to look at the network and service management issues that need to be sorted out if future IP networks are going to offer more than just traditional best effort service in any meaningful way 🧚

2. Background 📚

Defining a management framework for QoS is going to be hard, ngl 😩. That's because QoS is a huge break from the best effort model that sat at the core of IP from the beginning, which had a clear design strategy where simplicity came before everything else [1]. You can really see that philosophy in the network and service management area for IP [2]. Changes to support a range of QoS features would shake up the existing control structure in a very dramatic way 💥. Making it worse is that nobody really agrees on what makes up a "service" in IP [3]. Unlike some other network technologies, in IP it isn't enough to limit service management to end-to-end connectivity. The transport service offered to packets, and the way that transport gets used, have to be covered too 👀. QoS management is a subset of the broader service management, so if you want to solve the QoS management problem, it helps to understand the issues and limits of the bigger service management problem first 🫶. QoS can't be treated as its own standalone thing, and its management requirements will come from the higher-level service requirements in general 💜. If the transport services available in IP expand, then what counts as a service expands too 🌈. Just look at how the WEB is now de-facto part of the IP service scope, which is wild considering the WEB didn't even exist when IP was first invented 🤯. This is likely to keep happening as network decision points move toward the edge of the network, closer to applications and customers 🦋

There's also an ongoing argument about whether IP networks need QoS at all 🙈. New technologies based on fiber and wavelength-division multiplexing have a lot of people convinced that bandwidth will get so cheap that an explicit control framework for QoS differentiation won't be needed 💸. Engineering a network for peak usage is uneconomical, sure, but a major part of this debate is the cost of developing operational support systems for a QoS network and deploying them into existing networks 🛠️. Just because customers might be willing to pay for extra service doesn't mean it's a good reason to make sweeping architectural changes that could seriously affect the Internet as we know it today 😬. The IP community has to be really concerned that the equality that defined the best effort Internet might get sacrificed for a service with a completely different business model 😤. If the core network started offering services that made more revenue, it could easily come at the expense of the less revenue-generating best effort service 💔

5. IP Service Management: Problem Statement ✨

Okay bestie, before we can design the Service Management Framework for IP, we have to figure out what kinds of services actually need managing 💅. A network management framework usually has two halves: an informational framework (the info about everything) and a distribution framework (getting that info to the network devices). The distribution side has to support the informational side, which is the straightforward part. But there are sneakier relationships too, because what each side implies about managing the system matters. The informational side looks like the easier problem, and it's the one the IP community is mostly focused on right now 🧚.

Efforts like the DMTF CIM are trying to define network information models and, to a lesser extent, service information models 🌸. Honestly these look a LOT like what the telecommunications industry did to define its information models [7]. What hasn't shown up yet is a standard for how the information in those models gets used to manage a network 😭.

There are going to be so many elements to manage that this information has to be highly distributed 🫶. Highly distributed directories are a great fit for static information. Dynamic information is way messier, and it still hasn't been satisfactorily addressed. Policy management is the logical extension once distributed directory services are available in the network, and the IETF and DMTF want policy to be the framework that handles certain service management issues. Most of the current policy work focuses on access and traffic prioritization inside one particular network element, and only for a single administrative domain [8]. Classifying traffic flows and enforcing policy at the edge, focused on admission, without addressing the end-to-end nature of the problem leaves some of the most complex QoS management issues unanswered 💀. Providing a verifiable commodity level of service in IP will affect every facet of the network, so a management solution has to handle both the scale and the dynamics of how the network operates ✨.

---

5.1 Common Management Domain 🌈

Standardization efforts need to focus on management problems that span multiple domains. The test for "multi-domain" usually comes down to a many-to-one or one-to-many relationship that needs two or more distinct entities to be involved. Domains could be administrative domains or routing domains, or they could include agreements between domains 🦋. Unlike the telecommunications network, where traffic only crosses a relatively small number of domains, traffic in IP networks is likely to cross numerous domains under separate administrative control. It gets even more complicated because, unlike telecom, many of these domains will be highly competitive, offering and accepting different service level agreements 👑.

In telecom, traffic goes from the access provider's network to a core network and then, for an international call, across international boundaries. Compared with IP, the number of domains is small, the service in each one is virtually identical, and yet each domain probably has a different business model from the others. IP is the opposite: it will have many domains, many services, and domains that are highly competitive 😤. To succeed, IP will need to model the domain problem in a way that reduces the complexity that comes from having many independent networks, each with a different service model, responsible for a single flow.

Addressing service management across domains that compete directly with each other is also tricky, because a solution must not expose too much information about the capabilities of one domain's network to its competitor 🙈. Solutions may need a 3rd party that both sides trust to provide the management functions they need, while making sure sensitive information doesn't pass from one to the other 🔐.

5.2 Service Management Business Processes 💼

A service management framework has to address the business processes that run when a service is provided. A service can be split into two fundamental parts: the definition of the service, and the embodiment of the service 🍓. This split might seem obvious, but a formal process that covers both of these aspects needs to be in place if managing the service is actually going to happen.

When you specify a service, it must be possible to map it onto the capabilities of the underlying network architecture. The service needs to be specified unambiguously so that mechanisms can be put in place to control it. It can help to think of the relationship between a service definition and a service instance the same way you'd think about an object definition and its instantiation in object-oriented modeling 🧩. As networks evolve, it will be necessary to describe the network capabilities to the service in a logical way. Because IP networks are so fragmented, specific service classifications will need to be available that transcend individual regions and domains. An interface that defines and controls the network capabilities, abstracted from the service perspective, lets service management systems administer the network ⭐.

Services are often designed with management capabilities of their own. These services have tended not to rely on the service aspects of the network, only on its transport capabilities. As services become more dependent on the network, management over a shared framework will be required 💖. Operators have recognized the business need to let users have as much control over the management of their own services as possible. IP services will be highly diverse and customizable, which makes it even more necessary for service management to be made available to the user as far as possible 🎀.

In an IP environment, there may be many separate entities required to provide a service, and that will create a significant management challenge 😵‍💫.

5.3 Billing and Security 💸

Paramount to the success of any service is figuring out how that service will be billed 💰. The billing process must be defined at the very start of the service, and that's where the network support needed for billing should be addressed. Security is the same deal: it must also be addressed in the earliest stages of defining the service 🔒. It isn't practical to assume that the billing and security services will be hosted by the same provider as the service itself, or that it will be possible to design billing and security functions specifically for every service. These functions will have to be a generic part of the network 🫧.

5.4 Standards 📚

Given the limited success of telecommunications standards bodies in formalizing the relationships between different management support functions, it's highly suspect that similar efforts would succeed in IP networks, which have an even more diverse concept of network and services 🫠. If the IP network is going to be made up of peer domains of equal dominion, it will be necessary to have management functionality that can traverse those domains. Where management responsibility lies depends a lot on the reference point. From a centric vantage point, responsibility is shared equally among the different domains. From within any particular domain, management responsibility exists within that domain and that domain only 🏰. For a management framework to succeed in IP networks, logical management functions will have to be identified, along with an extremely flexible definition language to define the interface to those functions. The more management functionality has to cross boundaries of responsibility, the more the network management functions have to be distributed throughout the network 🌸.

5.5 Core Inter-domain Functions ✨

okay so this one is about the business side of IP, and it's giving "who pays whom and who gets the good lanes" 💅 Right now, if services need to work across different domains, the providers have to negotiate their service level agreements (SLAs) one by one. 🙈 That's fine for a few deals, but once the number of agreements gets huge, or they all look totally different from each other, it turns into a complete mess. At that point some kind of standardization is going to be needed to keep these agreements under control. 💜

Bandwidth Brokers were thought up as a way to handle a lot of the between-domain traffic problems from a business angle. The whole idea is to make sure the network domains agree on the traffic. Security and billing also need attention, even though those are way harder to put a number on. 📊

Here's the tea: service providers have historically been pretty reluctant to use bandwidth brokers or SLA-style tools. 😬 They're scared these tools will show competitors and customers exactly where they're weak. Honestly, that's not a technical problem, but it's a very real practical one when you're trying to run a service well. 🫠

Looking ahead at what the QoS network of the future needs, two opposite philosophies show up. 🦋 Network providers want more control over traffic so they can pick what gets priority, especially when things get congested. Users, on the other hand, want to be able to find a path that acts a lot like a leased line [9]. 🎀 Either way, once IP bandwidth stops being handed out equally and starts being delivered according to complex formulas, there's going to be a bigger need for authentication and validation. ✨ That's how you prove who gets which service and that they actually paid for it. It also includes being able to measure that the service being promised is really being delivered, pinning down the exact parameters of the service, and checking that nobody is getting a higher level of service than they're authorized for. 🔥

Some earlier work on an architectural framework for mixed traffic networks suggested that bilateral agreements would be the only thing that works between administrative domains [10]. 🧚 Multilateral agreements are definitely complicated to manage, ngl. But bilateral agreements don't scale well, and if traffic has to cross lots of administrative domains, it gets really hard to quantify the end-to-end service being delivered. 😭 And if domains keep changing hands or being run differently, that instability makes bilateral agreements even less useful for predicting end-to-end service. 🌸

As IP keeps converging toward being all IP, it's going to be super interesting to see how existing telecommunications regulations affect IP networks, especially as more regulated traffic moves over them. 🌈 Regulation has been used in telecom to open up the network, but the results have been mixed. 🤷‍♀️ A regulated process might cancel out the effects that competitive pressure has on bilateral agreements and make a truly open environment possible. But it could also backfire and do the exact opposite. 💀 Honestly, the answer to this might not be the best technical solution. It might just be the most politically acceptable one. 👑

If traffic agreements at network boundaries aren't standardized, we'll keep seeing network providers consolidate. ⭐ Providers that can't convince other providers to pair up with them may not be able to compete once QoS networks become commonplace. 🥺 This would hit small and midsize service providers the hardest. They'd feel pressure to merge with a larger provider or else risk not being able to offer the highest levels of service. 💔 And if this all plays out across international boundaries, it's really hard to predict where it ends up. 🌍

5.6 Network Services 💖

Most of the current work on higher-level management functions for IP networks has been focused on providing QoS. 🎀 Lots of service issues are still unresolved for the current best effort paradigm, and even more will show up if true QoS support actually happens. 😩 Authentication, authorization, and accounting services that are already inadequate for today's best effort service will need extra work before they can support QoS services. 🔐

It's reasonable to split services into application level services and transport level services. 🧩 Transport services are the ones the network provides no matter what application is running. These include things like Packet Forwarding and Routing, QoS differentiation, Traffic Engineering, and so on. They might also include functions like security (Ipsec) and Directory services. In IP networks, people often separate QoS transport services into end-to-end ones (RSVP) and per-hop ones (Diffserv). From a management perspective, though, the two look very similar. 🦋 Transport level services aren't very flexible, so applications have to squeeze themselves into the transport framework. 💅 An application that needs extra transport level services has to be a mass-market app, because only then can the investment in new infrastructure be justified. And since changing transport services takes so much effort, applications that need new ones will have a longer time to market. Don't underestimate how much effort and cost it takes to build the framework needed to support new transport services! 😭

Application level services are the ones specific to the application. A lot of service management happens between the application supplier and the application consumer, and none of it needs the existing network to know or support anything. 🌷 Keeping service management at this level can greatly reduce time to market and costs. ✨ The downside is that lots of applications end up needing the same functionality, which leads to inefficient use of network resources. 🙃 Services supplied by the network can be built more robustly and can offer extra functionality, because they can access information that applications can't. 🧠 That gives them extra benefit over application level services. A good example of an application level service that could benefit from a network service is the AAA paradigm for Web based E-Commerce, which is mostly limited to users typing in their credit card info. 💳 Sometimes application level service requirements end up with the downsides of both transport services and application services. 😬 For instance, in IP telephony this might include services provided by a gateway or another network device built specifically for IP telephony, to support things like call forwarding or call waiting. 📞 IP telephony has such mass appeal that it's possible to suggest major infrastructure changes, but the nature of those changes has slowed down how far IP telephony applications have spread. 🐢

---

6. The Way to a QoS Management Architecture 👑

An overview of some of the problems from the previous sections makes it clear that we need a consolidated framework. 🧚‍♀️ Transport level QoS will demand traffic engineering that can see the whole network in much more depth than what the Routing protocols currently provide. 🗺️ That view has to include dynamic network congestion information as well as connectivity information. 📡 The current best-effort transport control may turn into more of a hindrance for new services, and it may be of questionable value if the IP network truly becomes a full service QoS network. 🤔 Both IntServ and DiffServ QoS schemes need network provisioning to properly support QoS within a particular domain, plus agreements for traffic that crosses domains. 🌉 Policy management, object oriented information models, and domain gateways are pushing toward a more centralized management structure that provides full service across domains and throughout the entire network. 🌟 Given how costly and complicated a system like that would probably be, failing to come up with a standard, even a de facto one, would have serious implications for the future of the Internet. 🚨💖

6.1. Point to Point QoS

okay so for the current QoS trends to actually succeed 💅, the new control structures and the existing ones have to be harmonized, no cap 🫶. The move is to use something very similar to the existing routing control structures ✨. That way you could build functionality that is not in the data path, which allocates traffic within a domain and uses inter-domain signaling to distribute it between domains 🦋. QoS-like authorization and authentication for edge devices admitting QoS traffic, plus administering and allocating traffic between administrative domains, could also be supported 🔥. While it meets the requirements for a bandwidth broker network element [10], it could also handle more general policy decisions and QoS routing 👑. These tasks are all interrelated, so it makes sense to integrate them if possible 💖.

The new service architecture must allocate traffic within a particular administrative domain and signal traffic requirements across domains, and while it's doing that it still has to be compatible with the current way traffic gets routed 😭. One way to pull this off is to redirect routing messages to a central function, which then calculates paths based on the entire network transport requirements 🧚. Across domains, communication happens as needed to establish and maintain service levels at the gateways 🌸. At the edges, devices would feed traffic information to billing interfaces and verify that the agreed service level is actually being provided 💅. For scalability, any central function would need to be distributable in large networks 🌈. Routing messages very similar in content to the existing ones would carry enough info to support the traffic engineering requirements, without changing the basic forwarding functions of the devices ⭐. Having routes computed centrally would simplify network devices, since they wouldn't have to do computationally intensive routing tasks 🫶.

Given the number of flows going through the network, the core cannot know about individual flow states [11] 💀. At the same time, it isn't practical to expect edge devices to determine paths that will optimally use network resources 🙈. The info needed to forward traffic is becoming tied to complex parameters that can't be determined on a per hop basis and have nothing to do with forwarding packets, which is what routers do best 🎀. So it might make sense to move route determination to network components designed specifically for the job 🍓. In a QoS network, routing decisions will depend more and more on info that isn't easily discernible from the data, the kind of info routers could logically share with each other 🧠. That means additional functionality will be needed to determine how data gets routed through the network, and it further suggests that all the info a router needs to forward packets might not be better provided by a network element outside the packet forwarding functions of the router 🔥.

At the network edges, where traffic gets admitted, there need to be mechanisms that make sure traffic stays within the bounds of what was specified 🛡️. To do this, input traffic has to be buffered and controlled 🫧. Second, the traffic would need to be marked so other network elements can tell it's preferred traffic without having to keep flow information 🏷️. Alternatively, a path could be chosen for the traffic that is dedicated to the level of service requested, which is per flow based 🛤️. A combination of the two would also be possible, allowing a reservation of resources that accommodates multiple flows 🌟. Both methods are similar from a management perspective, and they're really identical when it comes to route determination, which could be done centrally. One method is just a virtual path based on how the device handles packets in the network, and the other is a pre-reserved path through the network 🦋. Existing best effort routing won't provide optimum routes for these new levels of service. To get them, you'd need either routing protocols that support optimum path discovery or mechanisms to configure the paths needed for the required services 🧭. Beyond specific service parameters, reliability will also be a potential service discriminator 🔐. With traditional path determination methods, it's unlikely that a new path could be found quickly enough after a failure to maintain the agreed service level 😬. That could mean multiple path reservations in some cases 👯. Per flow reservations are too resource intensive, so virtual trunks would be a good way to cut down on management traffic by reserving blocks of capacity, and they'd provide stability when the resource reservation and route selection functions fail 🚂.

Shaping at network boundaries comes with its own implications 🎢. Shaping would include both rate and burst parameters, as well as possible delay aspects 📏. Having to provision services with specific service parameters would cause both major business and technical problems 💼. By definition, packet data is bursty, and there are idle periods during a session that a provider could reasonably hope to exploit to make better use of network resources 😴. It's not practical to expect that a consumer paying a premium for a service wouldn't check that the service was really available 🧐. That service model looks full of peril for the existing best effort Internet, because any significant amount of bandwidth reserved for exclusive use or for a high priority flow would be unavailable to best effort data 😱.

Within the network itself, there will need to be pre-configured routes, and there also needs to be the ability for routes to be dynamically configured ⚙️. Some of the problems with pre-configured traffic include its basic inconsistency with how traffic is currently engineered across the Internet, and the difficulty of making arrangements between administrative domains 🙃. The current Internet was built around one of the most egalitarian yet simplistic ways of sharing bandwidth 🤝. Supporting existing best effort service in an unbiased way, while also providing other classes of service, could add a tremendous amount of complexity to the QoS scheme 🌀. On the flip side, if reserved bandwidth isn't shared, it could significantly affect how much bandwidth is available on the Internet as we know it today 📉. QoS could even contribute to bandwidth shortages, by reserving bandwidth in the network that other services can't use, even though that bandwidth will often be underutilized 🙄. Add in the motivation of service providers who want to sell commodity bandwidth, and the pressure on Internet bandwidth availability could be tremendous 🌋.

Current IP community work on defining QoS mechanisms has centered on a few particular architectures and a handful of new protocols 📚. The following sections look at some of the particular issues with the current IP community efforts, as they relate to the earlier discussion 🔍. This document isn't meant to be a tutorial on those efforts. Instead, it aims to identify some of the support issues tied to using particular technologies that provide some form of classifiable service within an IP network 🎓.

6.2. QoS Service Management Scope

You could limit a discussion of QoS management to just configuring a path between two endpoints 🛤️. Even within that limited scope, there are still lots of unresolved issues 🫠. There's no expectation that a QoS path for traffic between two points needs to be, or should be, the same in both directions ↔️. Since there will be an originator of the connection, there are questions about how billing and accounting will be settled if the return path is set up by a different provider than the one the originator uses 🧾. To make billing work, there will need to be a method that lets the application originating the call also pay for the return path, and also lets collect calls be made 📞. Third party providers will need to be set up, and every party in the data path has to trust them to ensure billing and guaranteed payment 🤝. Using a virtual DCN built on both IETF and non-IETF protocols, messages between service providers and the 3rd party verification system can be secured 🔐. A signaling protocol will be necessary to establish the cost of the call and who's paying for it, and each provider will need a verifiable way to bill for the service it provided 💸. As pointed out earlier, this is similar to what the existing telephone network does, but at a much larger scale, and it could involve providers that are highly competitive with each other 📱🔥.

7. The DiffServ Architecture ✨

okay so the DiffServ management problem is literally two pronged 💅. first there's the management inside each administrative domain that has to get handled, and then there's the management between the domains. and bestie, there's been pretty much no real work on the second part in the architecture 😭. what work there has been assumes that service level agreements will get reached between the administrative domains, and that end-to-end service will just be a concatenation of those various SLAs. this is problematic for many reasons 💀. it kinda presumes that agreements reached bilaterally could be chained together and still give an end-to-end level of service that a customer would be willing to pay a premium for. the problems we talked about earlier, with trying to maintain large numbers of these agreements between competitive networks, would also apply, and they tend to limit how effective this approach is. to efficiently establish the chain needed to get end to end service it might take an infinite number of iterations 🌀.

guaranteeing a class of service on a per hop basis is in no way a guarantee of the service on an end-to-end basis 🙅. it's not likely that a customer would be willing to pay for an improved level of service if it didn't include guarantees on the bandwidth and the quantitative bounds on delay and error rates guaranteed end-to-end. this would necessitate engineering the paths through the network so as to achieve a desired end-to-end result. it's very likely that an initial attempt at providing this kind of service will specify only a particular ingress and egress border, but for robustness and flexibility it'll be desirable to have a network that can support such service without those limitations 🦋. the Intserv approach, as opposed to the DiffServ architecture, would require per flow information in the core network and may as a result of this prove not to be scalable [11]. a DiffServ type architecture, with a limited number of service classes, could be pre-provisioned and, as network circumstances warranted, be modified to support the actual dynamics of the network ✨.

the high level functional requirements for edge routers have been pretty well defined in the DiffServ architecture, but the true scope of the effort to implement this functionality hasn't been well recognized 🙈. yes, there are interesting differences between the QoS architecture of the Internet and the circuit switched network used for telecommunications, but much of the lessons learned in telecommunications should, even if they might do little else, give some insight into the level of effort needed to implement these kinds of requirements 🧚. ironically, the Internet community has in the past rejected the level of standardization that was proposed for management of telecommunications networks, and yet it may be the full service internet where it becomes actually imperative that such requirements be completed if the desired services will ever be offered 👑.

8. A Summary of the QoS Functional Areas 🌸

the management of QoS will need to provide functionality to the application and/or at the access, at the core, and at the boundaries to administrative regions.

QoS traffic functions will need to include admission control, authentication and authorization, and billing. there also needs to be verification that traffic is within agreed parameters, plus programmatic interfaces to advise when the service is outside the agreed limits. interfaces that provide service verification, fault notification, and re-instantiation and termination will also be necessary 🎀.

core functions will include traffic engineering, network device configuration, fault detection, and recovery. network devices will need to inform the management system of their available resources, and the management system will need to tell devices how and where to forward data 🔥.

between administrative regions, accounting, service signaling, and service verification will be needed. at the administrative boundaries of the network, functions similar to those provided at the edge will be necessary. peer entities in different administrative domains would signal their needs across the boundary. verification at the boundary could then occur consistent with the verification at the edge. actual traffic through the boundaries could be measured, and billing information could be transferred between the domains. the central management function would be responsible for re-routing traffic in the event of a failure or to better utilize the existing network resources 🦋.

billing requirements suggest the need for 3rd party verification and validation functions available to each provider of QoS service within the flow. on one side of the transaction, functionality is needed to approve pricing and payment, and on the other side there will need to be an interface to provide the pricing information and make payment requests for payment demands 💅.

these requirements will raise a host of issues, not the least of which is security 😭. for the most part, security considerations will be addressed both by securing the protocols (like with IPsec) and by establishing a dedicated network for control information [6]. while it will in most instances be too costly to create a physically separated DCN, it will be possible to create a virtually separated network that provides the same security benefits 🔐. future work in the IRTF Service Management Research Group intends to look in detail at these requirements 🔮.

9. Security Considerations 🛡️

okay bestie, this part is SERIOUS 💀. for an issue as complex as a Service Management architecture, which interacts with protocols from other standards bodies as well as from the IETF, it seems necessary to keep the overall picture in mind while, at the same time, breaking out specific parts of the problem to be standardized in particular working groups. so a requirement that the overall Service Management architecture address security concerns does not necessarily mean that the security mechanisms will be developed in the IETF 🧩.

this document does not propose any new protocols, and therefore does not involve any security considerations in that sense. however, throughout this document, consideration of the security issues raised by the architectural discussions is addressed 🔒.

10. Summary 🌈

the paradigm for service management in IP networks has been adopted from that of telecommunications networks. basic differences between the service models of these networks call into question whether this is realistic. further analysis is needed to determine what the proper paradigm for IP service management is, and to define a common vocabulary for it 📚.

the IP community is currently very active in solving problems relating to transport QoS issues. these activities are illustrated by the work of the Diffserv, Intserv, and Policy working groups. in contrast, not enough effort is being focused on service issues relating to applications. the present solution is for applications to build in their own service management functionality. this is often an inefficient use of network resources, but more importantly, it will not provide for access to transport level services and the functionality that they offer 😤.

the IP community needs to focus on adding service functionality that is flexible enough to be molded to specific application needs, yet will have access to the service information that will be necessary to provide superior application functionality ⭐. the principal needs to be addressed relate to developing transport level services for billing and security. directory services and extending the work done to define AAA services are promising starting points for developing this needed functionality 💜.

11. References 📖

[1] L. Mathy, C. Edwards, and D. Hutchison, "The Internet: A Global Telecommunications Solution?", IEEE Network, July/August 2000.

[2] B. Leiner, et. al., "A Brief History of the Internet version 3.31", revised 4 Aug 2000.

[3] Eder, M. and S. Nag, "Service Management Architectures Issues and Review", RFC 3052, January 2001.

[4] Y. Bernet, "The Complementary Roles of RSVP and Differentiated Services in the Full-Service QoS Network", IEEE Communications Magazine, February 2000.

[5] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.

[6] Recommendation M.3010 "Principles for a telecommunications management network", ITU-T, February 2000.

[7] Recommendation M.3100 "Generic network information model", ITU-T, July 1995.

[8] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.

[9] V. Jacobson, "Differentiated Services for the Internet", Internet2 Joint Applications/Engineering QoS Workshop.

[10] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.

[11] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.

12. Authors' Addresses 📬

Michael Eder
Nokia Research Center
5 Wayside Road
Burlington,  MA  01803, USA

Phone: +1-781-993-3636
Fax:   +1-781-993-1907
EMail: Michael.eder@nokia.com


Sid Nag
PO Box 104
Holmdel, NJ 07733, USA

Phone: +1-732-687-1762
EMail: thinker@monmouth.com


Hemant Chaskar
Nokia Research Center
5 Wayside Road
Burlington,  MA  01803, USA

Phone: +1-781-993-3785
Fax:   +1-781-993-1907
EMail: hemant.chaskar@nokia.com

13. Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2002). 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.