doc: Add RFC documents

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