DS:差异化服务架构

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 本备忘录为 Internet 社区提供信息。它没有指定任何类型的 Internet 标准。本备忘录的分发不受限制。

640.gif


RFC2475:An Architecture for Differentiated Services,December 1998


本备忘录的状态


本备忘录为 Internet 社区提供信息。它没有指定任何类型的 Internet 标准。本备忘录的分发不受限制。


版权声明


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


梗概


本文档定义了在 Internet 中实现可扩展服务差异化的体系结构。该架构通过聚合流量分类状态来实现可扩展性,该状态通过使用 DS 字段 [DSFIELD] 的 IP 层数据包标记来传达。数据包被分类和标记以在其路径上的节点上接收特定的每跳转发行为。复杂的分类、标记、监管和整形操作只需在网络边界或主机上实施。网络资源通过服务供应策略分配给流量流,该策略控制流量在进入具有差异化服务能力的网络时如何标记和调节,以及流量如何在该网络内转发。可以在这些构建块之上实施各种各样的服务。


1、 介绍


1.1、 概述


本文档定义了在 Internet 中实现可扩展服务差异化的体系结构。“服务”定义了跨网络内一组一条或多条路径在一个方向上的数据包传输的一些重要特征。这些特性可以通过吞吐量、延迟、抖动和/或损失的定量或统计术语来指定,或者可以其他方式根据对网络资源的访问的某些相对优先级来指定。需要服务差异化以适应异构应用需求和用户期望,并允许互联网服务的差异化定价。


该架构由在网络节点中实现的许多功能元素组成,包括一小组每跳转发行为、数据包分类功能和流量调节功能,包括计量、标记、整形和监管。该架构通过仅在网络边界节点实现复杂的分类和调节功能,并将每跳行为应用于已使用 IPv4 或 IPv6 报头 [DSFIELD] 中的 DS 字段适当标记的流量聚合来实现可扩展性。每跳行为被定义为允许在竞争流量流之间的每个节点上分配缓冲区和带宽资源的合理粒度方法。每个应用程序流或每个客户转发状态不需要在网络核心内维护。保持以下区别:


* 提供给流量聚合的服务,

* 用于实现服务的条件函数和每跳行为,

* 用于标记数据包以选择每跳行为的 DS 字段值(DS 代码点),以及

* 实现每跳行为的特定节点实现机制。


业务提供和流量调节策略与网络内部的转发行为充分解耦,允许实现多种业务行为,并有未来扩展的空间。


这种架构仅在一个流量方向上提供服务差异化,因此是不对称的。互补对称架构的开发是当前研究的主题,但超出了本文档的范围;参见例如 [EXPLICIT]。


第1.2章节是本文档中使用的术语表,第1.3章节列出了此架构所解决的要求,第1.4章节提供了与其他服务差异化方法的简要比较。第2章节详细讨论了架构的组件。第3章节提出了每跳行为规范的指导方针。第4章节讨论了与未实现本文档和 [DSFIELD] 中定义的差异化服务的节点和网络的互操作性问题。第5章节讨论了组播服务交付的问题。第6章节解决了安全和隧道方面的考虑。


1.2、 术语


本节给出了本文档中使用的术语的一般概念概述。本文档后面的部分对其中一些术语进行了更精确的定义。


行为聚合 (Behavior Aggregate,BA)


DS 行为聚合。


BA分类器


仅根据 DS 字段的内容选择数据包的分类器。


边界链路


连接两个域的边缘节点的链路。


分类器


根据定义的规则根据包头的内容选择包的实体。


DS行为聚合


具有相同 DS 代码点的数据包集合,沿特定方向穿过链路。


DS边界节点


将一个 DS 域连接到另一个 DS 域或不支持 DS 的域中的节点的 DS 节点。


DS 能力


能够实现本架构中描述的差异化服务;通常用于指由符合 DS 的节点组成的域。


DS代码点


DS 字段的 DSCP 部分的特定值,用于选择 PHB。


符合 DS 标准


能够支持 [DSFIELD]、本文档和其他差异化服务文档中定义的差异化服务功能和行为;通常用于指代节点或设备。


DS域


一个支持 DS 的域;一组连续的节点,这些节点使用一组通用的服务提供策略和 PHB 定义进行操作。


DS出口节点


DS 边界节点在其离开 DS 域时处理流量的角色。


DS入口节点


DS 边界节点在其进入 DS 域时处理流量的角色。


DS内部节点


不是 DS 边界节点的 DS 节点。


DS字段


当按照 [DSFIELD] 中给出的定义进行解释时,IPv4 报头 TOS 八位字节或 IPv6 流量类八位字节。DSCP 字段的位对 DS 代码点进行编码,而其余位当前未使用。


DS节点


符合 DS 的节点。


DS区


一组连续的 DS 域,可以通过跨这些 DS 域的路径提供差异化服务。


下游DS域


边界链路上流量下游的 DS 域。


丢弃设备


执行丢弃的设备。


丢弃


根据指定规则丢弃数据包的过程;策略。


遗留节点


实现 [RFC791,RFC1812] 中定义的 IPv4 优先级但不符合 DS 的节点。


标记器


执行标记的设备。


打标


根据定义的规则在数据包中设置 DS 代码点的过程;预先标记,重新标记。


机制


在节点中实现的特定算法或操作(例如,排队规则)以实现一组一个或多个每跳行为。


计量器


执行计量的设备。


计量


测量分类器选择的流量流的时间属性(例如,速率)的过程。该过程的瞬时状态可用于影响标记器、整形器或投放器的操作,和/或可用于计数和测量目的。


微流


应用程序到应用程序数据包流的单个实例,由源地址、源端口、目标地址、目标端口和协议 ID 标识。


MF分类器


一个多字段 (multi-field,MF) 分类器,它根据任意数量的报头字段的内容来选择数据包;通常是源地址、目标地址、DS 字段、协议 ID、源端口和目标端口的某种组合。


每跳行为 (Per-Hop-Behavior,PHB)


在符合 DS 的节点上应用到 DS 行为聚合的外部可观察转发行为。


PHB组


由于适用于集合中所有 PHB 的共同约束(例如队列服务或队列管理策略),一组一个或多个 PHB 只能有意义地同时指定和实施。PHB 组提供了一个服务构建块,允许将一组相关的转发行为一起指定(例如,四个丢弃优先级)。单个 PHB 是 PHB 组的特例。


策略


根据执行流量配置文件的相应计量器的状态,丢弃流量流中的数据包(通过丢弃器)的过程。


预标记


在进入下游 DS 域之前设置数据包的 DS 代码点。


提供者 DS 域


向源域提供 DS 服务的提供者。


重标记


更改数据包的 DS 代码点,通常由标记根据 TCA 执行。


服务


在 DS 域或端到端中对定义的客户流量子集的整体处理。


服务水平协议 (Service Level Agreement,SLA)


客户与服务提供者之间的服务合同,其中规定了客户应获得的转发服务。客户可能是一个用户组织(源域)或另一个 DS 域(上游域)。SLA 可能包括流量调节规则,这些规则构成了 TCA 的全部或部分内容。


服务提供策略


定义如何在 DS 边界节点上配置流量调节器以及如何将流量流映射到 DS 行为聚合以实现一系列服务的策略。


整形器


一种执行整形的设备。


整形


延迟流量流中的数据包以使其符合某些定义的流量配置文件的过程。


源域


一个域,其中包含发起接收特定服务的流量的节点。


流量调节器


执行流量的实体


调节


函数,其中可能包含仪表、标记、滴管和整形器。流量调节器通常仅部署在 DS 边界节点中。流量调节器可以重新标记流量流,或者可以丢弃或整形数据包以改变流的时间特性并使其符合流量配置文件。


流量调节控制


为强制执行 TCA 中指定的规则而执行的功能,包括计量、标记、整形和监管。


流量调节协议 (Traffic Conditioning Agreement,TCA)


协议指定分类器规则和任何相应的流量配置文件以及计量、标记、丢弃和/或整形规则,这些规则将应用于分类器选择的流量流。TCA 包含在 SLA 中明确指定的所有流量调节规则以及从相关服务要求和/或从 DS 域的服务供应策略中隐含的所有规则。


流量概况


流量流的时间属性的描述,例如速率和突发大小。


流量流


一组具有管理意义的一个或多个穿过路径段的微流。流量流可能由一组由特定分类器选择的活动微流组成。


上游DS域


边界链路上流量上游的 DS 域。


1.3、 要求


Internet 的历史一直是主机数量、应用程序的数量和种类以及网络基础设施容量不断增长的历史之一,并且在可预见的未来预计这种增长将持续下去。用于服务差异化的可扩展架构必须能够适应这种持续增长。


在此架构中确定并解决了以下要求:


* 应适应各种服务和供应策略,端到端扩展或在特定(组)网络内扩展,


* 应该允许服务与正在使用的特定应用程序分离,


* 应与现有应用程序一起使用,无需更改应用程序编程接口或主机软件修改(假设分类器、标记和其他流量调节功能的适当部署),


* 应将流量调节和服务提供功能与核心网络节点内实现的转发行为分离,


* 不应依赖于逐跳应用信令,


* 应该只需要一小组转发行为,其实现复杂性不会主导网络设备的成本,并且不会为未来的高速系统实现带来瓶颈,


* 应避免核心网络节点内的每个微流或每个客户的状态,


* 应仅利用网络核心内的聚合分类状态,


* 应允许在核心网络节点(BA 分类器)中实现简单的数据包分类,


*应允许与非 DS 兼容网络节点的合理互操作性,


* 应适应增量部署。


1.4、 与其他方法的比较


本文档中指定的差异化服务架构可以与其他现有的服务差异化模型进行对比。我们将这些替代模型分为以下几类:相对优先级标记、服务标记、标签交换、综合服务/RSVP 和静态每跳分类。


相对优先级标记模型的示例包括 [RFC791] 中定义的 IPv4 优先级标记、802.5 令牌环优先级 [TR] 和 802.1p 流量类别的默认解释 [802.1p]。在该模型中,应用程序、主机或代理节点为数据包选择一个相对优先级或“优先级”(例如,延迟或丢弃优先级),传输路径上的网络节点应用与优先级值相对应的适当优先级转发行为在数据包的标头内。我们的架构可以被视为对该模型的改进,因为我们更清楚地指定了边界节点和流量调节器的作用和重要性,并且因为我们的每跳行为模型允许比相对延迟或丢弃优先级更通用的转发行为。


服务标记模型的一个例子是 [RFC1349] 中定义的 IPv4 TOS。在这个例子中,每个数据包都标有对“服务类型”的请求,其中可能包括“最小化延迟”、“最大化吞吐量”、“最大化可靠性”或“最小化成本”。网络节点可以选择经过适当设计以满足服务请求的路由路径或转发行为。这个模型与我们的架构略有不同。请注意,我们没有描述使用 DS 字段作为路线选择的输入。[RFC1349] 中定义的 TOS 标记是非常通用的并且不跨越可能的服务语义的范围。此外,服务请求与每个单独的数据包相关联,而某些服务语义可能取决于数据包序列的聚合转发行为。服务标记模型不容易适应未来服务数量和范围的增长(因为代码点空间很小)并且涉及在每个核心网络节点中配置“TOS->转发行为”关联。标准化服务标记意味着标准化服务产品,这超出了 IETF 的范围。请注意,在 DS 代码点空间的分配中进行了规定,以允许提供者可以使用本地重要的代码点来支持服务标记语义 [DSFIELD]。


标签交换(或虚拟电路)模型的例子包括帧中继、ATM 和 MPLS [FRELAY, ATM]。在此模型中,路径转发状态和流量管理或 QoS 状态是为网络路径上每一跳上的流量流建立的。不同粒度的流量聚合与入口节点处的标签交换路径相关联,每个标签交换路径内的数据包/信元都标有转发标签,用于查找下一跳节点、每跳转发行为、以及每一跳的替换标签。该模型允许对流量流进行更细粒度的资源分配,因为标签值不是全局重要的,而仅在单个链路上重要;因此,可以为在具有特定标签的链路上接收到的数据包/信元的聚合保留资源,并且标签交换语义控制下一跳选择,允许流量流遵循专门设计的路径通过网络。这种改进的粒度以建立和维护标签交换路径的额外管理和配置要求为代价。此外,在最佳情况下(假设多点对点标签交换路径),每个节点维护的转发状态量与网络边缘节点的数量成正比,并与网络边缘节点的平方成正比。最坏情况下的边缘节点数量,当采用具有预配资源的边缘-边缘标签交换路径时。


集成服务/RSVP 模型在默认情况下依赖于传统的数据报转发,但允许源和接收器交换信令消息,这些消息在它们之间路径上的每个节点上建立额外的数据包分类和转发状态 [RFC1633,RSVP]。在没有状态聚合的情况下,每个节点上的状态量与并发预留的数量成比例,这在高速链路上可能会很大。该模型还需要应用程序支持 RSVP 信令协议。可以利用差异化服务机制来聚合网络核心 [Bernet] 中的集成服务/RSVP 状态。


集成服务/RSVP 模型的一个变体通过仅利用在网络路径上的每个节点中实施的“静态”分类和转发策略,消除了对逐跳信令的要求。这些策略在管理时间尺度上更新,而不是响应网络中活跃的微流的瞬时混合。此变体的状态要求可能比使用 RSVP 时遇到的情况更糟糕,尤其是在骨干节点中,因为随着时间的推移可能适用于节点的静态策略的数量可能大于活动的发送方-接收方会话的数量。可能在节点上安装了保留状态。尽管支持大量分类器规则和转发策略在计算上可能是可行的,但与在可能被业务流穿越的骨干网络中的每个节点上安装和维护这些规则相关的管理负担是巨大的。


尽管我们将我们的架构与这些服务差异化的替代模型进行了对比,但应该注意的是,使用这些技术的链路和节点可用于跨2层交换基础设施(例如,802.1p LAN、帧中继/ATM 主干)扩展差异化服务行为和语义互连 DS 节点,并且在 MPLS 的情况下可以用作替代的域内实现技术。在 DS 域的特定区域(或在提供对 DS 域的访问的网络中)使用特定链路层技术所施加的限制可能意味着在更粗粒度的基础上区分流量。根据 PHB 到不同链路层服务的映射以及在一组受限优先级(或不同类别和容量的虚拟电路)上调度数据包的方式,所有或部分使用中的 PHB 可能是可支持的(或可能无法区分)。


2、 差异化服务架构模型


差异化服务架构基于一个简单的模型,其中进入网络的流量被分类并可能在网络边界进行调节,并分配给不同的行为聚合。每个行为聚合都由单个 DS 代码点标识。在网络核心内,根据与 DS 代码点关联的每跳行为转发数据包。在本节中,我们将讨论差异化服务区域内的关键组件、流量分类和调节功能,以及如何通过流量调节和基于 PHB 转发的组合来实现差异化服务。


2.1、 差异化服务领域


DS 域是一组连续的 DS 节点,这些节点以公共服务提供策略和在每个节点上实施的一组 PHB 组运行。DS 域有一个明确定义的边界,由 DS 边界节点组成,这些节点对入口流量进行分类和可能的调节,以确保通过该域的数据包被适当标记,以从域内支持的 PHB 组之一中选择一个 PHB。DS 域内的节点根据其 DS 代码点选择数据包的转发行为,使用推荐的代码点->PHB 映射或本地自定义映射 [DSFIELD] 将该值映射到支持的 PHB 之一。在 DS 域中包含不符合 DS 的节点可能会导致不可预测的性能,并可能妨碍满足服务级别协议 (SLA) 的能力。


DS 域通常由同一管理下的一个或多个网络组成;例如,组织的 Intranet 或 ISP。域的管理负责确保提供和/或保留足够的资源来支持域提供的 SLA。


2.1.1、 DS 边界节点和内部节点


DS域由DS边界节点和DS内部节点组成。DS 边界节点将 DS 域与其他 DS 或不支持 DS 的域互连,而 DS 内部节点仅连接到同一 DS 域内的其他 DS 内部或边界节点。


DS 边界节点和内部节点都必须能够根据 DS 代码点对数据包应用适当的 PHB;否则可能会导致不可预测的行为。此外,DS 边界节点可能需要执行由它们的 DS 域和它们连接到的对等域之间的流量调节协议 (TCA) 定义的流量调节功能(参见第 2.3.3 节)。


内部节点可能能够执行有限的流量调节功能,例如 DS 代码点重新标记。实现更复杂分类和流量调节功能的内部节点类似于 DS 边界节点(见第 2.3.4.4 节)。


包含 DS 域的网络中的主机可以充当来自该主机上运行的应用程序的流量的 DS 边界节点;因此,我们说主机在 DS 域内。如果主机不充当边界节点,则拓扑上最接近该主机的 DS 节点充当该主机流量的 DS 边界节点。


2.1.2、 DS 入口节点和出口节点


DS 边界节点既充当 DS 入口节点又充当不同方向流量的 DS 出口节点。流量在 DS 入口节点进入 DS 域,并在 DS 出口节点离开 DS 域。DS 入口节点负责确保进入 DS 域的流量符合它与入口节点所连接的其他域之间的任何 TCA。DS 出口节点可以对转发到直接连接的对等域的流量执行流量调节功能,具体取决于两个域之间的 TCA 的详细信息。请注意,DS 边界节点可能充当某些接口集的 DS 内部节点。


2.2、 差异化服务区域


差异化服务区域(DS Region)是一组一个或多个连续的 DS 域。DS 区域能够沿着跨越区域内的域的路径支持差异化服务。


DS 域中的 DS 域内部可能支持不同的 PHB 组和不同的 codepoint->PHB 映射。然而,为了允许跨域的服务,对等 DS 域必须各自建立一个对等 SLA,该 SLA 定义(显式或隐式)TCA,该 TCA 指定从一个 DS 域到另一个域的传输流量如何在两个域之间的边界处进行调节DS 域。


一个 DS 区域内的多个 DS 域可能采用公共服务提供策略,并可能支持一组公共 PHB 组和代码点映射,从而消除这些 DS 域之间的流量调节需要。


2.3、 流量分类和调节


通过在上游网络和下游DS域之间建立SLA来跨越DS域边界扩展差异化服务。SLA 可以指定数据包分类和重新标记规则,还可以指定流量配置文件和对符合或超出配置文件的流量流的操作(参见第 2.3.2 节)。域之间的 TCA 源自(显式或隐式)此 SLA。


数据包分类策略通过被调节和/或映射到 DS 域内的一个或多个行为聚合(通过 DS 代码点重新标记)来识别可以接收差异化服务的流量子集。


流量调节执行计量、整形、管制和/或重新标记,以确保进入 DS 域的流量符合 TCA 中指定的规则,根据域的服务提供策略。所需的流量调节范围取决于服务提供的细节,范围可能从简单的代码点重新标记到复杂的监管和整形操作。网络之间协商的流量调节策略的详细信息超出了本文档的范围。


2.3.1、 分类器


数据包分类器根据数据包报头某些部分的内容选择流量流中的数据包。我们定义了两种类型的分类器。BA(行为聚合)分类器仅根据 DS 代码点对数据包进行分类。MF(Multi-Field)分类器根据一个或多个头域的组合值来选择数据包,例如源地址、目的地址、DS域、协议ID、源端口和目的端口号,以及其他信息,例如传入接口。


分类器用于将匹配某些指定规则的数据包“引导”到流量调节器的元素以进行进一步处理。分类器必须根据适当的 TCA 由某些管理程序配置。


分类器应该验证它用于对数据包进行分类的信息(参见第 6 节)。


请注意,在出现上行数据包分段的情况下,检查传输层报头字段内容的 MF 分类器可能会错误地对第一个之后的数据包分段进行分类。这个问题的一个可能解决方案是保持碎片状态;然而,由于上游片段重新排序或发散路由路径的可能性,这不是通用的解决方案。应用于数据包片段的策略超出了本文档的范围。


2.3.2、 流量概况


流量配置文件指定由分类器选择的流量流的时间属性。它提供了用于确定特定数据包是在配置文件内还是在配置文件外的规则。例如,基于令牌桶的配置文件可能如下所示:

codepoint=X, use token-bucket r, b


上述配置文件表明,所有标有 DS 代码点 X 的数据包都应根据速率为 r 和突发大小为 b 的令牌桶计量器进行测量。在这个例子中,超出规范的数据包是流量流中的那些数据包,当桶中没有足够的令牌可用时到达。配置文件内和配置文件外的概念可以扩展到两个以上的级别,例如,可以定义和强制执行与配置文件的多个级别的一致性。


可以对in-profile报文和out-of-profile报文应用不同的调节动作,也可以触发不同的计费动作。In-profile 数据包可能被允许进入 DS 域而无需进一步调节;或者,他们的 DS 代码点可能会改变。当 DS 代码点第一次设置为非默认值 [DSFIELD] 时,或者当数据包进入使用不同 PHB 组或代码点->PHB 映射策略的 DS 域时,会发生后者。超出配置文件的数据包可能会排队,直到它们符合配置文件(整形)、丢弃(监管)、用新代码点标记(重新标记)或在触发某些计数过程时原封不动地转发。不符合规范的数据包可能被映射到一个或多个行为聚合,这些行为聚合在转发性能的某个维度上“劣于”到符合规范的数据包被映射到的 BA。


请注意,流量配置文件是 TCA 的可选组件,其使用取决于服务提供的细节和域的服务供应策略。


2.3.3、 流量调节器


流量调节器可能包含以下元素:计量器、标记器、整形器和丢弃设备。流量流由分类器选择,分类器将数据包引导至流量调节器的逻辑实例。使用计量器(在适当的情况下)根据流量配置文件测量流量。计量器关于特定数据包的状态(例如,它是在配置文件内还是在配置文件外)可用于影响标记、丢弃或整形动作。


当数据包离开 DS 边界节点的流量调节器时,每个数据包的 DS 代码点必须设置为适当的值。


图 1 显示了分类器和流量调节器的框图。请注意,流量调节器不一定包含所有四个元素。例如,在没有流量模板生效的情况下,数据包可能只通过一个分类器和一个标记。


640.png

图 1:数据包分类器和流量调节器的逻辑视图


2.3.3.1、 计量器


流量计量器根据 TCA 中指定的流量配置文件测量分类器选择的数据包流的时间属性。计量器将状态信息传递给其他调节功能,以触发每个数据包的特定操作,这些数据包要么符合规范,要么不符合规范(在某种程度上)。


2.3.3.2、 标记器


数据包标记器将数据包的 DS 字段设置为特定的代码点,将标记的数据包添加到特定的 DS 行为聚合。标记器可以被配置为将被引导到它的所有数据包标记为单个代码点,或者可以被配置为将数据包标记为用于选择 PHB 组中的 PHB 的一组代码点中的一个,根据计量器。当标记更改数据包中的代码点时,它被称为“重新标记”了数据包。


2.3.3.3、 整形器


整形器延迟流量流中的部分或全部数据包,以使该流符合流量配置文件。整形器通常有一个有限大小的缓冲区,如果没有足够的缓冲区空间来容纳延迟的数据包,数据包可能会被丢弃。


2.3.3.4、 丢弃设备


Dropper 丢弃流量流中的部分或全部数据包,以使该流符合流量配置文件。这个过程被称为“监管”流。请注意,通过将整形器缓冲区大小设置为零(或几个)数据包,可以将丢弃器实现为整形器的特殊情况。


2.3.4、 流量调节器和 MF 分类器的位置


流量调节器通常位于 DS 入口和出口边界节点内,但也可能位于 DS 域内部的节点中,或位于不支持 DS 的域内。


2.3.4.1、 源域内


我们将源域定义为包含发起接收特定服务的流量的节点的域。源域内的流量源和中间节点可以执行流量分类和调节功能。来自源域的跨边界的流量在离开源域之前可以由流量源直接标记或由中间节点标记。这被称为初始标记或“预标记”。


考虑一个公司的例子,该公司的策略是其 CEO 的数据包应该具有更高的优先级。CEO 的主机可以用指示“更高优先级”的 DS 代码点标记所有传出数据包的 DS 字段。或者,直接连接到 CEO 主机的第一跳路由器可以对流量进行分类,并用正确的 DS 代码点标记 CEO 的数据包。这种高优先级流量也可以在源附近进行调节,从而限制从特定源转发的高优先级流量。


将数据包标记为靠近流量源有一些优点。首先,在决定哪些数据包应该接受更好的转发处理时,流量源可以更容易地考虑应用程序的偏好。此外,在流量与来自其他来源的数据包聚合之前,数据包的分类要简单得多,因为需要在单个节点内应用的分类规则的数量减少了。


由于数据包标记可能分布在多个节点上,源 DS 域负责确保流向其提供者 DS 域的聚合流量符合适当的 TCA。额外的分配机制,如带宽代理或 RSVP,可用于为提供者网络内的特定 DS 行为聚合动态分配资源 [2BIT, Bernet]。源域的边界节点还应监控与 TCA 的一致性,并根据需要对数据包进行监管、整形或重新标记。


2.3.4.2、 在 DS 域的边界


业务流可以在边界链路的任一端(上游域的 DS 出口节点或下游域的 DS 入口节点)进行分类、标记和以其他方式进行调节。域之间的 SLA 应指定哪个域负责将流量流映射到 DS 行为聚合并根据适当的 TCA 调节这些聚合。但是,DS 入口节点必须假定传入流量可能不符合 TCA,并且必须准备好根据本地策略执行 TCA。


当数据包在上游域中预先标记和调节时,下游 DS 域中需要支持的分类和流量调节规则可能更少。在这种情况下,下游 DS 域可能只需要重新标记或监管传入的行为聚合来强制执行 TCA。然而,更复杂的依赖于路径或源的服务可能需要在下游 DS 域的入口节点中进行 MF 分类。


如果 DS 入口节点连接到上游不支持 DS 的域,则 DS 入口节点必须能够对传入流量执行所有必要的流量调节功能。


2.3.4.3、 在不支持 DS 的域中


不具备 DS 能力的域中的流量源或中间节点可以使用流量调节器在流量到达下游 DS 域的入口之前预先标记流量。通过这种方式,可以隐藏用于分类和标记的本地策略。


2.3.4.4、 内部 DS 节点


尽管基本架构假设复杂的分类和流量调节功能仅位于网络的入口和出口边界节点,但不排除在网络内部部署这些功能。例如,可能在跨洋链路上实施更严格的访问策略,需要链路上游节点中的 MF 分类和流量调节功能。由于可能需要维护大量潜在的分类和调节规则,因此该方法可能具有扩展限制。


2.4、 每跳行为


每跳行为 (PHB) 是对应用于特定 DS 行为聚合的 DS 节点的外部可观察转发行为的描述。在这种情况下,“转发行为”是一个通用概念。例如,在只有一个行为聚合占用一条链路的情况下,可观察到的转发行为(即丢失、延迟、抖动)通常仅取决于链路的相对负载(即,如果该行为假定节约工作的调度纪律)。当多个行为聚合竞争节点上的缓冲区和带宽资源时,主要观察到有用的行为区别。PHB 是节点向行为聚合分配资源的手段,在这种基本的逐跳资源分配机制之上,可以构建有用的差异化服务。


PHB 的最简单示例是保证将 X% 的链路(在某个合理的时间间隔内)分配给行为聚合的最小带宽分配。在各种竞争性流量条件下,可以相当容易地测量此 PHB。稍微复杂的 PHB 将保证链路的 X% 的最小带宽分配,并按比例公平共享任何多余的链路容量。通常,PHB 的可观察行为可能取决于对相关行为聚合的流量特征或其他行为聚合的特征的某些约束。


PHB 可以根据它们相对于其他 PHB 的资源(例如,缓冲区、带宽)优先级,或者根据它们相对可观察的流量特性(例如,延迟、丢失)来指定。这些 PHB 可以作为构建块来分配资源,并应指定为一个组(PHB 组)以保持一致性。PHB 组通常会共享一个应用于组内每个 PHB 的公共约束,例如数据包调度或缓冲区管理策略。组中 PHB 之间的关系可以是绝对优先级或相对优先级(例如,通过确定性或随机阈值丢弃优先级),但这不是必需的(例如,N 个相等的链路份额)。单独定义的单个 PHB 是 PHB 组的特例。


PHB 是通过一些缓冲区管理和数据包调度机制在节点中实现的。PHB 是根据与服务提供策略相关的行为特征来定义的,而不是根据特定的实现机制来定义的。通常,多种实现机制可能适合于实现特定的 PHB 组。此外,一个节点上可能会实现一个以上的 PHB 组并在一个域内使用。应该定义 PHB 组,以便可以推断出组之间的适当资源分配,并且可以实施可以同时支持两个或更多组的集成机制。PHB 组定义应指出可能与先前记录的 PHB 组发生冲突,这可能会阻止同时操作。


如[DSFIELD]中所述,通过接收数据包中DS码点的映射,在节点处选择PHB。标准化的 PHB 有一个推荐的代码点。但是,代码点的总空间大于可用于标准化 PHB 的推荐代码点的空间,并且 [DSFIELD] 为本地可配置映射留下了规定。一个代码点->PHB 映射表可能包含 1->1 和 N->1 映射。所有的代码点都必须映射到某个 PHB;在缺少某些本地策略的情况下,未根据 PHB 规范映射到标准化 PHB 的代码点应映射到默认 PHB。


2.5、 网络资源分配


DS 域节点中支持的 PHB 组的实现、配置、操作和管理应根据域的服务提供策略有效地划分这些节点的资源和行为聚合之间的节点间链路。流量调节器可以通过执行 TCA 以及可能通过来自域中节点和流量调节器的操作反馈来进一步控制这些资源的使用。尽管可以在没有复杂流量调节功能的情况下部署一系列服务(例如,仅使用静态标记策略),但诸如监管、整形和动态重新标记等功能可以部署提供定量性能指标的服务。


流量调节器和内部节点之间的配置和交互应由域的管理控制进行管理,并且可能需要通过协议和控制实体进行操作控制。有多种可能的控制模型。


这些组件之间交互的确切性质和实现超出了该架构的范围。然而,可扩展性要求域的控制不需要网络资源的微观管理。最具可扩展性的控制模型将在操作时间范围内以开环方式操作节点,并且只需要管理时间尺度管理,因为 SLA 是变化的。这个简单的模型在某些情况下可能不合适,并且可能需要一些自动化但缓慢变化的操作控制(分钟而不是秒)来平衡网络的利用率与最近的负载配置文件。


3、 每跳行为规范指南


[DSFIELD] 中给出了每跳行为标准化的基本要求。本节通过描述 PHB(组)规范的附加指南来详细说明该文本。这是为了帮助促进实施的一致性。在建议 PHB 组进行标准化之前,它应该适当地满足这些准则,以保持该体系结构的完整性。


G.1:PHB 标准必须指定从为标准映射[DSFIELD] 保留的代码点空间中选择的推荐DS 代码点。推荐的代码点将由 IANA 分配。PHB 提议可能会从 EXP/LU 空间推荐一个临时代码点,以促进域间实验。确定数据包的 PHB 不得要求检查超出 DS 字段的附加数据包头字段。


G.2: 每个新提议的 PHB 组的规范应包括行为概述和提议行为的目的。概述应包括针对 PHB 组的一个或多个问题陈述。概述应包括 PHB 组背后的基本概念。这些概念应该包括但不限于排队行为、丢弃行为和输出链路选择行为。最后,概述应指定 PHB 组解决问题陈述中指定的一个或多个问题的方法。


G.3: PHB 组规范应指明指定的单个 PHB 的数量。如果指定了多个 PHB,则应明确指定这些 PHB 之间的交互以及组内所有 PHB 必须全局遵守的约束。例如,规范必须指出如果微流中的不同数据包被标记为组内不同的 PHB,则该微流中的数据包重新排序的概率是否会增加。


G.4: 当 PHB 组的正常功能依赖于诸如供应限制之类的约束时,那么 PHB 定义应描述违反这些约束时的行为。此外,如果违反这些约束时需要进行丢包或重新标记等操作,则应具体规定这些操作。


G.5: 可以指定一个 PHB 组供域内的本地使用,以提供某些特定于域的功能或特定于域的服务。在这种情况下,PHB 规范可用于为供应商提供 PHB 组的一致定义。但是,任何为本地使用而定义的 PHB 组都不应该考虑标准化,但可以作为信息 RFC 发布。相比之下,用于一般用途的 PHB 组将遵循更严格的标准化过程。因此,所有 PHB 提案都应明确说明是考虑将其用于一般用途还是本地用途。


众所周知,可以设计 PHB 组以提供主机到主机、WAN 边缘到 WAN 边缘和/或域边缘到域边缘服务。为保持一致性,在 PHB 定义中使用术语“端到端”应解释为“主机到主机”。


出于实验或操作目的,可以在域内本地定义和部署其他 PHB 组。没有要求必须公开记录这些 PHB 组,但它们应该使用来自 [DSFIELD] 中定义的 EXP/LU 池之一的 DS 代码点。


G.6: 为一个PHB组内的一个PHB标记的数据包被重新标记以选择该组内的另一个PHB是可能的或合适的;在域内或跨域边界。进行此类 PHB 修改通常有以下三个原因:


A. 与 PHB 组关联的代码点共同用于承载有关网络的状态,

B. 存在需要 PHB 提升或降级数据包的条件(假设组内的 PHB 可以按某种顺序排列),

C. SLA 不涵盖两个域之间的边界。在这种情况下,跨越边界链路时选择的代码点/PHB 将由上游域的本地策略确定。


PHB 规范应该清楚地说明为 PHB 组内的 PHB 标记的数据包可以或应该修改(例如,提升或降级)为组内的另一个 PHB 的情况。如果不希望修改数据包的 PHB,则规范应明确说明修改 PHB 时的后续风险。无论是在 PHB 组内还是在 PHB 组外,更改数据包的 PHB 的可能风险是在微流内进行数据包重新排序的可能性更高。组内的 PHB 可能携带一些主机到主机、WAN 边缘到 WAN 边缘和/或域边缘到域边缘语义,如果数据包被重新标记为从组中选择另一个 PHB,这些语义可能难以复制(或其他)。


对于某些 PHB 组,通过重新标记数据包以指定组内的另一个 PHB 来反映节点中的状态变化可能是合适的。如果 PHB 组旨在反映网络状态,则 PHB 定义必须充分描述 PHB 与其反映的状态之间的关系。此外,如果这些 PHB 限制了节点可以以某种方式执行的转发操作,则这些约束可以指定为节点应该或必须执行的操作。


G.7: PHB 组规范应包括定义隧道对 PHB 组效用的影响的部分。当内部报头的原始 DS 字段封装在隧道中时,本节应指定新创建的外部报头的 PHB 组的效用的含义。本节还应该讨论当来自内部报头和外部报头的代码点都可以访问时,应该对隧道出口处的内部报头应用哪些可能的更改(参见第 6.2 节)。


G.8: 指定 PHB 组的过程在本质上可能是渐进的。当提出新的 PHB 组时,应记录它们与先前指定的 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 规范提供一个附录,该附录推荐到链路层 QoS 机制的映射,以支持 PHB 跨共享媒体或交换链路层的预期行为。确定 PHB 和链路层 QoS 机制之间最合适的映射取决于许多因素,超出了本文档的范围;然而,规范应该尝试提供一些指导。


4、 与非差异化服务兼容节点的互操作性


我们将非差异化服务兼容节点(非 DS 兼容节点)定义为不解释 [DSFIELD] 中指定的 DS 字段和/或不实现部分或全部标准化 PHB(或那些在特定 DS 域中使用)。这可能是由于节点的功能或配置所致。我们将遗留节点定义为非 DS 兼容节点的特例,该节点实现了 [RFC791,RFC1812] 中定义的 IPv4 优先级分类和转发,但在其他方面不符合 DS。IPv4 TOS 八位字节中的优先级值有意与 [DSFIELD] 中定义的类选择器代码点兼容,并且 [RFC791,RFC1812] 中定义的优先转发行为符合也在 [DSFIELD] 中定义的类选择器 PHB 要求。传统节点和符合 DS 的节点之间的一个关键区别在于,传统节点可能会也可能不会解释 [RFC1349] 中定义的 TOS 八位字节的第 3-6 位(“DTRC”位);实际上,它不会按照 [DSFIELD] 中的规定解释这些位。我们假设不推荐使用 [RFC1349] 中定义的 TOS 标记。对于非零 DS 代码点的数据包,不符合 DS 标准且不是传统节点的节点可能会表现出不可预测的转发行为。


差异化服务依赖于节点中每跳行为实现提供的资源分配机制。如果流量通过不兼容 DS 的节点或不支持 DS 的域,服务的质量或统计保证级别可能会崩溃。


我们将研究两个不同的案例。


第一种情况涉及在 DS 域内使用不符合 DS 的节点。请注意,PHB 转发主要用于以受控方式分配稀缺节点和链路资源。在高速、轻负载链路上,最坏情况的数据包延迟、抖动和丢失可以忽略不计,并且在此类链路的上游端使用不符合 DS 标准的节点可能不会导致服务降级。在更现实的情况下,节点中缺少 PHB 转发可能会导致无法跨节点的路径提供低延迟、低损耗或预配置的带宽服务。然而,使用遗留节点可能是一个可接受的替代方案,假设 DS 域将自身限制为仅使用 [DSFIELD] 中定义的类选择器代码点,并假设遗留节点中的特定优先级实现提供兼容的转发行为沿着穿过该节点的路径提供服务。请注意,将使用的代码点限制为类选择器代码点很重要,因为遗留节点可能会或可能不会根据 [RFC1349] 解释第 3-5 位,从而导致不可预测的转发结果。


第二种情况涉及遍历不支持 DS 的域的服务的行为。为了论证起见,我们假设不具备 DS 能力的域不会在域边界节点上部署流量调节功能;因此,即使域由传统的或符合 DS 的内部节点组成,边界上缺乏流量执行也会限制跨域一致地提供某些类型服务的能力。DS 域和不支持 DS 的域可以协商一个协议,该协议管理在进入不支持 DS 的域之前应如何标记来自 DS 域的出口流量。可以通过流量采样而不是严格的流量调节来监控该协议的合规性。或者,如果知道不具备 DS 能力的域由传统节点组成,上游 DS 域可以机会性地将差异化服务流量重新标记为一个或多个类选择器代码点。如果不知道下游域的流量管理能力,并且没有适当的协议,DS 域出口节点可以选择将 DS 代码点重新标记为零,假设不具备 DS 能力的域将处理流量统一,尽力服务。


如果不支持 DS 的域与 DS 域对等,则应根据适当的 SLA 或策略在 DS 域的 DS 入口节点处调节来自不支持 DS 的域的流量。


5、 组播注意事项


通过组播流量使用差异化服务引入了许多服务供应问题。


首先,由于组播数据包复制,在入口节点进入DS域的组播数据包可能同时采取多条路径通过域的某些段。通过这种方式,它们比单播数据包消耗更多的网络资源。在组播组成员资格是动态的情况下,很难预先预测源自特定组的上游网络的组播流量可能消耗的网络资源量。这种不确定性的结果是可能难以向组播发送方提供定量服务保证。此外,可能需要为单播流量保留代码点和 PHB,以提供与组播流量的资源隔离。


第二个问题是为到达 DS 入口节点的组播数据包选择 DS 代码点。因为该数据包可能在与多个下游域对等的多个 DS 出口节点处退出 DS 域,所以使用的 DS 代码点不应导致来自下游 DS 域的违反对等 SLA 的服务请求。当在 DS 入口节点为接收跨越域出口边界的差异化服务的流量集合建立分类器和流量调节器状态时,可以考虑相邻下游中转域的身份和相应对等 SLA 的细节进入配置决策(取决于路由策略和路由基础设施的稳定性)。通过这种方式,可以在上游域的入口部分实施与下游 DS 域的对等 SLA,从而减少上游域出口节点的分类和流量调节负担。由于动态组成员身份的可能性,这在组播流量的情况下不太容易执行。结果是单播流量的服务保证可能会受到影响。解决这个问题的一种方法是为组播流量建立一个单独的对等 SLA,或者为组播数据包使用一组特定的代码点,或者在 DS 出口节点中实施必要的分类和流量调节机制,以提供优先隔离与下游域的对等 SLA 一致的单播流量。


6、 安全和隧道注意事项


本节解决因引入差异化服务而引起的安全问题,主要是拒绝服务攻击的可能性,以及未经授权的流量窃取服务的相关可能性(第 6.1 节)。此外,还讨论了存在 IPsec 时差异化服务的运行及其与 IPsec 的交互(第 6.2 节),以及审计要求(第 6.3 节)。本节考虑使用 IPsec 和非 IPsec 隧道引入的问题。


6.1、 盗窃和拒绝服务


差异化服务的主要目标是允许为公共网络基础设施上的流量流提供不同级别的服务。可以使用多种资源管理技术来实现这一点,但最终结果将是某些数据包接收到与其他数据包不同(例如,更好)的服务。网络流量到导致不同(例如,更好或更差)服务的特定行为的映射主要由 DS 字段指示,因此攻击者可能能够通过将 DS 字段修改为指示所使用行为的代码点来获得更好的服务用于增强服务或通过将 DS 字段设置为此类代码点的数据包注入。考虑到其极限,当修改或注入的流量耗尽可用于转发它和其他流量流的资源时,这种服务盗窃就变成了拒绝服务攻击。防御此类盗窃和拒绝服务攻击包括将 DS 边界节点的流量调节与 DS 域内网络基础设施的安全性和完整性相结合。


如第 2 节所述。2、DS入口节点必须调节进入DS域的所有流量,以确保它具有可接受的DS代码点。这意味着代码点必须符合适用的 TCA 和域的服务供应策略。因此,入口节点是防御基于修改后的 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 代码点执行一些流量调节检查(例如,检查从未用于特定链路上的流量的 DS 代码点)以提高安全性和鲁棒性(例如,对基于 DS 代码点修改的服务盗窃攻击的抵抗力)。任何检测到的此类检查失败都是可审核事件,生成的审核日志条目应包括接收数据包的日期/时间、源和目标 IP 地址以及导致失败的 DS 代码点。在实践中,在确定要在内部节点执行哪些检查(如果有)时,需要权衡此类检查的有限收益与其潜在的性能影响。


任何不能充分保护 DS 代码点修改或攻击者注入流量的链路都应被视为边界链路(因此,该链路上的任何到达流量都被视为在入口节点进入域)。本地安全策略提供了“充分安全”的定义,并且这样的定义可能包括确定 DS 代码点修改和/或流量注入的风险和后果不能证明任何额外的链路安全措施是合理的。可以通过物理访问控制和/或软件手段(例如确保数据包完整性的隧道)来增强链路安全性。


6.2、 IPsec 和隧道交互


[ESP, AH] 中定义的 IPsec 协议在其任何加密计算中都不包括 IP 标头的 DS 字段(在隧道模式的情况下,不包括外部 IP 标头的 DS 字段)。因此,网络节点修改 DS 字段对 IPsec 的端到端安全没有影响,因为它不会导致任何 IPsec 完整性检查失败。因此,IPsec 不会针对攻击者修改 DS 字段(即中间人攻击)提供任何防御,因为攻击者的修改也不会对 IPsec 的端到端安全产生影响。在某些环境中,在不影响 IPsec 完整性检查的情况下修改 DS 字段的能力可能构成隐蔽通道;如果需要消除这样的通道或减少其带宽,则应配置 DS 域,以便可以在流量退出的 DS 出口节点执行所需的处理(例如,将敏感流量上的所有 DS 字段设置为单个值)更高的安全域。


IPsec 的隧道模式为封装的 IP 报头的 DS 字段提供安全性。隧道模式 IPsec 数据包包含两个 IP 标头:由隧道入口节点提供的外部标头和由数据包的原始源提供的封装内部标头。当 IPsec 隧道(全部或部分)托管在差异化服务网络上时,中间网络节点对外部报头中的 DS 字段进行操作。在隧道出口节点,IPsec 处理包括剥离外部报头并使用内部报头转发数据包(如果需要)。如果隧道出口节点的DS域的DS入口节点没有处理内部IP头,则隧道出口节点是隧道出口流量的DS入口节点,因此必须执行相应的流量调节职责(参见Sec . 6.1)。如果 IPsec 处理包括对封装数据包的足够强的加密完整性检查(其中充分性由本地安全策略确定),则隧道出口节点可以安全地假设内部报头中的 DS 字段与它在隧道入口节点。这允许与隧道入口节点在同一 DS 域中的隧道出口节点安全地处理通过这种完整性检查的数据包,就好像它是从同一 DS 域内的另一个节点到达一样,省略了 DS 入口节点流量调节否则需要。一个重要的结果是,DS 域内部的不安全链路可以通过足够强大的 IPsec 隧道来保护。


这种分析及其含义适用于任何执行完整性检查的隧道协议,但内部报头的 DS 字段的保证级别取决于隧道协议执行的完整性检查的强度。如果隧道可以通过当前 DS 域外的节点(或易受攻击),如果没有足够的保证,则必须将封装的数据包视为从域外到达 DS 入口节点。


IPsec协议目前要求隧道出口节点的IPsec解封装处理不能改变内部报头的DS字段。这确保了对手对 DS 字段的修改不能用于跨 IPsec 隧道端点发起盗窃或拒绝服务攻击,因为任何此类修改都将在隧道端点被丢弃。本文档不更改该 IPsec 要求。


如果将来修改IPsec规范,允许隧道出口节点根据外层头中的DS字段值修改内层IP头中的DS字段(例如,将部分或全部外层DS字段复制到内层DS 字段),则需要额外考虑。对于完全包含在单个 DS 域内且链路已充分保护以防止外部 DS 字段修改的隧道,对内部 DS 字段修改的唯一限制将是域的服务供应策略所施加的限制。否则,执行此类修改的隧道出口节点将充当离开隧道的流量的 DS 入口节点,并且必须执行入口节点的流量调节职责,包括防御盗窃和拒绝服务攻击(参见 Sec . 6.1)。如果隧道在不同于隧道出口节点的节点进入DS域,则隧道出口节点可以依赖于上游DS入口节点已经确保外部DS字段值是可接受的。即使在这种情况下,也有一些检查只能由隧道出口节点执行(例如,加密隧道的内部和外部 DS 代码点之间的一致性检查)。任何检测到的此类检查失败都是可审计事件,生成的审计日志条目应包括接收数据包的日期/时间、源和目标 IP 地址以及不可接受的 DS 代码点。


从架构的角度来看,至少可以通过两种不同的方式来看待 IPsec 隧道。如果将隧道视为逻辑单跳“虚拟线路”,则转发隧道流量的中间节点的操作不应在隧道末端之外可见,因此不应在解封装过程中修改 DS 字段。相反,如果隧道被视为转发流量的多跳参与者,则可能需要修改 DS 字段作为隧道解封装处理的一部分。当隧道终止于域管理员不希望部署流量调节逻辑(例如,为了简化流量管理)的 DS 域的内部节点时,后一种情况的特定示例发生。这可以通过使用外部 IP 报头中的 DS 代码点(受 DS 入口节点的流量调节)来重置内部 IP 报头中的 DS 代码点来支持,有效地将 DS 入口流量调节责任从 IPsec 隧道出口转移节点到适当的上游 DS 入口节点(必须已经为未封装的流量执行该功能)。


6.3、 审计


并非所有支持差异化服务的系统都会实施审计。但是,如果将差异化服务支持合并到支持审计的系统中,那么差异化服务实现也应该支持审计。如果存在此类支持,则实施必须允许系统管理员从整体上启用或禁用对差异化服务的审计,并且可以允许部分启用或禁用此类审计。


在大多数情况下,审计的粒度是局部问题。但是,本文档中确定了几个可审计的事件,并且为这些事件中的每一个定义了应包含在审计日志中的最小信息集。附加信息(例如,与触发可审计事件的信息包相关的数据包)也可以包含在这些事件中的每一个的审计日志中,并且本规范中没有明确指出的附加事件也可能导致审计日志条目。接收方不需要向声称的发送方传输任何消息以响应检测到可审计事件,因为此类行为可能导致拒绝服务。


7、 致谢


本文档得益于 Steven Blake、David Clark、Ed Ellesson、Paul Ferguson、Juha Heinanen、Van Jacobson、Kalevi Kilkki、Kathleen Nichols、Walter Weiss、John Wroclawski 和 Lixia Zhang 的早期草稿。


作者感谢以下人士的有益评论和建议:Kathleen Nichols、Brian Carpenter、Konstantinos Dovrolis、Shivkumar Kalyana、Wu-chang Feng、Marty Borden、Yoram Bernet、Ronald Bonica、James Binder、Borje Ohlman、Alessio Casati、Scott Brim、Curtis Villamizar、Hamid Ould-Brahi、Andrew Smith、John Renwick、Werner Almesberger、Alan O'Neill、James Fu 和 Bob Braden。


8、 参考文献


[802.1p] ISO/IEC Final CD 15802-3 Information technology - Telecommunications and information exchange between systems -Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) bridges, (current draft available as IEEE P802.1D/D15).
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[ATM] ATM Traffic Management Specification Version 4.0 <af-tm-0056.000>, ATM Forum, April 1996.
[Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. Nichols, and M. Speer, "A Framework for Use of RSVP with Diff-serv Networks", Work in Progress.
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[EXPLICIT] D. Clark and W. Fang, "Explicit Allocation of Best Effort Packet Delivery Service", IEEE/ACM Trans. on Networking, vol. 6, no. 4, August 1998, pp. 362-373.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990.
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, July 1994.
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997.
[TR] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token Ring Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.5-1995), 1995.


完整的版权声明


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


本文件及其译文可能会被复制和提供给他人,并且可以全部或部分地准备、复制、出版和分发对其进行评论或以其他方式解释或协助其实施的衍生作品,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文档本身,例如通过删除版权声明或对 Internet 协会或其他 Internet 组织的引用,除非出于制定 Internet 标准的需要,在这种情况下,版权程序定义在必须遵循 Internet 标准流程,或按照要求将其翻译成英语以外的语言。


上述授予的有限权限是永久性的,不会被互联网协会或其继任者或受让人撤销。


本文档和其中包含的信息按“原样”提供,互联网协会和互联网工程工作队不提供所有明示或暗示的保证,包括但不限于任何保证,即使用此处的信息不会侵犯任何有关适销性或特定用途适用性的权利或任何默示保证。

相关文章
|
25天前
|
安全 Android开发 iOS开发
深入探索Android与iOS的差异:从系统架构到用户体验
在当今的智能手机市场中,Android和iOS无疑是最受欢迎的两大操作系统。本文旨在探讨这两个平台之间的主要差异,包括它们的系统架构、开发环境、安全性、以及用户体验等方面。通过对比分析,我们可以更好地理解为何不同的用户群体可能会偏好其中一个平台,以及这些偏好背后的技术原因。
|
1月前
|
Android开发 Swift iOS开发
深入探索iOS与Android操作系统的架构差异及其对应用开发的影响
在当今数字化时代,移动设备已经成为我们日常生活和工作不可或缺的一部分。其中,iOS和Android作为全球最流行的两大移动操作系统,各自拥有独特的系统架构和设计理念。本文将深入探讨iOS与Android的系统架构差异,并分析这些差异如何影响应用开发者的开发策略和用户体验设计。通过对两者的比较,我们可以更好地理解它们各自的优势和局限性,从而为开发者提供有价值的见解,帮助他们在这两个平台上开发出更高效、更符合用户需求的应用。
|
2月前
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
3月前
|
存储 Linux KVM
Proxmox VE (PVE) 主要架构和重要服务介绍
Proxmox VE (PVE) 是一款开源的虚拟化平台,它基于 KVM (Kernel-based Virtual Machine) 和 LXC (Linux Containers) 技术,支持虚拟机和容器的运行。PVE 还提供高可用集群管理、软件定义存储、备份和恢复以及网络管理等企业级功能。
1335 7
|
3月前
|
IDE Android开发 iOS开发
深入解析Android与iOS的系统架构及开发环境差异
本文旨在探讨Android和iOS两大主流移动操作系统在系统架构、开发环境和用户体验方面的显著差异。通过对比分析,我们将揭示这两种系统在设计理念、技术实现以及市场策略上的不同路径,帮助开发者更好地理解其特点,从而做出更合适的开发决策。
192 2
|
2天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
27 11
|
19天前
|
安全 Android开发 iOS开发
深入探索iOS与Android系统架构差异及其对开发者的影响
本文旨在通过对比分析iOS和Android两大移动操作系统的系统架构,探讨它们在设计理念、技术实现及开发者生态方面的差异。不同于常规摘要仅概述内容要点,本摘要将简要触及核心议题,为读者提供对两大平台架构特点的宏观理解,铺垫
|
26天前
|
Kubernetes Cloud Native Docker
云原生之旅:从传统架构到容器化服务的演变
随着技术的快速发展,云计算已经从简单的虚拟化服务演进到了更加灵活和高效的云原生时代。本文将带你了解云原生的概念、优势以及如何通过容器化技术实现应用的快速部署和扩展。我们将以一个简单的Python Web应用为例,展示如何利用Docker容器进行打包和部署,进而探索Kubernetes如何管理这些容器,确保服务的高可用性和弹性伸缩。
|
22天前
|
IDE 安全 Android开发
深入探索Android与iOS操作系统的架构差异
本文旨在对比分析Android和iOS两大主流移动操作系统在架构设计上的根本差异。通过详细解读两者的系统架构、开发环境、以及安全性等方面,揭示它们各自的特点及优势,为开发者选择合适的平台提供参考。
|
1月前
|
安全 Android开发 iOS开发
深入探讨Android与iOS的系统架构差异
本文旨在通过对比分析Android和iOS两大移动操作系统的系统架构,揭示它们在设计理念、安全性、应用生态及开发环境等方面的显著差异。我们将从底层架构出发,逐步剖析至用户界面层面,为开发者和科技爱好者提供一份详尽的技术参考。
33 1