Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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.


 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

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
 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

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
 Sid Nag
 PO Box 104
 Holmdel, NJ 07733, USA
 Phone: +1-732-687-1762
 Hemant Chaskar
 Nokia Research Center
 5 Wayside Road
 Burlington,  MA  01803, USA
 Phone: +1-781-993-3785
 Fax:   +1-781-993-1907

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
 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


 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Eder, et. al. Informational [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3387.txt · Last modified: 2002/09/25 23:43 (external edit)