Network Working Group                                            M. Eder
Request for Comments: 3387                                    H. Chaskar
Category: Informational                                            Nokia
                                                                  S. Nag
                                                          September 2002
        
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

服务管理研究小组(SMRG)对IP网络服务质量(QoS)的考虑

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.

版权所有(C)互联网协会(2002年)。版权所有。

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.

IP网络管理设计的指导原则是简单,无需集中控制。尽力而为的服务模式是原始管理原则的结果,反之亦然。区分一组数据包或流相对于另一组数据包或流提供的服务的新方法正在进行中。然而,随着IP网络的发展,过去的管理方法可能不适用于一些人对未来设想的具有服务质量(QoS)能力的网络。本文档分析了QoS可能对管理产生影响的一些领域,并探讨了一些有待解决的问题。

1. Introduction
1. 介绍

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

简单性高于一切是IP网络设计的指导原则之一。然而,随着IP网络的发展,IP中的服务概念也在发展,过去的策略可能不适用于一些人对未来设想的具有全服务QoS能力的网络。在IP社区内,他们的观点存在着很大的推动力,即如果要实现IP的承诺,网络将需要提供越来越多的服务。IP中这些新服务的定义导致需要重新评估IP网络使用的当前控制机制。提供机制以区分提供给一组数据包或流的服务与另一组数据包或流的服务的工作正在进行中,但是利用这些机制所需的许多支持功能在范围上是有限的,并且需要一个完整的框架

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.

不存在。这是复杂的事实,许多这些新的服务,也将需要某种形式的计费框架,除了一个控制,这是一个全新的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.

如果未来的IP网络将以任何重要的方式提供不仅仅是传统的尽力而为的服务,那么本文件旨在评估需要解决的网络和服务管理问题。

2. Background
2. 出身背景

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

定义QoS管理框架的任务将很困难,因为它与过去IP的核心尽力而为的服务模式有着根本的不同,并且有一个明确的设计策略,即简单性优先于一切[1]。这种理念在IP网络和服务管理领域最为明显[2]。支持各种QoS功能的拟议变更将以非常显著的方式影响现有的控制结构。使问题更加复杂的是,对IP中“服务”的构成缺乏了解[3]。与其他一些网络技术不同,在IP中,仅将服务管理的范围限制在端到端连接是不够的,但还必须涵盖为数据包提供的传输服务以及传输的使用方式。QoS管理是更一般的服务管理的一个子集。在寻求解决QoS管理问题时,了解服务管理问题的一些问题和局限性是非常有用的。QoS不能被视为一个独立的实体,其管理需求将由一般更高级别的服务需求驱动。如果IP中的可用传输服务扩展,其结果将是服务的进一步扩展。现在事实上,WEB服务被纳入了IP服务的范围,这是值得注意的,因为在IP最初发明时,WEB甚至不存在,这很好地说明了这种情况。随着当前网络决策点向网络边界移动的趋势,这种现象预计会增加,从而更接近应用程序和客户。此外,关于IP网络是否需要QoS的争论仍在继续。基于光纤和波分复用的新技术使许多人相信带宽将非常便宜,因此不需要有明确的控制框架来提供QoS区分。无论为高峰使用率设计网络多么不经济,本次辩论中的一个主要论点无疑是为QoS网络开发运营支持系统并在现有网络中部署这些系统的成本。客户可能愿意为额外服务付费这一事实可能并不能成为实施全面架构更改的理由,因为这些更改可能会严重影响众所周知的互联网

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.

今天IP社区必须非常关注的是,尽力而为的互联网所具有的平等性可能会被牺牲,取而代之的是具有完全不同商业模式的服务。如果核心网络开始提供产生更多收入的服务,那么很容易就会以产生较少收入的尽力而为服务为代价。

3. IP Management Standardization
3. IP管理标准化

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.

IP社区中的管理标准化工作传统上涉及通常称为“元素管理”或“设备管理”的内容。最近,IP管理方面的新工作增加了解决服务问题和以更抽象的术语看待网络的能力。这些努力包括服务的逻辑表示以及网络中资源的表示,再加上服务用户的概念,使得人们经常谈论的“策略”概念成为可能。其中值得注意的是IETF中的政策工作以及DMTF在CIM和DEN上的工作。服务管理框架的关键元素正在进入人们的视野,但它指出了IP的一种趋势,这种趋势与过去的控制机制有很大的不同。随着服务模型从足以支持尽力而为发展到能够支持不同级别的服务,集中化管理体系结构的趋势变得非常明显。

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.

这一点越来越明显,原因有二。QoS机制需要网络范围的信息[4],要使其成功,就必须不需要来自核心网络的大量支持。越来越多的人认为,只有在网络边缘才有足够的资源来提供接纳和控制各种QoS流所需的机制。

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.

现在经常问到的一个问题是:“在网络中间提供服务的建筑效益是否超过建筑成本”(5)。同样的问题也应该问服务管理。由于需要新的网络元件来支持服务管理,即使它们不直接促进分组的转发,也需要考虑增加的复杂性和破坏网络稳定的可能性的成本。当我们开始更详细地研究本调查文件中提出的一些问题时,SMRG将对此问题进行分析。

4. Telecommunications Service Management
4. 电信服务管理

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.

在IP网络中定义服务管理的一个起点是查看以前在电信网络中所做的工作。服务管理框架的电信标准即使在服务受到相当限制的环境中也没有得到广泛接受。尽管监管规定网络运营商必须充分开放其网络,以允许多个供应商参与提供服务,但许多专有协议仍在市场上占据主导地位。这表明存在一些形式化的边界,或者市场足够大,足以证明开发接口的合理性。国际电信管理标准通过将其划分为独立但高度相关的层来看待整个管理问题。许多用于描述IP管理问题的术语已从电信标准中扩散开来[6]。这些标准是专门针对电信网络和服务而设计的,目前尚不清楚它们将如何适用于IP网络。服务管理是根据电信网络中的服务集定义的,管理框架反映了这些网络的分层集中控制结构。服务管理框架基于电信管理网络(TMN)分层管理方法。目前的知识产权标准主要侧重于要素管理层,特别是侧重于统计数据的收集,强调分散的方法。在TMN体系结构中,层与层之间存在依赖关系,定义了边界处的清晰接口。必须进一步研究TMN标准中定义的服务管理在多大程度上可应用于IP,其中可能存在对层间正式接口要求的阻力[6]。

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.

TMN概念必须小心地应用于IP网络,因为存在根本性差异。IP网络的控制高度分散,尤其是在网络层。管理是非层次化和分散的,有许多点对点关系。将管理正式划分为多个层(这些层的边界存在管理依赖关系)可能不适用于IP。在IP中定义服务管理的任何努力都必须时刻保持警惕,不要假定电信概念可以直接应用于IP网络。将网络管理问题抽象为元素、网络和服务管理的最基本概念起源于电信行业的标准化工作,而IP管理框架如果不是因为电信遗留问题,可能甚至不会做出这些区别。

5. IP Service Management: Problem Statement
5. IP服务管理:问题陈述

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.

在定义IP服务管理框架时,必须解决需要管理的服务的性质。传统的网络管理框架由两部分组成,一部分是信息框架,另一部分是向网络设备分发信息的框架。一种非常直截了当的关系存在于分发框架必须支持信息框架,但也存在于信息和分发框架所暗示的关于系统管理的更微妙的关系。信息框架似乎是更容易解决的问题,也是IP社区主要关注的问题。

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.

像DMTF CIM这样的努力目前正试图定义网络信息模型,在较小程度上是服务信息模型。这些工作与电信行业在定义信息模型方面惊人地相似[7]。尚未出现的是定义如何使用模型中包含的信息来管理网络的标准。

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.

要在这些网络中管理的元素数量将需要高度分布这些信息。高度分布的目录是静态信息的主要候选目录。对于动态性质的信息,问题变得更加复杂,尚未得到令人满意的解决。策略管理是在网络中提供分布式目录服务的逻辑扩展。IETF和DMTF希望策略管理成为处理某些服务管理问题的框架。当前的许多政策工作都集中在特定网元内的访问和流量优先级上,并且只针对单个管理域[8]。在边缘对流量进行分类并强制执行策略,目的是关注准入问题,而不解决问题的端到端性质,这使得一些最复杂的QoS管理问题仍然没有得到解决。在IP中提供可验证的商品服务级别将影响到网络的各个方面,问题的管理解决方案必须解决其运行的规模和动态。

5.1 Common Management Domain
5.1 公共管理域

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

标准化工作需要集中于多领域性质的管理问题。对多域的测试通常围绕多对一或一对多关系展开,这些关系需要两个或多个不同实体的参与。域可以反映管理域、路由域或包含域之间的协议。不像

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.

通信量只通过相对较少数量的域的电信网络,IP网络中的通信量可能在单独的管理控制下通过许多域。使情况进一步复杂化的是,与电信网络不同,这些领域中的许多在性质上具有高度竞争力,提供并适应不同的服务级别协议。即使放松管制,电信流量也会从接入提供商网络传输到核心网络,然后,如果是国际呼叫,则会跨越国际边界。域的数量相对于IP来说很小,每个域中支持的服务实际上是相同的,但是每个域可能有不同于其他域的业务模型。相比之下,IP将有许多域、许多服务,并且域可能具有很强的竞争力。为了取得成功,IP需要以一种降低复杂性的方式对域问题进行建模,这种复杂性是由多个独立的网络产生的,每个网络都有不同的服务模型来负责单个流。解决互为直接竞争对手的域之间的服务管理问题也会使流程复杂化,因为解决方案不能向竞争对手透露太多关于一个域网络功能的信息。解决方案可能需要双方都信任的第三方提供所需的管理功能,同时确保敏感信息不会从一方传递到另一方。

5.2 Service Management Business Processes
5.2 服务管理业务流程

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

在指定服务时,必须能够将其映射到底层网络体系结构的功能上。需要以明确的方式指定服务,以便能够建立机制来实现对服务的控制。在面向对象建模中,它可以是一个有用的工具,用于查看服务定义与该服务实例之间的关系,以及对象定义与该对象实例化之间的关系。随着网络的发展,有必要对服务的网络能力进行逻辑描述,因为IP网络是如此分散,因此需要提供超越各个区域和域的特定服务分类。一种接口,用于定义和

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.

服务的设计通常具有特定于它们的管理功能。这些服务往往不依赖于网络的服务方面,而只依赖于其传输能力。随着服务越来越依赖于网络,将需要在共享框架上进行管理。运营商已经认识到,业务需要允许用户尽可能多地控制自己服务的管理。IP服务将具有高度多样性和可定制性,这进一步要求尽可能向用户提供服务管理。

In the IP environment where they may be many separate entities required to provide the service this will create a significant management challenge.

在IP环境中,可能需要许多独立的实体来提供服务,这将带来重大的管理挑战。

5.3 Billing and Security
5.3 计费和安全

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
5.4 标准

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

鉴于电信标准机构将不同管理支持职能之间的关系正式化的努力成效有限,人们高度怀疑这种努力将在网络和服务概念更加多样化的IP网络中取得成功。如果IP网络由具有同等管辖权的对等域组成,则必须具有能够遍历这些域的管理功能。当然,管理责任所在的角度在很大程度上取决于参考点。一个中心的有利位置表示不同领域之间平等分担责任。从任何特定域中,管理责任存在于该域中,并且仅存在于该域中。为了使管理框架在IP网络中取得成功,必须确定逻辑管理功能以及极其灵活的定义语言,以定义这些管理功能的接口。越

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
5.5 核心域间功能

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.

IP服务管理范式必须从技术解决方案的组合以及表示供应商业务关系的公式的角度来解决管理问题。目前,域之间需要支持的服务要求提供者之间协商服务级别协议(SLA)。如果协议数量变得非常多和/或协议的性质变化很大,这些协议在某个时候可能会变得难以管理。这将导致充分需要某种形式的标准化来控制这些协议。

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.

带宽代理被认为是一种从业务角度处理域间与流量相关的许多问题的方法。带宽代理的前提是确保网络域之间就流量达成一致,但也需要解决不太可能量化的安全和计费问题。传统上,服务提供商不愿意使用带宽代理或SLA类型的功能,因为他们担心此类工具会将其弱点暴露给竞争对手和客户。虽然这不是一个技术问题,但它确实在有效管理服务方面提出了一个实际问题。展望未来QoS网络的基本要求,两种相互竞争的理念变得显而易见。网络提供商希望对流量进行更多的控制,以允许他们选择哪些流量优先,尤其是在拥挤的环境中。用户希望能够识别与租用线路特征非常相似的路径[9]。在这两种情况下,随着IP带宽从平等交付到基于复杂公式交付,将越来越需要提供身份验证和验证,以验证谁获得了什么服务以及他们是否为此付费。这将包括测量是否提供了指定的服务、定义服务的确切参数以及验证是否只提供了授权级别的服务的能力。

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

早期关于混合交通网络架构框架的一些工作表明,双边协议将是在管理域之间工作的唯一方法[10]。多边协议的管理可能确实很复杂,但双边协议的规模不会很好,如果流量需要穿越许多管理领域,则很难对其进行量化

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.

随着向全IP的融合继续进行,了解现有电信法规可能会对IP网络产生何种影响将是一件有趣的事情,因为更多的受监管流量会通过这些网络传输。电信界曾采用监管来开放网络,但结果喜忧参半。一个受监管的过程可能会消除竞争压力对双边协议类型的影响,从而有可能获得一个真正开放的环境,但也可能产生相反的效果。不幸的是,这个问题的答案可能不是最好的技术解决方案,而是政治上最可接受的解决方案。如果网络边界之间的流量协议没有标准化,将导致网络提供商的持续整合。如果QoS网络变得普遍,无法诱导其他提供商与其配对的提供商可能无法竞争。这对于中小型服务提供商来说尤其明显,他们将被迫与大型服务提供商合并,否则将无法提供最高级别的服务。如果这种现象跨越国际边界,那么很难预测最终结果会是什么。

5.6 Network Services
5.6 网络服务

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.

目前关于IP网络高级管理功能的大多数活动都局限于提供QoS的问题。相对于当前的尽力而为模式,许多服务问题仍有待解决,如果实现真正的QoS支持,还可以预期更多的问题。认证、授权和记帐服务仍然不足以支持现有的尽力而为服务,因此需要额外的工作来支持QoS服务。

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

将服务分为应用程序级服务和传输级服务是合理的。传输服务是网络独立于任何应用程序提供的服务。这些服务包括包转发和路由、QoS区分、流量工程等服务。这些服务还可能包括安全(Ipsec)和目录服务等功能。在IP网络中,通常将QoS传输服务区分为端到端(RSVP)或每跳(Diffserv)。从管理的角度来看,两者非常相似。传输级服务不是很灵活,需要应用程序级服务适应传输框架。需要额外运输级服务的应用程序需要是大众市场应用程序,在这种应用程序中,新基础设施的投资是合理的。因为改变交通的努力

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.

应用程序级服务是特定于应用程序的服务。许多服务管理功能发生在应用程序供应商和应用程序消费者之间,不需要现有网络的知识或支持。通过将服务管理功能保持在此级别,可以大大减少上市时间和成本。缺点是许多应用程序需要相同的功能,从而导致网络资源使用效率低下。通过访问应用程序无法访问的信息,网络提供的服务能够更可靠地构建,并能够提供附加功能,从而提供应用程序级服务的附加好处。基于Web的电子商务的AAA范例是可以从网络服务中获益的应用程序级服务的一个例子,它主要限于用户输入信用卡信息。有时,应用程序级服务需求同时具有传输服务和应用程序服务级的缺点。例如,在IP电话中,这可以包括由网关或特定于IP电话的其他网络设备提供的服务,以支持诸如呼叫转发或呼叫等待之类的服务。IP电话的巨大吸引力使人们有可能提出重大的基础设施变革,但这种变革的性质导致了IP电话应用的缓慢普及。

6. The Way to a QoS Management Architecture
6. QoS管理体系结构的实现方法

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.

前几节中的一些问题概述表明需要一个整合的框架。传输级QoS将要求流量工程具有完整网络的视图,该视图比当前通过路由协议可用的视图更全面。此视图需要包括动态网络拥塞信息以及连接信息。当前的尽力而为传输控制可能会成为新服务的更多障碍,如果IP网络将真正成为全服务QoS网络,其价值可能会受到质疑。IntServ和DiffServ QoS方案都需要网络配置,以充分支持特定域内的QoS,并为跨域的流量提供协议。策略管理、面向对象的信息模型和域网关正导致一种更集中的管理结构,它跨域和整个网络提供全方位服务。考虑到这样一个系统的可能成本和复杂性,未能制定出一个标准,即使它是一个事实上的标准,也将对未来的互联网产生严重影响。

6.1 Point to Point QoS
6.1 点对点服务质量

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.

为了使QoS的当前趋势取得成功,需要对新的和现有的控制结构进行协调。通过利用与现有路由控制结构非常相似的结构,应该可以开发功能,而不是在数据路径中,该功能可以在域内分配流量,并使用域间信令在域之间分配流量。还可以支持为允许QoS流量以及管理和分配管理域之间的流量的边缘设备支持QoS授权和身份验证功能所必需的附加功能。在满足带宽代理网元[10]要求的同时,还可以执行制定更一般的策略决策和QoS路由的附加功能。考虑到这些任务是相互关联的,如果可能的话,整合它们是有意义的。

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

给定通过网络的流量数量,核心无法了解单个流量状态[11]。同时,期望边缘设备能够确定最佳利用网络资源的路径是不现实的。由于通过网络转发通信量所需的信息与复杂参数相关,这些参数不能在每跳的基础上确定,并且与包的转发无关,路由器做得最好,因此将确定路由的功能移动到专门为任务设计的网络组件可能是有意义的。在QoS网络中,路由决策将越来越依赖于路由器之间逻辑共享的数据中不易识别的信息。这将需要使用其他功能来确定数据的路由

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

在网络边界处提供成形有其含义。成形将包括速率和突发参数以及可能的延迟方面。必须提供具有特定服务参数的服务将带来重大的业务和技术问题。根据定义,分组数据本质上是突发性的,并且在会话期间存在空闲时段,提供商可以合理地希望利用这些空闲时段来更好地利用网络资源。期望为某项服务支付额外费用的消费者不会检查该服务是否确实可用是不现实的。这样的服务模式似乎充满了风险

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.

对于网络本身内的流量,需要预先配置路由,并提供动态配置路由的能力。预配置流量的一些问题包括与当前通过Internet设计流量的方式基本不一致,以及难以在管理域之间制定安排。当前的互联网是用一种最平等但最简单的共享带宽方法发展起来的。以无偏见的方式支持现有的尽力而为服务,同时提供其他类别的服务,可能会给QoS方案增加巨大的复杂性。另一方面,如果保留的带宽不共享,可能会对我们今天所知道的互联网带宽的可用性产生重大影响。QoS可能会在网络中保留其他服务无法使用的带宽,从而导致带宽不足,即使可以预期该带宽在大部分时间内都未得到充分利用。再加上服务提供商想要出售商品带宽的动机,互联网带宽的可用性可能会面临巨大的压力。

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.

IP社区中当前关于定义提供QoS的机制的工作主要集中在一些特定的体系结构和一些新协议上。在以下部分中,我们将研究与当前知识产权社区工作相关的一些特定问题,因为它们与之前的讨论有关。本文档的目的不是作为这些工作的教程,而是确定与使用支持IP网络中某种形式的可分类服务的特定技术相关的一些支持问题。

6.2 QoS Service Management Scope
6.2 QoS服务管理范围

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

可以将QoS管理的讨论范围仅限于两个端点之间的路径配置。即使在这个有限的范围内,仍然存在许多未解决的问题。不期望两点之间的业务的QoS路径需要或应该在两个方向上相同。考虑到将有一个连接的发起人,如果返回路径是由不同的提供商(而不是连接的发起人)建立的,那么将有关于如何解决计费和记帐的问题。为了方便计费,需要存在一种方法,允许发起呼叫的应用程序也为返回路径和要进行的对方付费呼叫付费。第三方

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.

需要建立数据路径中各方信任的提供商,以确保计费和保证支付。利用基于IETF和非IETF协议构建的虚拟DCN服务,可以保护服务提供商和第三方验证系统之间的消息。信令协议对于确定呼叫成本以及谁将为其付费是必要的,并且每个提供商将需要一种可验证的方法来为所提供的服务计费。如前所述,该功能将类似于现有电话网络中使用的功能,但规模将大得多,并且可能涉及彼此具有高度竞争力的提供商。

7. The DiffServ Architecture
7. 区分服务体系结构

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.

以每跳为基础保证一类服务决不是以端到端为基础保证服务。如果不包括对带宽的保证以及端到端保证的延迟和错误率的定量界限,客户就不可能愿意为改进的服务水平付费。这将需要对网络中的路径进行工程设计,以实现所需的端到端结果。虽然提供此类服务的初始尝试很可能只指定特定的入口和出口边界,但为了健壮性和灵活性,希望有一个能够在没有此类限制的情况下支持此类服务的网络。与DiffServ体系结构相反,Intserv方法需要核心网络中的每流信息,因此可能无法扩展[11]。具有有限数量的服务类的DiffServ类型体系结构可以预先配置,并且在网络环境允许的情况下,可以进行修改以支持网络的实际动态。

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.

边缘路由器的高级功能需求在DiffServ体系结构中已经得到了很好的定义,但实现此功能的真正范围尚未得到很好的认可。虽然互联网的QoS体系结构与用于电信的电路交换网络之间存在着有趣的差异,但在电信领域学到的许多经验教训,即使它们可能没有什么其他作用,也应该能够提供一些关于实现这些需求所需努力水平的见解。具有讽刺意味的是,鉴于互联网界过去拒绝了为电信网络管理提出的标准化水平,如果能够提供所需的服务,那么可能是全服务互联网,实际上必须完成这些要求。

8. A Summary of the QoS Functional Areas
8. QoS功能领域概述

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管理将需要为应用程序和/或在访问、核心和行政区域边界提供功能。

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.

QoS流量功能将需要包括准入控制、身份验证和授权以及计费。验证流量是否在商定的参数和编程接口内,以便在服务超出商定的限制时提供建议。还需要提供服务验证、故障通知、重新实例化和终止的接口。

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.

需要在行政区域之间进行会计、服务信令和服务验证。在网络的管理边界处,将需要与边缘处提供的功能类似的功能。不同管理域中的对等实体将跨边界发出需求信号。然后,边界处的验证可能与边缘处的验证一致。可以测量通过边界的实际流量,并在域之间传输计费信息。中央管理职能部门将负责在发生故障时重新路由流量,或更好地利用现有网络资源。

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.

计费要求表明,流中的每个QoS服务提供商都需要第三方验证和验证功能。在交易功能的一端,需要批准定价和付款,而在另一端,需要有一个接口来提供定价信息,并针对付款需求提出付款请求。

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.

这些要求将引发一系列问题,其中最重要的是安全问题。在大多数情况下,将通过保护协议(如IPsec)和为控制信息建立专用网络来解决安全问题[6]。虽然在大多数情况下,创建一个物理上分离的DCN的成本太高,但可以创建一个提供相同安全优势的虚拟分离网络。IRTF服务管理研究组的未来工作打算详细研究这些需求。

9. Security Considerations
9. 安全考虑

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.

对于像服务管理体系结构这样复杂的问题,它与其他标准机构以及IETF的协议交互,似乎有必要记住总体情况,同时,将问题的特定部分划分为特定工作组进行标准化。因此,总体服务管理架构解决安全问题的要求并不一定意味着安全机制将在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
10. 总结

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.

IP网络中的服务管理模式已经从电信网络中采用。这些网络的服务模型之间的基本差异,如果这是现实的话,就会引起疑问。需要进一步分析,以确定什么是IP服务管理的适当范例,并为其定义一个通用词汇表。

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

IP社区目前非常积极地解决与传输QoS问题相关的问题。Diffserv、Intserv和策略工作组的工作说明了这些活动。相比之下,在与应用程序相关的服务问题上没有投入足够的精力。目前的解决方案是让应用程序内置自己的服务管理功能。这是

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.

IP社区需要专注于添加足够灵活的服务功能,以适应特定的应用程序需求,同时能够访问提供卓越应用程序功能所必需的服务信息。需要解决的主要问题涉及开发用于计费和安全的传输级服务。目录服务和扩展为定义AAA服务所做的工作是开发此所需功能的有希望的起点。

11. References
11. 工具书类

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

[1] L.Mathy,C.Edwards和D.Hutchison,“互联网:全球电信解决方案?”,IEEE网络,2000年7月/8月。

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

[2] B.Leiner等人,“互联网版本3.31的简史”,2000年8月4日修订。

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

[3] Eder,M.和S.Nag,“服务管理架构问题和审查”,RFC3052,2001年1月。

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

[4] Y.Bernet,“RSVP和差异化服务在全服务QoS网络中的互补作用”,IEEE通信杂志,2000年2月。

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

[5] Floyd,S.和L.Daigle,“开放可插拔边缘服务的IAB架构和政策考虑”,RFC 3238,2002年1月。

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

[6] 建议M.3010“电信管理网络的原则”,ITU-T,2000年2月。

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

[7] 建议M.3100“通用网络信息模型”,ITU-T,1995年7月。

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

[8] Moore,B.,Ellesson,E.,Strassner,J.和A.Westerinen,“政策核心信息模型——版本1规范”,RFC 3060,2001年2月。

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

[9] V.Jacobson,“互联网的差异化服务”,第二代互联网联合应用/工程QoS研讨会。

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

[10] Nichols,K.,Jacobson,V.和L.Zhang,“互联网的两位差异化服务架构”,RFC 2638,1999年7月。

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

[11] Mankin,A.,Baker,F.,Braden,B.,Bradner,S.,O'Dell,M.,Romanow,A.,Weinrib,A.和L.Zhang,“资源保留协议(RSVP)第1版适用性声明—关于部署的一些指南”,RFC 2208,1997年9月。

12. Authors' Addresses
12. 作者地址

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

美国马萨诸塞州伯灵顿韦赛德路5号迈克尔·埃德尔诺基亚研究中心01803

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

Sid Nag PO Box 104 Holmdel, NJ 07733, USA

美国新泽西州霍姆德尔104号希德纳格邮政信箱07733

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

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

美国马萨诸塞州伯灵顿路5号Hemant Chaskar诺基亚研究中心邮编01803

   Phone: +1-781-993-3785
   Fax:   +1-781-993-1907
   EMail: hemant.chaskar@nokia.com
        
   Phone: +1-781-993-3785
   Fax:   +1-781-993-1907
   EMail: hemant.chaskar@nokia.com
        
13. Full Copyright Statement
13. 完整版权声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

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.

RFC编辑功能的资金目前由互联网协会提供。