Internet Research Task Force M. Eder Internet Draft H. Chaskar Document: draft-irtf-smrg-ipsmf-00.txt Nokia S. Nag Category: Experimental July 11, 2001 IP Service Management in the QoS Network Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). 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 QoS-capable network envisioned by some for the future. We examine some of the areas of impact QoS is likely to have on management and look at some questions that remain to be addressed. IP Service Management in the QoS Network expires January, 2002 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 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 paper 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 these new services represent 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]. IP, in contrast to other network technologies, does not limit the scope of service management simply to end-to-end connectivity, but combines service management with regards to transport with the management of the actual applications and how they are using the network. If the available transport services in IP expand, this will result in 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 Eder, Nag, Chaskar 2 IP Service Management in the QoS Network expires January, 2002 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 offer QoS. 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 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, its 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. 4. Telecommunications Service Management One place to start an effort to define service management in IP networks is by looking at what was been done previously in telecommunications networks. The telecommunications standards have not been very successful in defining an industry accepted service management framework even in an environment in which the service is fairly constrained. Yet regulation has made it necessary for Eder, Nag, Chaskar 3 IP Service Management in the QoS Network expires January, 2002 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 [5]. These standards were designed specifically to address telecommunications networks, 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 TMN a dependency exists between layers and clear functions at their boundaries are defined. To what extent service management, as defined in the TMN standards, can be applied to IP which is lacking a network layer that supports a Logical Layered Architecture must be further investigated [5]. 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 as its origins in the telecommunications industry's standardization work. The IP management framework might not have made even these distinctions if it where not for the telecommunications legacy. 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 proper framework architecture to enable management information to be distributed in the network environment. The informational framework appears to be the easier problem to address and the one that is principally being focused on by the IP community. Eder, Nag, Chaskar 4 IP Service Management in the QoS Network expires January, 2002 Efforts by organizations such as the DMTF with their CIM and DEN initiatives 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 [6]. What has not emerged is a clear framework for defining how the network management functionality will exist and how the information within the network domain and between domains will be exchanged. Clearly the size of these networks will require this information to be highly distributed. There is a good deal of disagreement on this subject, but one would expect that 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 the framework by which certain service management issues can be addressed, primarily concentrating on those concerning access and traffic prioritization within a single administrative domain [7]. Many of the current policy efforts are focused on 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. The full scope of problems associated with providing a commodity service that will need to be verifiable have not been addressed. A second issue with current policy efforts is the static nature in which they have been architect. Policies are not going to be functional if they cannot accommodate the dynamic nature of the network and its users. 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. Element or device management does not meet the requirements for being multi-domain because the scope is primarily that of the device manufacturer. This may partially explain why it is proving to be not a very worthwhile candidate for standardization. The implementation of element management systems standards have varied depending on the nature of the hardware and been pretty dependent on a particular manufacturers implementation. The problem with the domain model as it relates to IP networks is that so much of the traffic is likely to traverse multiple domains under separate administrative control. Unlike the telecommunications network in which traffic traverses only a relatively small number of domains, IP traffic may traverse many Eder, Nag, Chaskar 5 IP Service Management in the QoS Network expires January, 2002 separately administered networks. 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. To be successful IP will need to model the domain problem in a way that reduces the complexity. A service management framework must address the business processes that operate when providing a service [5]. The processes a service framework must address can be separated into two fundamental divisions for any service. The first is the definition of the service and the second is the management of an embodiment of the service. While this division is intuitive, a formal process needs to be in place if management of the service is to be actually realized. In specifying a service, the service architecture must first be mapped onto the capabilities of the underlying network architecture. The service needs to be specified in an unambiguous way so that the 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. Increasingly, as networks evolve it is going to be necessary to logically describe the network capabilities to the service. As the IP networks become more fragmented it will be increasingly the case that specific service classifications will need to be made available. A method that will allow for the logical definition of the network from a service perspective would allow for greater control of the network by the service management systems. An ever increasing number of service specific devices are being added to the network. These devices are often designed with management capabilities consistent with the services they offer. It has been recognized that there exists a requirement for the user to have as much control over the management of the service as possible. As the number and type of service specific devices increase in the network it will become important to provide management access to these devices over well understood methods. IP services will need to be highly customizable necessitating that the management of the service be with the user to the extent possible. Paramount to the success of any service is determining how that service will be billed. The process of billing must take place 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 Eder, Nag, Chaskar 6 IP Service Management in the QoS Network expires January, 2002 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. Given the limited success of telecommunications efforts to formalize the relationship between different management support functions it is highly suspect that such efforts would have any chance of succeeding in IP networks which have a 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 management functionality will have to cross boundaries of responsibility, the more the network management functions have to be distributed throughout the network. 6. 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 their being sufficient need for standardization or regulation to control these agreements resulting in it becoming no longer acceptable to make individual arrangements. 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 since they consider that 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 Eder, Nag, Chaskar 7 IP Service Management in the QoS Network expires January, 2002 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 [8]. In either situation as IP bandwidth goes from being delivered on a basis equal to all, to being delivered based on a particular authorities formula, there will become a need to provide authentication and validation. This will include the ability to measure that 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 the only method that will work between administrative domains is that of bilateral agreement [9]. Multilateral agreements may indeed be complex to administer, but another type of multilateral agreements exists that is not so complex. This is the multilateral agreements mandated by means of national or international regulation. Bilateral agreements will not scale well and if the traffic needs to traverse many administrative domains it will be hard to quantify the end-to-end service being provided. If the current instability in the ownership and administration of domains continues this will also limit the usability of bilateral agreements. Only through a regulated process will it be possible to eliminate the effects competitive pressures will have on these types of agreements and make it possible to get a truly open environment. Much pressure of a non-technical nature exists today to discourage this scenario. If traffic agreements between the boundaries of networks is not mandated or standardized a continuing consolidation of network providers will result. Providers unable to induce other providers to pair with them will lose business if QoS networks become commonplace. This result would be especially visible in its effects on small and midsize service providers. The majority of contemporary activity on higher level management functions for IP networks have been restricted to the issue of differentiating QoS with regards to transport. 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, Traffic Engineering, RSVP/Intserv, Diffserv and MPLS. These might also include such functions as security (Ipsec) and Directory services. In IP networks, QoS transport services can be Eder, Nag, Chaskar 8 IP Service Management in the QoS Network expires January, 2002 viewed as end-to-end (RSVP) or per-hop (Diffserv). Transport level services tend to be unalterable requiring application level services to fit into the transport framework. An application that needs a new transport level service will need to be a mass-market application where the investment in new infrastructure can be justified. Because of the effort in altering transport services, applications that need new ones will have a longer time to market. 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. Transport services 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 transport service is the AAA paradigm for E-Commerce. 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 made 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. 7. A New Service Management Architecture An overview of the new management architectures shows a clear 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, including network dynamics and network congestion information in the networks at a given instant of time, for the network administrator to take appropriate actions at any given instant. The current existing best-effort transport control plane 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 administrators to provision their networks to support QoS within a particular domain and to establish SLAs for traffic traversing domains. In reality, very few administrators would be able to understand the complexities of such a task and would simply accept the factory default settings with the expectation that these would provide adequate operations. Policy management, object Eder, Nag, Chaskar 9 IP Service Management in the QoS Network expires January, 2002 oriented information models, and domain gateways are leading to a need for a more centralized management structure that is no less automated than the infrastructure of the past but provides an approach able to insure full service throughout the network and across domains. Given the probable cost and complexity of such a system failure to come up with a standard, even if it is a de facto standard, will have serious implications for the Internet in the future. 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 [9], 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 architecture is based on a centrally located functionality responsible for allocating traffic within a particular administrative domain and capable of signaling traffic requirements across domains. This would be accomplished by redirecting routing messages to the central functionality which would then calculate paths based on the entire network and the transport requirements. 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 the network devices and release them from performing computationally intensive routing related tasks. Given the growth of the Internet, for scalability reasons the core can not know about flow states [10], and this information can be known only in the edge routers. As the information needed to forward traffic through the network becomes more and more related to complex parameters that have nothing to do with the forwarding of packets, which routers do best, it makes less and less sense to have the determination of routes as a component of a routers functions. In a QoS network routing decisions become increasingly dependent on information not easily discernable from the data that routers can logically share between themselves. This will necessitate the need for additional functionality to determine the routing of data through the network and further suggests that all the information needed to allow a router to forward packets might not be better provided external to the routers functions. Eder, Nag, Chaskar 10 IP Service Management in the QoS Network expires January, 2002 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 functionality, it will be necessary to buffer and control the input traffic. Second the traffic would need to be marked so the other network elements would be aware that this was the preferred traffic. Conversely, a path could be chosen for this traffic that was dedicated to the level of service being requested. Some combination of these two would be possible. In fact these two methods are more similar than they first appear from a management perspective. Both are really identical in that one is just a virtual path based on the handling of the packets by the device in the network and the second would be more a pre-configured path through the network. It can not be expected that the existing best effort routing will provide the optimum routes for these new levels of service. 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. There are implications of providing shaping at the network boundaries. Shaping would include both rate and burst parameters. Having to provision services, that cannot be over subscribed, would present both major business and technical problems. By definition, packet data is bursty in nature and there exist long periods of idleness during the session. 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 the existing best effort Internet if any significant amount of the bandwidth was reserved for exclusive use. Clearly 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. Each is complex in itself. Some of the problems with pre-configured traffic include it's 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 Eder, Nag, Chaskar 11 IP Service Management in the QoS Network expires January, 2002 bandwidth, and that 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 paper 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. 8. 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. The second is certainly easier to address because there has been little actual work on this aspect of 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. From the business perspective, 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. Market conditions mentioned earlier with trying to maintain large numbers of these agreements between competitive networks would also apply. 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. 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 too much per flow and overhead information in the core network and not be scaleable [10]. 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 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 Eder, Nag, Chaskar 12 IP Service Management in the QoS Network expires January, 2002 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. 9. Common 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, 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. 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. Eder, Nag, Chaskar 13 IP Service Management in the QoS Network expires January, 2002 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 will not provide for access to transport level services and the functionality that only those services will 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 assess to transport 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. Authors Michael Eder Nokia Research Center 5 Wayside Road Burlington, MA 01803 Phone: +1-781-993-3636 Fax: +1-781-993-1907 E-mail: Michael.eder@nokia.com Sid Nag PO Box 104 Holmdel, NJ 07733 Phone: +1-732-687-1762 E-mail: thinker@monmouth.com Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803 Phone: +1-781-993-3785 Fax: +1-781-993-1907 E-mail: hemant.chaskar@nokia.com Eder, Nag, Chaskar 14 IP Service Management in the QoS Network expires January, 2002 12. References [1] Laurent Mathy, Christopher Edwards, David Hutchison, "The Internet: A Global Telecommunications Solution?", IEEE Network, July/August 2000. [2] Barry M. Leiner, Vinton G. Cerf, et. al., ôA Brief History of the Internetö version 3.31, revised 4 Aug 2000 [3] J. Strassner and E. Ellesson, "Terminology for describing network policy and services", draft-ietf-policy-terms-02.txt, June 1999. [4] Yoram Bernet, "The Complementary Roles of RSVP and Differentiated Services in the Full-Service QoS Network", IEEE Communications Magazine, February 2000 [5] Recommendation M.3010 (02/00) - Principles for a telecommunications management network, ITU-T [6] Recommendation M.3100 (07/95) - Generic network information model, ITU-T [7] B. Moore, et. al., "Policy Core Information Model -- Version 1 Specification", IETF, RFC 3060, February 2001 [8] Van Jacobson, Differentiated Services for the Internet, Internet2 Joint Applications/Engineering QoS Workshop [9] K. Nichols, V. Jacobson, L. Zhang, A Two-bit Differentiated Services Architecture for the Internet, RFC 2638, July 1999 [10] Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A., Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement", RFC 2208, September 1997. Eder, Nag, Chaskar 15