2007年B. A. Movsichpff、C. M. Lagoa以及H. Che等人，再度发表一份有关QoS、流量工程（traffic engineering；TE）以及错误修复（failure recovery；FR）的整合文章。距离2004年上次报告已有一段时日，QoS的发展现况因此值得关注。一方面是因为QNS（QoS network service）问题在IP网路上的解决标准迟未定案；其次由于IP网路所肩负的商业需求日渐重要。本文中我们将回顾目前网路上各标准主体对于此问题的看法，并深入分析ITU-T所提议的RACF一般化QoS架构。

网路服务品质保证的必要性

家庭化网路应用日益频繁，未来网路将和电视一样普及。在下一世代以网路（NGN）为基础的IP网路架构服务中，QoS（quality of service）便成为一项重要的关键技术。因为IP网路不像电路交换式网路（circuit-based network）一样，本身有一定品质保证机制。对IP网路而言，截至目前为止QoS的保证仍处在百家争鸣阶段，尚未有一个统一的端点式QoS标准出现。一个传统的QoS概念包含三个主要成员，分别是网路节点的QoS、网路策略／管理部分与QoS讯号，如(图一)所示。

《图一 传统的QoS概念示意图》

NGN QoS的复杂因素

不过NGN的QoS问题不只涉及此三部分，NGN的QoS问题之所以复杂，乃因其QoS控制机制会受到许多因素的影响。例如NGN网路的应用程式所需效能通常不一致，加上IP网路当时的设计，并不涵盖应用程式效能的概念，各种应用程式所适用的QoS机制不尽相同；端点对端点之间的路径通常会因为端点所需要的不同QoS需求而变；传送技术对QoS型态的支援差异以及不同网路营运商的营运自主性等因素。

IP网路标准发展始料未及

换句话说，端点式QoS标准的建立并未确定，IP网路的发展超乎当时的想像，IP网路本身并不提供端点式（end-to-end）的QoS品质保证机制，目前IP网路应用压力也越来越大。在这些应用里，许多方面是当时设计始料未及的，例如：IP语音服务、IP影像应用，IP多媒体服务、甚至是IP网路上的互动游戏（interactive game）等等。使用者若要能享受更好的服务品质，必须藉由其他额外机制辅助。

规划网路架构与回馈机制

于是，许多系统或网路服务供应商，便集中资源研究取得更多网路频宽的可用性，包含如何在一定品质下，减少使用频宽、或是如何让网路频宽变得更大，尤其是在Internet架构下，如何能取得更多频宽上的使用效益。

这种Internet网路架构包含封包式的即时流量与非即时流量，当网路传递有多种路径可供选择、并且网路上存有多个不同类别等级（classes of service；CoS）可供使用时，最佳化资料传输率与载入平衡法是最常被用来调整网路品质的手段之一。但是不同的调整方法往往需要不同的网路状态资讯回馈机制，来感知目前网路递送路径是否符合可用的QoS最低要求。

为使这些回馈资讯可常被系统使用，故网路资源也必须要规划保留一定频宽，使得真正可用的频宽又显得更少。因为各种网路应用型态具有本身上的差异，因此需要的品质要求也各不相同。为了解所需要的品质状态，设计人员需要借助相关评估方法，一般IP网路上的客观品质评估模型可参考(表一)所示。

使用来源端控管QoS品质

Movsichpff等人所提议的新方法，主要目的还是在解决之前所存在的问题，新方法引人瞩目，在于其只需要使用来源端的推理资讯、亦即考虑该传递路径目前是否拥塞，便可进行必要的QoS品质控管程序，可完成网路资源的最佳化使用，并利用发展资料传输率适应法则（data rate adaptation）来最大化可用资源。因为以最少资讯的方式掌控网路服务品质实属不易，目前所有方法仍存有网路之间通透性的问题。

IntServ与DiffServ架构

我们必须要了解有关保证网路品质的主要方法。一种使用的是整合服务（integrated services；IntServ）概念，另一种是差异性服务（differentiated services；DiffServ）概念。前者架构中的节点（nodes）需要取得一个流量状态（flow state），以调整服务所需的使用频宽；后者则不需要取得流量状态资讯，但是利用类别标记（class tag）方式，将相同流量特征归为一类，再由每个节点对不同的流量类型提供差异性服务，所以此方式可被用在大规模的网路架构中。相关IntServ与DiffServ的运作如(图二)所示。

《图二 IntServ与DiffServ运作架构示意图》

表面上看来，Internet可用DiffServ的概念来提供QoS服务，但事实上却非如此。因为DiffServ的应用必须要在网路流量处在不过载（under load）的条件下才能正确运作。然而实际上，Internet网路环境常有过载（overload）情形发生，且过载情形也导致一些封包被丢弃。

因此要在Internet上应用DiffServ概念，运作状况不一定较好，这点在A. Charny及JY Le Boude的研究中亦有相同发现，亦即当网路流量不过载时，DiffServ才能保证最大延迟限制。另外由I. Stoira及H. Zhang的报告看来，要能做到服务的保证，实作上相当复杂。为克服此问题，研究者提出许多在DiffServ架构下有关点对点服务品质的方法，许多均认为流量的控制有其必要，因为下一代网路型态乃以目前Internet网路架构为主。若使用特殊协定的网路例如多协定标记切换网路MPLS）虽无问题，不过一般封包式的IP网路上便会有问题，因为这些网路当时在设计之初并未考量之，因此解决方案迫在眉睫。

目前的QoS架构机制

概述

QoS的控制程序有多种实作方法，为达到较好的通透性，QoS控制机制必须被定义于相同的基础架构之上，现行许多QoS机制则建立于特殊传送技术或控制方法。为解决此问题，架构下一代NGN网路有许多标准制订主体参与，例如：ITU-T、ETSI、3GPP、IETF以及IEEE等等。有关IP网路的QoS架构讨论，远在2000年时IETF便已制订RFC 2990予以规范，但其架构只是提供给相关网路工作群组的一个参考，并非是真正网路上的标准架构。直到近几年，因新应用型态的需要，QoS的议题才又逐渐获得重视。但因为各家对于NGN的看法多有出入，因此许多标准制订主体多在自己所认可之NGN架构下，发展QoS的控制架构。

各家定义虽略有差异，一般而言NGN需具备封包式网路、宽频以及QoS感知的传送技术、服务功能与传送方式的独立性、享有自由存取网路（unfettered access to networks）及相关服务、或提供择一性与一般化的行动力（generalized mobility），以及随意服务等属性。

在参与下一代网路QoS标准制订上，主体通常有着不同的角色分配，例如ITU-T与ETSI便是制订网路架构与开发控制程序；另外IETF与IEEE则致力于网路第二层（layer 2）与第三层（layer 3）内特异问题的核心解决方案。 QoS的问题虽然广泛，但整合策略应该会比全新建立一个标准容易。这些标准多属针对特定问题的解决方案，因此当ITU-T的一般化QoS架构完成后，将可涵盖其他标准主体所制订的QoS标准。

综合以上，法国电信（France Telecom）便提议一种结合IntServ与DiffServ架构、称为流量感知网路（flow-aware network；FAN）的方法。其中边界节点只会在网路负载超过一个门槛时，才会将那些超量封包予以丢弃。此外，电子与电信通讯研究所（Electronics and Telecom communication Research Institute；ETRI）与英国电信（British Telecom；BT）等机构，则提议另一种流量状态感知（flow state aware）技术，其中将Internet服务区分为许多不同的服务类型等级（CoS），并针对这些型态加以定义需求条件与控制程序。

控制架构之比较

目前有数种QoS的提议架构，在此我们将常见部分整理如(表二)所示。

大多数QoS架构在处理端点式的QoS问题，尤其是成本敏感的企业应用而言。这种新系统大多数会先存在于企业模式，企业对企业（E2E）的端点式QoS架构主要应用范围是以ITU-T架构下的网路多媒体应用为基础，然后逐渐推广到一般大众可负担的范围。为使QNS可以普及广受支持，建立一般化的标准架构建立势在必行。

ITU-T的RACF标准

在ITU-T NGN架构的一个重要概念，便是分别独立传送组织层与服务组织层，借此，网路资源需求与服务的可信度主要发生于在网路端，由服务组织层依据客户的要求来决定。换句话说，传送组织层主要是负责封包的前导与流量控制；而服务组织层主要是负责应用程式的讯号（application signaling），可被视为一个简易的应用伺服器（application server）。

因此传送组织层只关心不同型态封包的传送问题，所有传送控制的功能，都被放在传送组织层，这些传送功能利用控制介面与服务组织层相连结。对于是否允许加入所要求的服务，要视当时网路策略与资源可用性来决定。此外，一旦服务要求被接受后，也同时控制了网路资源的分配。另外服务组织层所关心的是封包的负载费用（payload），至于服务型态与传送方法之间并无密切关联性。

ITU-T的RACF依据营运策略与网路资源可用性原则，负责决定服务加入（admission）以及传送功能上的资料控制。有关ITU-T对于NGN所制订之传送与服务架构颇为复杂，如(图三)所示。

《图三 ITU-T对于NGN所制订之传送与服务架构示意图》

TCF

传送控制功能（transport control function；TCF）主要是当作两个组织面的一种调停机制，可以依据当时的网路资源状态或是网路提供者策略，决定客户所提出的服务要求是否被接受。因此，RACF可以视为一种可以决定网路资源及适当控制网路成员的集合功能体。

SCF

服务控制功能（service control function；SCF）则是负责建立应用程式讯号，当SCF传送一个QoS要求给RACF时，RACF会侦测QoS是否可被接受，然后藉由控制网路元件的方式，保留所需要的网路资源。 SCF在应用层发讯时，会去改变位址资讯（address information）。 PD-FE会去确认NAPT的控制是否有其必要性，再去控制网路边界装置的PE-FE，修改资料封包的IP位址。

NACF

另外，存取网路内存有一种称为网路附属控制功能（network attachment control function；NACF），可被用来支援验证使用者的一些特性资料。在呼叫建立的过程中，NACF会依据存取网路中订户的最大可用频宽，来对相关要求进行确认。通常不管在存取网路或是核心网路，RACF的功能架构均大同小异。

静态和动态QoS控制架构

不同的网路型态有不同的控制方法或传送技术，QoS控制机制可分为静态或动态。静态的QoS控制架构，控制资讯常被存放在网路装置的架构档（configuration file）。例如家庭网路装置的电源被启动或架构被管理系统更改时，QoS便会起始化设定，亦即家庭中的门闸（gateway）QoS设定可以被架构档或远端管理系统所侦测，这类型QoS控制架构可以参考DSL论坛的架构。

另外动态的QoS控制架构是在两端利用呼叫设定讯号（call set-up signaling）进行连线时，同时也可对网路的可用资源进行分配与控制。在Cable Lab的QoS控制机制，同时考量了静态与动态QoS控制方法，在架构服务环境的同时也能建立基本服务，并利用QoS讯号来取得动态的额外服务需求，相对于ITU-T与ETSI／ TISPAN所定义的QoS机制有所不同。

ITU-T与ETSI所定义的QoS架构焦点主要放在动态QoS控制上。因此，传送与服务的独立性便显得重要。动态QoS应用端程式的要求讯号可能会动态改变，因此传送架构必须要保留一些网路频宽给这些QoS要求使用。不过在发展RACF与RACS（resource and admission control subsystem）时，均有考量DSL环境，因此这些DSL环境亦可直接套用动态QoS控制策略。但RACF体系架构仍嫌庞大，或许因为要考量不同网路通透性的关系。此外，在RACF的一般化架构里，仍有一些问题尚待解决。

（本文下期将继续探讨RACF需面对的问题，与RACF的功能与功能体，欢迎读者持续锁定。）