diff options
Diffstat (limited to 'doc/rfc/rfc3387.txt')
| -rw-r--r-- | doc/rfc/rfc3387.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc3387.txt b/doc/rfc/rfc3387.txt new file mode 100644 index 0000000..2892aa9 --- /dev/null +++ b/doc/rfc/rfc3387.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group M. Eder +Request for Comments: 3387 H. Chaskar +Category: Informational Nokia + S. Nag + September 2002 + + + Considerations from the Service Management Research Group (SMRG) + on Quality of Service (QoS) in the IP Network + +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 (2002). All Rights Reserved. + +Abstract + + The guiding principles in the design of IP network management were + simplicity and no centralized control. The best effort service + paradigm was a result of the original management principles and the + other way around. New methods to distinguish the service given to + one set of packets or flows relative to another are well underway. + However, as IP networks evolve the management approach of the past + may not apply to the Quality of Service (QoS)-capable network + envisioned by some for the future. This document examines some of + the areas of impact that QoS is likely to have on management and look + at some questions that remain to be addressed. + +1. Introduction + + Simplicity above all else was one of the guiding principles in the + design of IP networks. However, as IP networks evolve, the concept + of service in IP is also evolving, and the strategies of the past may + not apply to the full-service QoS-capable network envisioned by some + for the future. Within the IP community, their exists a good deal of + impetus for the argument that if the promise of IP is to be + fulfilled, networks will need to offer an increasing variety of + services. The definition of these new services in IP has resulted in + a need for reassessment of the current control mechanism utilized by + IP networks. Efforts to provide mechanisms to distinguish the + service given to one set of packets or flows relative to another are + well underway, yet many of the support functions necessary to exploit + these mechanisms are limited in scope and a complete framework is + + + +Eder, et. al. Informational [Page 1] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + non-existent. This is complicated by the fact that many of these new + services will also demand some form of billing framework in addition + to a control one, something radically new for IP. + + This document intends to evaluate the network and service management + issues that will need to be addressed, if the IP networks of the + future are going to offer more than just the traditional best effort + service in any kind of significant way. + +2. Background + + The task of defining a management framework for QoS will be difficult + due to the fact that it represents a radical departure from the best + effort service model that was at the core of IP in the past, and had + a clear design strategy to have simplicity take precedence over + everything else [1]. This philosophy was nowhere more apparent than + in the network and service management area for IP [2]. Proposed + changes to support a variety of QoS features will impact the existing + control structure in a very dramatic way. Compounding the problem is + the lack of understanding of what makes up a "service" in IP [3]. + Unlike some other network technologies, in IP it does not suffice to + limit the scope of service management simply to end-to-end + connectivity, but the transport service offered to packets and the + way the transport is used must also be covered. QoS management is a + subset of the more general service management. In looking to solve + the QoS management problem it can be useful to understand some of the + issues and limitations of the service management problem. QoS can + not be treated as a standalone entity and will have its management + requirements driven by the general higher level service requirements. + If the available transport services in IP expand, the result will be + the further expansion of what is considered a service. The now + de-facto inclusion of WEB services in the scope of IP service, which + is remarkable given that the WEB did not even exist when IP was first + invented, illustrates this situation well. This phenomenon can be + expected to increase with the current trend towards moving network + decision points towards the boundary of the network and, as a result, + closer to the applications and customers. Additionally, the argument + continues over the need for QoS in IP networks at all. New + technologies based on fiber and wavelength-division multiplexing have + many people convinced that bandwidth will be so inexpensive it is not + going to be necessary to have an explicit control framework for + providing QoS differentiation. However uneconomical it is to + engineer a network for peak usage, a major argument in this debate + certainly is the cost of developing operational support systems for a + QoS network and deploying them in the existing networks. Just the + fact that customers might be willing to pay for additional service + may not be justification for implementing sweeping architectural + changes that could seriously affect the Internet as it is known + + + +Eder, et. al. Informational [Page 2] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + today. The IP community must be very concerned that the equality + that characterized the best effort Internet may be sacrificed in + favor of a service that has a completely different business model. + If the core network started to provide services that generated more + revenue, it could easily come at the expense of the less revenue + generating best effort service. + +3. IP Management Standardization + + Management standardization efforts in the IP community have + traditionally been concerned with what is commonly referred to as + "element management" or "device management". Recently, new efforts + in IP management have added the ability to address service issues and + to look at the network in more abstract terms. These efforts which + included a logical representation of services as well as the + representation of resources in the network, combined with the notion + of a user of a service, has made possible the much talked about + concept of 'policy'. Notable among these efforts are the Policy work + in the IETF and the DMTF work on CIM and DEN. Crucial elements of + the service management framework are coming into perspective, but + point to a trend in IP that is a quite radical departure from the + control mechanisms of the past. As the service model evolves from + being what was sufficient to support best effort to being able to + support variable levels of service, a trend towards a centralized + management architecture has become quite apparent. + + This is becoming increasingly apparent for two reasons. QoS + mechanisms need network wide information [4], and for them to + succeed, they must not require a tremendous amount of support from + the core network. It is becoming increasingly accepted that only at + the edge of the network will there be sufficient resources to provide + the mechanisms necessary to admit and control various QoS flows. + + A question often asked these days is if "the architectural benefits + of providing services in the middle of the network outweigh the + architectural costs"[5]. This same question should be asked of + service management. As new network elements are needed to support + service management, even if they are not contributing directly to the + forwarding of packets, the cost both in the increased complexity and + the possibility of destabilizing the networks needs to be considered. + An analyses of this issue will be made by the SMRG when we start to + look more in detail at some of the issues raised in this survey + document. + + + + + + + + +Eder, et. al. Informational [Page 3] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + +4. Telecommunications Service Management + + One place to start an effort to define service management in IP + networks is by looking at what has been done previously in + telecommunications networks. The telecommunications standards for a + service management framework have not received wide scale acceptance + even in an environment in which the service is fairly constrained. + Many proprietary protocols still dominate in the market even though + regulation has made it necessary for network operators to open their + networks sufficiently to allow for multiple vendor participation in + providing the service. This indicates that some formalized + boundaries exist or the markets are sufficiently large to justify the + development of interfaces. International telecommunications + management standards look at the complete management problem by + dividing it into separate but highly related layers. Much of the + terminology used to describe the management problem in IP has + diffused from the telecommunications standards [6]. These standards + were designed specifically to address telecommunications networks and + services, and it is not clear how applicable they will be to IP + networks. Service management is defined in terms of the set of + services found in telecommunications networks and the management + framework reflects the hierarchical centralized control structure of + these networks. The framework for service management is based on the + Telecommunications Management Network (TMN) layered approach to + management. Current IP standards are heavily weighted towards the + element management layer and especially towards the gathering of + statistical data with a decentralized approach being emphasized. In + the TMN architecture a dependency exists between layers and clear + interfaces at the boundaries are defined. To what extent service + management, as defined in the TMN standards, can be applied to IP + where there would likely be resistance to a requirement to have + formalized interfaces between layers [6] must be further + investigated. + + TMN concepts must be applied carefully to IP networks because + fundamental differences exist. Control of IP networks is highly + distributed especially in the network layer. Management is non- + hierarchical and decentralized with many peer-to-peer relationships. + A formal division of management into layers, where management + dependencies exist at the borders of these layers, may not be + applicable to IP. Any effort to define service management in IP must + be constantly vigilant that it does not assume the telecommunications + concepts can be applied directly to IP networks. The most basic + abstraction of the network management problem into element, network, + and service management has its origins in the telecommunications + industry's standardization work and the IP management framework might + not have made even these distinctions if it where not for the + telecommunications legacy. + + + +Eder, et. al. Informational [Page 4] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + +5. IP Service Management: Problem Statement + + In defining the Service Management Framework for IP, the nature of + services that are going to need to be managed must be addressed. + Traditionally network management frameworks consist of two parts, an + informational framework and the framework to distribute information + to the network devices. A very straight forward relationship exists + in that the distribution framework must support the informational + one, but also more subtle relationships exists with what the + informational and distribution frameworks imply about the management + of the system. The informational framework appears to be the easier + problem to address and the one that is principally being focused on + by the IP community. + + Efforts like the DMTF CIM are currently trying to define network, and + to a lesser extent service, information models. These efforts show a + surprising similarity to those of the telecommunications industry to + define information models [7]. What has not emerged is a standard + for defining how the information contained in the models is to be + used to manage a network. + + The number of elements to be managed in these networks will require + this information to be highly distributed. Highly distributed + directories would be a prime candidate for the information that is of + a static nature. For information that is of a dynamic nature the + problem becomes far more complex and has yet to be satisfactorily + addressed. Policy management is a logical extension of having + distributed directories services available in the network. The IETF + and DMTF are looking to Policy management to be a framework to handle + certain service management issues. Much of the current policy + efforts are focused on access and traffic prioritization within a + particular network element and only for a single administrative + domain [8]. Classifying traffic flows and enforcing policies at the + edge with the intent of focusing on admission issues, without + addressing the end-to-end nature of the problem, leaves some of the + most complex QoS management issues still unanswered. Providing a + verifiable commodity level of service, in IP, will effect every facet + of the network and a management solution to the problem will have to + address the scale and the dynamics by which it operates. + +5.1 Common Management Domain + + Standardization efforts need to concentrate on the management + problems that are multi-domain in character. The test for multi- + domain often centers around there being a many-to-one or a one-to- + many relationship requiring the involvement of two or more distinct + entities. Domains could reflect the administrative domain, routing + domain, or include agreements between domains. Unlike the + + + +Eder, et. al. Informational [Page 5] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + telecommunications network in which traffic traverses only a + relatively small number of domains, traffic in IP networks is likely + to traverse numerous domains under separate administrative control. + Further complicating the situation is, that unlike the + telecommunications network, many of these domains will be highly + competitive in nature, offering and accommodating varying service + level agreements. Telecommunications traffic, even with + deregulation, passes from the access providers network to a core + network and then, if it is an international call, across + international boundaries. The number of domains is relative to IP + small, the service supported in each is virtually identical, and yet + each domains is likely to have a different business model from the + other. In contrast IP will have many domains, many services, and + domains will likely be highly competitive. To be successful IP will + need to model the domain problem in a way that reduces the complexity + that arises from having many independent networks each having a + different service model being responsible for a single flow. + Addressing service management issues across domains that are direct + competitors of each other will also complicate the process because a + solution must not expose too much information about the capabilities + of one domains network to the competitor. Solutions may require a + 3rd party trusted by both to provide the needed management functions + while at the same time insuring that sensitive information does not + pass from one to the other. + +5.2 Service Management Business Processes + + A service management framework must address the business processes + that operate when providing a service. A service can be separated + into two fundamental divisions. The first is the definition of the + service and the second is the embodiment of the service. While this + division may seem intuitive, a formal process that addresses these + two aspects of a service needs to be in place if management of the + service is to be actually realized. + + In specifying a service it must be possible to map it onto the + capabilities of the underlying network architecture. The service + needs to be specified in an unambiguous way so that mechanisms can be + put in place to enable the control of the service. It can be a + useful tool to view the relationship of the definition of a service + to an instance of that service to the relationship between the + definition of an object to the instantiation of that object in object + oriented modeling. As networks evolve it is going to be necessary to + logically describe the network capabilities to the service and + because IP networks are so fragmented specific service + classifications will need to be made available that transcend the + individual regions and domains. An interface that defines and + + + + +Eder, et. al. Informational [Page 6] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + controls the network capabilities, abstracted for the service + perspective, allows for the administration of the network by the + service management systems. + + Services are often designed with management capabilities specific to + them. These services have tended to not rely on the service aspects + of the network, but 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 allow the user to have as much control over the management of + their own services as possible. IP services will be highly diverse + and customizable further necessitating that the management of the + service be made available to the user to the extent possible. + + In the IP environment where they may be many separate entities + required to provide the service this will create a significant + management challenge. + +5.3 Billing and Security + + Paramount to the success of any service is determining how that + service will be billed. The process by which billing will take place + must be defined at the service inception. It is here that the + network support necessary for billing should be addressed. + Analogously, security must also be addressed in the most early stages + of the service definition. It is not practical to assume that the + billing and the security services will be hosted by the same provider + as the service itself or that it will be possible to have the billing + and security functions specifically designed for every service. + These functions will have to be a generic part of the network. + +5.4 Standards + + Given the limited success of the telecommunications standards bodies + efforts to formalize the relationship between different management + support functions it is highly suspect that such efforts would + succeed in IP networks which have an even more diverse concept of + network and services. If the IP network is to be made up of peer + domains of equal dominion it will be necessary to have management + functionality that is able to traverse these domains. Of course the + perspective of where management responsibility lies is largely + dependent on the reference point. A centric vantage point indicates + responsibility shared equally among 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 these management functions. The more the + + + +Eder, et. al. Informational [Page 7] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + management functionality will have to cross boundaries of + responsibility, the more the network management functions have to be + distributed throughout the network. + +5.5 Core Inter-domain Functions + + The service management paradigm for IP must address management from a + perspective that is a combination of technical solutions as well as a + formula for representing vendor business relationships. Currently + services that need support between domains require that the service + level agreements (SLAs) be negotiated between the providers. At some + point these agreements will likely become unmanageable, if the number + of agreements becomes very large and/or the nature of the agreements + is highly variable. This will result in there being sufficient need + for some form of standardization to control these agreements. + + Bandwidth Brokers have been conceived as a method for dealing with + many of the problems between the domains relating to traffic from a + business perspective. The premise of the Bandwidth Brokers is to + insure agreement between the network domains with regards to traffic, + but security and billing issues, that are not likely to be as + quantifiable, will also need to be addressed. Service providers have + traditionally been reluctant to use bandwidth broker or SLA types of + functions as they fear such tools expose their weaknesses to + competitors and customers. While this is not a technical problem, it + does pose a real practical problem in managing a service effectively. + Looking at the basic requirements of the QoS network of the future + two competing philosophies become apparent. The network providers + are interested in having more control over the traffic to allow them + to choose what traffic gets priority especially in a congested + environment. Users desire the ability to identify a path that has + the characteristics very similar to a leased line [9]. In either + situation as IP bandwidth goes from being delivered on an equal + basis, to being delivered based on complex formulas, there will + become an increasing need to provide authentication and validation to + verify who gets what service and that they pay for it. This will + include the ability to measure that the service specified is being + provided, to define the exact parameters of the service, and to + verify that only an authorized level of service is being provided. + + Some of the earlier work on an architectural framework for mixed + traffic networks has suggested that bilateral agreements will be the + only method that will work between administrative domains [10]. + Multilateral agreements may indeed be complex to administer, but + bilateral agreements will not scale well and if the traffic needs to + traverse many administrative domains it will be hard to quantify the + + + + + +Eder, et. al. Informational [Page 8] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + end-to-end service being provided. Instability in the ownership and + administration of domains will also limit the usability of bilateral + agreements in predicting end-to-end service. + + As the convergence towards all IP continues it will be interesting to + understand what effects existing telecommunications regulations might + have on IP networks as more regulated traffic is carried over them. + Regulation has been used in the telecommunications world to open the + network, but it has had mixed results. A regulated process could + possibly eliminate the effects competitive pressures will have on + bilateral types of agreements and make it possible to get a truly + open environment, but it could also have an opposite effect. + Unfortunately the answer to this question may not come in the form of + the best technical solution but in the politically most acceptable + one. If traffic agreements between the boundaries of networks is not + standardized a continuing consolidation of network providers would + result. Providers unable to induce other providers to pair with them + may not be able to compete if QoS networks become commonplace. This + would be especially visible for small and midsize service providers, + who would be pressured to combine with a larger provider or face not + being able to offer the highest levels of service. If this + phenomenon plays out across international boundaries it is hard to + predict what the final outcome might be. + +5.6 Network Services + + The majority of current activity on higher level management functions + for IP networks have been restricted to the issue of providing QoS. + Many service issues still remain to be resolved with respect to the + current best effort paradigm and many more can be expected if true + QoS support is realized. Authentication, authorization and + accounting services still inadequate for the existing best effort + service will need additional work to support QoS services. + + It is reasonable that services can be classified into application + level services and transport level services. Transport services are + the services that the network provides independent of any + application. These include services such as Packet Forwarding and + Routing, QoS differentiation, Traffic Engineering etc. These might + also include such functions as security (Ipsec) and Directory + services. In IP networks a distinction is often made between QoS + transport services that are viewed as end-to-end (RSVP) or per-hop + (Diffserv). From a management perspective the two are very similar. + Transport level services are not very flexible, requiring application + level services to fit into the transport framework. An application + that needs additional transport level services will need to be a + mass-market application where the investment in new infrastructure + can be justified. Because of the effort in altering transport + + + +Eder, et. al. Informational [Page 9] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + services, applications that need new ones will have a longer time to + market and the effort and cost to develop a framework necessary to + support new transport services should not be underestimated. + + Application level services are those specific to the application. + Many service management functions occur between the application + supplier and the application consumer which require no knowledge or + support by the existing network. By keeping service management + functions at this level time to market and costs can be greatly + reduced. The disadvantages are that many applications need the same + functionality causing inefficient use of the network resources. + Services supplied by the network are able to be built more robustly + and can provide additional functionality, by virtue of having access + to information that applications can not, providing additional + benefit over application level services. An example of an + application level service that could benefit from a Network service + is the AAA paradigm for Web based E-Commerce, which is largely + restricted to user input of credit card information. Sometimes + application level service requirements have the disadvantages of both + transport service and application service level. For instance, in IP + telephony, this may include services provided by a gateway or other + network device specific to IP telephony to support such services as + call forwarding or call waiting. The mass appeal of IP telephony + makes it possible to suggest considerable infrastructure changes, but + the nature of this kind of change has contributed to the slow + penetration of IP telephony applications. + +6. The Way to a QoS Management Architecture + + An overview of some of the problems in the previous sections shows a + need for a consolidated framework. Transport level QoS will demand + traffic engineering that has a view of the complete network that is + far more comprehensive than what is currently available via the + Routing protocols. This view will need to including dynamic network + congestion information as well as connectivity information. The + current existing best-effort transport control may become more of a + hindrance to new services and may be of questionable value if the IP + network will truly become a full service QoS network. Both IntServ + and DiffServ QoS schemes require network provisioning to adequately + support QoS within a particular domain and agreements for traffic + traversing domains. Policy management, object oriented information + models, and domain gateways are leading to a more centralized + management structure that provides full service across domains and + throughout the network. Given the probable cost and complexity of + such a system failure to come up with a standard, even if it is a de + facto one, will have serious implications for the Internet in the + future. + + + + +Eder, et. al. Informational [Page 10] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + +6.1 Point to Point QoS + + For the current trends in QoS to succeed, there will need to be + harmonization across the new and existing control structures. By + utilizing a structure very similar to the existing routing control + structures, it should be possible develop functionality, not in the + data path, that can allocate traffic within a domain and use inter- + domain signaling to distribute between domains. Additional + functionality, necessary to support QoS-like authorization and + authentication functions for edge devices admitting QoS traffic and + administering and allocating traffic between administrative domains + could also be supported. While meeting the requirements for a + bandwidth broker network element [10], additional functionality of + making more general policy decisions and QoS routing could also be + performed. Given that these tasks are interrelated 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, while at the same time it must be compatible with the + current method for routing traffic. This could be accomplished by + redirecting routing messages to a central function, which would then + calculate paths based on the entire network transport requirements. + Across domains, communication would occur as necessary to establish + and maintain service levels at the gateways. At the edges, devices + would provide traffic information to billing interfaces and verify + that the service level agreed to was being provided. For scalability + any central function would need to be able to be distributed in large + networks. Routing messages, very similar in content to the existing + ones, would provide information sufficient to support the traffic + engineering requirements without changing the basic forwarding + functions of the devices. Having routes computed centrally would + simplify network devices by alleviating them from performing + computationally intensive routing related tasks. + + Given the number of flows through the network the core can not know + about individual flow states [11]. At the same time it is not + practical to expect that the edge devices can determine paths that + will optimally utilize the network resources. As the information + needed to forward traffic through the network becomes related to + complex parameters that can not be determined on a per hop basis and + have nothing to do with the forwarding of packets, which routers do + best, it might make sense to move the function of determining routes + to network components specifically designed for the task. In a QoS + network routing decisions will become increasingly dependent on + information not easily discernable from the data that routers could + logically share between themselves. This will necessitate the need + to for additional functionality to determine the routing of data + + + +Eder, et. al. Informational [Page 11] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + through the network and further suggests that all the information + needed to allow a router to forward packets might not be better + provided by a network element external to the packet forwarding + functions of a router. + + At the edges of the network where the traffic is admitted it will be + necessary to have mechanisms that will insure the traffic is within + the bounds of what has been specified. To achieve this it will be + necessary to buffer and control the input traffic. Second the + traffic would need to be marked so the other network elements are + able to identify that this is preferred traffic without having to + keep flow information. Conversely, a path could be chosen for the + traffic that was dedicated to the level of service being requested + that was per flow based. A combination of the two would be possible + that would allow a reservation of resources that would accommodate + multiple flows. Both methods are similar from a management + perspective and are really identical with regards to route + determination that could be performed centrally in that one method + represents just a virtual path based on the handling of the packets + by the device in the network and the second would be a pre-reserved + path through the network. Existing best effort routing will not + provide the optimum routes for these new levels of service and to + achieve this it would be necessary to have either routing protocols + that supported optimum path discovery or mechanisms to configure + paths necessary to support the required services. In addition to + specific service parameters reliability will also be a potential + service discriminator. It is unlikely using traditional path + determination methods that in the event of a failure a new path could + be determined sufficiently quickly to maintain the agreed service + level. This would imply the need for multiple path reservations in + some instances. Because Per flow reservations are too resource + intensive virtual trunks would provide a good way to reduce the + amount of management traffic by reserving blocks of capacity and + would provide stability in the event of a failure in the resource + reservation and route selection functions. + + There are implications of providing shaping at the network + boundaries. Shaping would include both rate and burst parameters as + well as possible delay aspects. Having to provision services with + specific service parameters would present both major business and + technical problems. By definition, packet data is bursty in nature + and there exist periods of idleness during the session that a + provider could reasonable hope to exploit to better utilize the + network resources. It is not practical to expect a consumer paying a + premium for a service would not check that the service was truly + available. Such a service model seems to be filled with peril for + + + + + +Eder, et. al. Informational [Page 12] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + the existing best effort Internet, because any significant amount of + bandwidth that was reserved for exclusive use or a high priority flow + would not be available for best effort data. + + With respect to traffic within the network itself there will be the + need to pre-configure routes and to provide the ability to have + routes be dynamically configured. Some of the problems with pre- + configured traffic include the basic inconsistency with the way + traffic is currently engineered through the Internet and the + difficulty in developing arrangements between administrative domains. + The current Internet has been developed with one of the most + egalitarian yet simplistic methods of sharing bandwidth. Supporting + the existing best effort service, in an unbiased way, while at the + same time providing for other classes of service could potentially + add a tremendous amount of complexity to the QoS scheme. On the + other hand, if the reserved bandwidth is not shared it could result + in a significant impact on the availability of the bandwidth in the + Internet as we know it today. QoS could potentially contribute more + to their being insufficient bandwidth, by reserving bandwidth within + the network that can not be used by other services, even though it + can be expected that this bandwidth will be underutilized for much of + the time. Add to that the motivation of the service providers in + wanting to sell commodity bandwidth, and there could be tremendous + pressures on the availability of Internet bandwidth. + + Current work within the IP community on defining mechanisms to + provide QoS have centered on a particular few architectures and a + handful of new protocols. In the following sections, we will examine + some of the particular issues with regards to the current IP + community efforts as they relate to the previous discussions. It is + not the goal of this document to serve as a tutorial on these efforts + but rather to identify some of the support issues related to using + particular technologies that support some form of classifiable + service within an IP network. + +6.2 QoS Service Management Scope + + One can restrict the scope of a discussion of QoS management only to + the configuration of a path between two endpoints. Even within this + limited scope there still remains many unresolved issues. There is + no expectation that a QoS path for traffic between two points needs + to be, or should be, the same in both directions. Given that there + will be an originator of the connection there are questions about how + billing and accounting with be resolved if the return path is + established by a different provider then that of the originator of + the connection. To facilitate billing a method will need to exist + that permits the application originating the call to pay also for the + return path and also for collect calls to be made. 3rd party + + + +Eder, et. al. Informational [Page 13] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + providers will need to be established that are trusted by all parties + in the data path to insure billing and guaranteed payment. Utilizing + the service of a virtual DCN that is built upon 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 will be paying + for it, and each provider will need a verifiable method to bill for + the service provided. As pointed out earlier this functionality will + be similar to what is used in the existing telephone network, but + will be at a much larger scale and potentially involve providers that + are highly competitive with each other. + +7. The DiffServ Architecture + + The DiffServ management problem is two pronged. First there is the + management within the administrative domain that must be addressed, + and then the management between the domains. There has been little + actual work on the second in the architecture. What work there has + been anticipates that service level agreements will be reached + between the administrative domains, and that end-to-end service will + be a concatenation of these various service level agreements. This + is problematic for many reasons. It presumes that agreements reached + bilaterally could be concatenated and continue to provide a level of + end-to-end service the customer would be willing to pay a premium + for. Problems discussed earlier, with trying to maintain large + numbers of these agreements between competitive networks would also + apply, and tend to limit the effectiveness of this approach. To + efficiently establish the chain necessary 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 is not likely + that a customer would be willing to pay for an improved level of + service if it did not 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. While it is very likely + that an initial attempt at providing this kind of service will + specify only a particular ingress and egress border, for robustness + and flexibility it will be desirable to have a network that can + support such service without such 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. + + + + +Eder, et. al. Informational [Page 14] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + The high level functional requirements for edge routers has been + quite well defined in the DiffServ architecture, but the true scope + of the effort to implement this functionality has not been well + recognized. While interesting differences exist between the QoS + architecture of the Internet and the circuit switched network used + for telecommunications much of the lessons learned in + telecommunications should, even if they might do little else, provide + some insight into the level of effort needed to implement these kinds + of requirements. Ironically, given the Internet community in the + past has rejected the level of standardization that was proposed for + management of telecommunications networks, 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. Verification that + traffic is within agreed parameters and 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 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. + + + + + + + +Eder, et. al. Informational [Page 15] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + 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 + request 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 be in most instances too costly to create a physically + separated DCN it will be possible to create a virtually separated + network that will provide the same security benefits. Future work in + the IRTF Service Management Research Group intends to look in detail + at these requirements. + +9. Security Considerations + + 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 in mind the overall picture + while, at the same time, breaking out specific parts of the problem + to be standardized in particular working groups. Thus, 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 are 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 if this is + realistic. Further analysis is needed to determine what is the + proper paradigm for IP service management 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 + + + +Eder, et. al. Informational [Page 16] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + often an inefficient use of network resources, but more importantly + 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 service information that will be necessary to + provide superior application functionality. 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. + + + +Eder, et. al. Informational [Page 17] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + + + [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 + + + + + + + + + + + + + + + + + +Eder, et. al. Informational [Page 18] + +RFC 3387 IP Service Management in the QoS Network September 2002 + + +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. + + + + + + + + + + + + + + + + + + + +Eder, et. al. Informational [Page 19] + |