rfc2475.txt

RFC文档

G.1：一个标准PHB 必须从为标准映射保留的编码区域内[DSFIELD]，选择一个推荐的
DS编码点。推荐的编码点由IANA指定。一个PHB提议可以从EXP/LU空间内选取一个临
时编码点，以便进行域间实验。注意，不能要求检查包头除DS域以外的信息域来确定该数据
包所对应的PHB。
G.2：每一个新提出的PHB组规范应该包括其行为及行为目的的概述。概述中应包括此
PHB组要解决的问题的描述。还应包括此PHB组涉及的基本概念。这些概念应包括，但不仅
限于，队列行为，丢弃行为，和输出链路选择行为。最后，概述中应阐明此PHB组解决所描
述问题的方法。
G.3：PHB组规范应说明其包括的单个PHB的个数。当PHB组包括多于一个PHB时，
PHB组规范就必须对这些PHB间的交互和限制做出详细说明。例如，规范必须说明如果同一
微流中不同的数据包被标记为此组中不同的PHB时，数据包被重新排序的可能性是否会增
大。
G.4：如果PHB组的特定功能依赖于某些外部限制，比如服务提供限制，那么PHB定义
中，就必须说明当这些限制被违反时，此PHB所产生的行为。更进一步，如果这些限制被违
反时，又需要采取类似包丢弃或重标记的行为，那么这些行为应被特别规定。
G.5： 一个PHB组可能被指明为仅在一个域内局部使用。其作用是在域内提供面向特定
域的功能或服务。在这种情况下，PHB规范有助于向服务提供者提供一份关于此PHB组的一
致性定义。然而，任何只定义为局部使用的PHB组，不能进行标准化。但是，它们可以作为
知识性RFC文档发表。相反的，作为通用的PHB组，就必须经过严格的标准化过程。所以，
所有的PHB组提议都必须明确指明其用途是通用的还是局部的。
PHB组可能被设计来提供主机到主机，WAN边界到WAN边界，和/或域边界到域边界服
务。出于一致性考虑，在PHB定义中使用“端到端（host to host）”应被理解为“主机到
主机”。
由于实验或操作要求，在域内还可以定义和配置其它PHB组。这些局部有效的PHB组并
不需要公开定义，但是它们应使用EXP/LU空间的编码点（[DSFIELD]中定义）。
G.6：被标记为PHB组中某个PHB的数据包，有可能在域中或域边界处，重标记为同
PHB组中的另一个PHB。有三种典型情况需要这种转换：
a.	与此PHB组对应的编码点，也被用来携带网络状态信息。
b.	需要提升或降低数据包的PHB的情况。（如果组内的PHB可进行某种排序）
c.	域边界处缺少SLA。这种情况下，数据包通过边界链路时的编码点/PHB根据上游域
的局部策略决定。
PHB规范应该清楚的说明数据包被重标记（例如，提升或降低）为本组中另一个PHB的
情况。如果某些情况下不能改变数据包的PHB，那么规范中必须清楚说明此时改变PHB的后
果。改变数据包的PHB（无论改为同组的，还是不同组），可能引起的后果之一是，对微流中
数据包重新排序的可能性增加。PHB可能携带某些主机到主机，WAN边界到WAN边界，和
/或域边界到域边界的语义，这些语义很难在数据包重标记为组内（或其它组）另一个PHB时
保存下来。
对于某些PHB组，可以通过重标记数据包为组内其它PHB来反映节点状态的变化。如果
一个PHB组被设计来反映网络状态，那么在相应的PHB规范中，就必须详述组中各个PHB
与其反映的网络状态之间的联系。此外，如果这些PHB对节点转发行为有所限制，那么这些
限制可以被表达为节点应当，或必须执行的行为。
G.7：PHB组规范中应包括一节说明隧道技术在本组的应用。此节应说明当数据包被封装
入隧道后，如何根据其内层包头的DS域，来确定外层包头DS域。还应说明，在隧道出口
处，内层包头应做如何的改变。（参见 6.2节）。
G.8：定义PHB组是一个增量式的过程。当定义新的PHB组时，应说明它如何与已定义
的PHB组协调。每一个新建立的PHB组，其作用的范围可能是全新的，也可能是已有PHB
组的扩展。如果一个PHB组完全独立于某些或全部已有PHB组规范，那么在其规范中应有一
节详述它如何与已经标准化的PHB组共存。例如，这一节中应该说明当微流中的数据包被标
记为与两个不同PHB组都相关的编码点时，它们被重排序的可能性有多大。如果在同一节点
中同时操作两个（或更多）PHB组不可能或是有害的，这种情况必须在此节中说明。如果节点
在处理同时收到的被标记为两个（或更多）PHB组的多个数据包时，需采取某些特殊动作，那
么这些特殊动作也应在此节说明。
定义PHB组时，应注意避免循环定义。
如果提议中的PHB组是已有的某个PHB组的扩展，那么规范中应包括一节详述此PHB
组如何与被扩展PHB组交互。更进一步，如果此PHB组改变或更狭义的定义了某些已有行
为，这些情况也应在规范中说明。
G.9：每个PHB规范都应包括一节阐述实现此PHB组的最小一致性需求。这一节主要目
的是提供此PHB组实现时容许变化的行为的变动范围。这一节可以采用规则，表格，伪代
码，或测试的形式叙述。
G.10：PHB规范应包括一节详述其行为的安全性。此节应包括对在隧道出口改变内层包
头的编码点，以及这种改变对数据包转发行为的影响的讨论。
另外，此节还应讨论提议的PHB组如何被用在拒绝服务攻击，减少服务协议攻击，和违
反服务协议攻击。最后，此节应讨论检测这些攻击的可能方案。
G.11：PHB规范中应包括一节详述配置和管理问题。这些问题可能影响PHB的操作和使
用此PHB的候选服务。
G.12：强烈建议每个PHB规范都提供一个附录，详述其对现有服务和潜在服务提供的服
务行为特征。这些服务包括但不限于用户特定的，设备特定的，域特定的或端到端的服务。强
烈建议附录中包括一节描述用户，设备，和/或域如何验证这些服务。
G.13：建议每个PHB规范提供一个附录。此附录面向域内部使用，提供本域向不支持此
PHB组的对等域转发数据包时选择何种PHB的指导。
G.14：建议每个PHB规范提供附录说明提议的PHB组对已有的高层协议的影响。在某
些情况下，PHB允许对高层协议做可能的改变，这些改变可能增加，也可能减少提议的PHB
组的使用。
G.15：建议每个PHB规范提供附录，对使用共享媒体或交换的链路层提供从PHB到链
路层QoS机制映射的建议。在PHB和链路层QoS机制之间进行适当的映射涉及许多因素，
这个问题已超出本文档的论述范围；然而，在PHB规范中应设法给出一些指导。

4	与非分类业务兼容节点的互操作
我们把非分类业务兼容节点（non-DS-compliant node）定义为任何不会根据
[DSFIELD]描述译解DS域，和/或没有实现部分或全部标准化PHB组（或只在特定DS域使
用的PHB组）的节点。这可能域节点的能力或配置有关。我们把遗留节点（legacy node）定
义为非分类业务兼容节点的特殊情况，这些节点实现了IPv4优先级和[RFC791，RFC1812]
定义的转发策略，但在其它方面是非分类业务兼容的。在[DSFIELD]中定义的等级选择编码点
（Class Selector Codepoints）被特别考虑，保持与IPv4中TOS字节定义的优先值兼容，
同时，在[DSFIELD]中定义的等级选择PHB也与[RFC791，RFC1812]定义的优先转发行为
相兼容。遗留节点和分类业务兼容节点之间的关键区别在于，遗留节点可能，也可能不译解
[RFC1349]定义的TOS字节的3-6比特（“DTRC”比特）；实际上它不会译解[DSFIELD]
指定的那些比特。我们假设使用[RFC1349]中定义的TOS标记是被反对的。注意，那些不是
遗留节点的非分类业务兼容节点，在转发带有非零DS编码点的数据包时，其转发行为是不可
预测的。
分类业务依赖于基于在节点上实现每一跳行为的资源分配机制。如果业务流穿过非分类业
务兼容节点或无分类业务能力域，那么服务的质量或统计确保水平很可能会下降。
我们讨论两种情况。第一种情况关于在DS域中使用非分类业务兼容节点。注意，PHB转
发主要是在对稀有节点和链路资源进行有控制的分配时有用。在高速，轻载荷链路上，最坏包
延迟，抖动，和丢失都是可以忽略的，并且，在这样的链路上游使用非分类业务兼容节点不会
造成服务降级。在多数实际情况下，一个节点缺少PHB转发支持会导致无法对通过此节点的
数据流提供低时延，低丢包率服务，或预定服务带宽。然而，如果在DS域中能够仅使用
[DSFIELD]定义的等级服务编码点，并且在遗留节点上的优先级实现方案与路径上的其它节点
的转发行为兼容，那么在无法兼容分类业务的节点处使用遗留节点就会是一个较好的替代方
案。注意，由于遗留节点可能，也可能不会根据[RFC1394]译解第3-5比特，从而导致不可预
测的转发行为，所以，必须限制只使用等级选择编码点。
第二种情况关于穿越无DS能力域（non-DS-capable domain）的服务行为。出于讨论
目的，我们假定无DS能力域不会在域边界节点处进行业务量调节；因此，即便在域内存在遗
留节点或DS兼容节点的情况下，由于在边界处缺少业务量管理，也会限制本域，使之不能稳
定提供某些服务。DS域和无DS能力域之间可以就如何在进入无DS能力域之前在DS域出
口处标记数据包达成协议。这个协议可通过业务量采样而不是严格的业务量调节确保实施。 如
果已知无DS能力域中包含遗留节点，那么上游DS域可以选择将分类业务流重标记为一个或
多个等级选择编码点。如果对下游域的业务量管理能力一无所知，而且缺少域间协议，那么
DS出口节点可以选择将DS编码点重标记为零，并假设无DS能力域会平等对待所有业务
流，遵从尽力而为原则转发。
在无DS能力域与DS域对等的情况下，来自无DS能力域的业务流应在DS域入口节点
处根据适当的SLA或其它协议进行调节。


5	关于组播
对组播业务使用分类业务机制引入很多问题。首先，在某个DS域入口节点进入的组播数
据包可能会被复制，然后通过多条不同的路径穿越此DS域。这种情况下，组播业务就会比单
播业务消耗更多的网络资源。由于组播成员是随时变化的，因此很难预测从上游网络来的某一
组播业务会消耗本域的多少网络资源。这种不确定性的后果之一就是很难向组播业务提供者提
供定量服务保证。此外，有必要为单播业务保留编码点和PHB，以便提供不受组播干扰的资
源。
第二个问题是到达DS入口点的组播数据包如何选择DS编码点。组播数据包可能在多个
出口节点流出DS域，每个出口节点都对应一个下游DS域，和相应的SLA。应注意组播数据
包的编码点不能违反任何一个SLA。当为从某一入口节点进入的请求分类服务的组播业务流建
立分类器和业务量调节器状态时，应该考虑到相应的下游DS域标识和SLA细节（使之服从路
由策略及路由体系的稳定性）。这样相应的下游DS域SLA可以部分的在上游DS域入口点处
得以履行，从而减轻上游域入口点的分类和业务量调节负担。当然，在组播业务中采取这样的
方法很困难，因为组播成员是动态变化的。结果是单播业务的服务保证会受到影响。解决此问
题的一种方案是，为组播业务创建单独的SLA，并且或者让组播业务采用特殊的一系列编码
点，或者在DS出口点实现必要的分类和业务量调节机制，根据下游域SLA将单播业务优先分
离，提供服务。

6	安全和隧道问题
这一节主要讨论由于引入分类业务而引起的安全问题，主要是拒绝服务攻击隐患，和通过
未授权业务窃取服务隐患（参见6.1）。另外，在IPsec条件下分类业务的操作和与IPsec交
互问题也有讨论（参见6.2节）。审查需求也在6.3 节有所讨论。本节讨论的问题包括由
IPsec和非IPsec隧道引入的。

6.1	窃取和拒绝服务
分类业务的主要目的是在统一的网络体系结构上，向业务流提供不同级别服务。很多资源
管理技术被用来完成这一目标，最终的结果是有些数据包会受到不同的（例如，更好的）服
务。把网络业务映射到特定的行为集合从而取得不同的（或好或坏）服务，主要依靠设定DS
域。随之而来的问题就是，可以通过把DS域修改为代表更高优先级的编码点，或者直接注入
DS域置为这些编码点的数据包而获得更好的服务。在极端情况下，如果修改或者注入的数据
包耗尽了网络资源，这种窃取服务行为就演变成拒绝服务攻击。解决方案包括综合使用在DS
边界节点进行业务量调节和增强DS域内网络结构的安全性和完整性。
如第2节描述，DS入口节点必须调节所有进入DS域的业务流，以确保它们带有可接受
的DS编码点。就是说编码点必须符合适用的TCA和域服务提供策略。因此，入口节点是防止
基于修改DS编码点（例如，改为此业务流无权的DS编码点）的窃取和拒绝服务攻击的主要
战线。因为，任何这样的攻击都会违反TCA和/或服务提供策略。一种重要类型的入口节点是
在DS域中可以发起业务的节点。必须保证任何发起的业务都带有可接受的DS编码点。
域服务提供策略和TCA都可能要求入口节点改变某些流入数据包的DS编码点（例如，
入口路由器可能根据适当的SLA设置用户业务流的DS编码点）。入口节点必须调节所有的业
务流以保证DS编码点是可接受的；带有不可接受编码点的数据包必须或者被丢弃，或者将其
DS编码点在转发前改为可接受值。例如，入口节点可能会将从与之无增强业务协议的域收到
的业务流DS编码点设置为缺省PHB编码点[DSFIELD]。某些DS编码点的适用可能需要特
别的业务授权（例如，那些对应于增强业务的编码点），并且这类授权可以采用技术方法
（如，IPsec）和/或非技术方法（如，固定连接到唯一客户的入口链路）。
域间协议可以使上游域部分或全部保证业务流带有下游域可接受的DS编码点，从而降低
入口节点进行业务量调节的要求。这种情况下，入口节点仍可以进行业务量调节检查，以避免
对上游域的依赖（例如，这类检查可以防止跨越域边界传播的窃取服务攻击）。如果由于上游
域未能履行其责任，导致业务流未能通过入口节点检查，那么这一审查事件必须被记录；记录
项包括接收到数据包的日期/时间，源和目的IP地址，和导致未通过此检查的DS编码点值。
实际中，需要在这类检查的好处和它们对系统性能的影响之间做出权衡，确定到底哪些情况需
要检查。
DS域内部节点依赖于DS段向要求分类业务功能的业务流提供服务。节点必须依靠正确
的DS域操作来防止带有不可接受DS编码点的业务流到达。健壮性考虑要求带有不可接受
DS编码点数据包的到达不会引起网络节点瘫痪。内部节点没有义务监督服务提供策略SLA的
执行情况，也不需要对DS编码点进行检查。内部节点可以对DS编码点执行某些业务量调节
检查（例如，检查出在某条特定链路上从不会使用的编码点），从而提高节点安全性和健壮性