IP协议的服务类型（翻译RFC 1349）

目录
1.简介
2.目标和理念
3.服务八位字节类型规范
4.TOS字段的规范
5. Internet协议中TOS字段的使用
5.1 Internet控制消息协议（ICMP）
5.2传输协议
5.3应用协议
6. ICMP和TOS字段
6.1无法到达目的地
6.2重定向
7.在路由中使用TOS字段
7.1主机路由
7.2转发
8.TOS的其他重要性
附录A.其他规格的更新
A.1 RFC-792（ICMP）
A.2 RFC-1060（分配的号码）
A.3 RFC-1122和RFC-1123（主机要求）
A.4 RFC-1195（集成IS-IS）
A.5 RFC-1247（OSPF）和RFC-1248（OSPF MIB）
附录B.基本原理
B.1最小化货币成本TOS值
B.2 TOS字段的规范
B.3弱TOS路由的选择
B.4最长匹配路由的保留
B.5使用目的地不可达
附录C. TOS机制的局限性
C.1固有局限性
C.2本规范的局限性

1.简介
互联网的路径在其提供的服务质量方面差异很大。有些路径比其他路径更可靠。有些收取高额的通话费用或按分组收费，而有些则不收取基于使用量的费用。吞吐量和延迟也相差很大。通常需要权衡：提供最高吞吐量的路径可能不会是提供最低延迟或最低开销的服务。因此，数据包通过Internet 遵循的“最佳”路径可能取决于应用程序及其用户的需求。

由于因特网本身不直接知道如何为特定的应用程序或用户优化路径，IP协议为上层协议提供了（相当有限的）字段，以便向因特网层传达关于如何对特定分组进行权衡的提示。本字段为“服务类型”字段，在本规范中简称为“TOS字段”。

尽管TOS字段从一开始就已经是IP规范的一部分，但在过去很少使用。然而，Internet主机规范现在要求主机使用TOS字段。此外，还开发了路由协议（包括OSPF和集成的IS-IS），可以分别计算每种服务的路由。这些新的路由协议使得路由器在进行路由决策时能够考虑所请求的服务类型。

本规范详细定义了主机和路由器如何使用TOS字段。第2节介绍了促使本规范中的设计选择的主要考虑因素。第3节和第4节描述了IP报头中服务八位字节的类型以及该八位字节的TOS字段可能包含的值。第5节描述了主机（或路由器）如何选择适当的值以插入其发起的IP数据报的TOS字段。第6节和第7节描述了ICMP目的地不可到达和重定向消息，以及TOS如何影响主机和路由器的路径选择。第8节描述了TOS可选地影响分组处理的一些附加方式。附录A描述了本规范如何更新一些现有规范。附录B和C扩展了第2节中的讨论。

2.目标和理念
指导本规范的基本规则是，主机不应因使用TOS字段而受到惩罚。如果主机适当地使用了TOS字段，那么它的网络服务应该至少和主机没有使用该字段时的服务一样好（并且希望更好）。这个目标被认为是特别重要的，因为任何不符合这个目标的规范，无论它在其他方面有多好，都不可能被广泛地部署和使用。这一目标的一个特殊结果是，如果网络不能提供包中请求的TOS，则网络不会丢弃包，而是以与未设置TOS位时相同的方式传递包。

尽管TOS字段在过去没有被广泛使用，但本规范的目标是尽可能与现有实践兼容。这主要意味着现有的主机实现不应该与实现本规范的主机和路由器进行不良交互，因为在本规范之前的路由器中几乎不存在TOS支持。然而，该规范试图与OSPF和集成IS-IS中的IP-TOS处理兼容。

由于Internet社区对TOS没有太多经验，因此该规范允许轻松定义和部署新的和实验性的服务类型是很重要的。这一目标对本规范产生了重大影响。特别是，它导致了永久地确定TOS字段大小的决定，以及主机和路由器应该能够正确地处理一种新类型的服务而不必理解其语义的决定。

本规范的附录B对本规范特定方面背后的原理进行了更详细的解释。

3.服务八位字节类型规范
TOS字段是IP数据报报头中服务八位字节类型的特性之一。服务八位字节的类型由三个字段组成：
0 1 2 3 4 5 6 7
±----±----±----±----±----±----±----±----+
| | | |
|PRECEDENCE| TOS |MBZ|
| | | |
±----±----±----±----±----±----±----±----+
上面标记为“PRECEDENCE”的第一个字段用于表示数据报的重要性或优先级。本备忘录未详细讨论此字段。

第二个字段在上面标记为“ TOS”，表示网络应该如何使用在吞吐量，延迟，可靠性和成本之间进行权衡。该TOS字段是此规范的主要话题。上面标有“ MBZ”（表示“必须为零”）的最后一个字段。当前未使用。数据报的创建者将此字段设置为零（除非参加使用该位的Internet协议实验）。路由器和数据报的接收者将忽略此字段的值。该字段在碎片时被复制。
过去，TOS 字段的大小有些混乱。RFC-791将其定义为一个三位字段，包括上图中的3-5位。它在MBZ字段中包含第6位。RFC-1122 在TOS字段中添加了第6位和第7位，从而消除了MBZ字段。该备忘录将TOS字段重新定义为上图所示的四位。选择使TOS字段为4位宽的原因可以在附录B.2中找到。

4.TOS字段的规范
如前所述，该规范将TOS字段重新定义为4 位字段。同样与RFC-791相反，此规范将TOS字段定义为单个枚举值，而不是一组位（其中每个位都有其自身的含义）。本规范定义了以下TOS字段值的语义（以二进制数表示）：
1000-最小延迟
0100-最大吞吐量
0010-最大可靠性
0001-最小货币成本
0000-正常服务

TOS字段中使用的值在本规范中称为“TOS值”，而IP数据包的TOS字段的值在本备忘录中称为“请求的TOS”。TOS字段值0000在本备忘录中称为“默认TOS”

由于此规范将TOS值重新定义为整数而不是位集，因此计算两个TOS值的逻辑或不再有意义。例如，路由器为其请求的TOS为1110的数据包选择低延迟路径将是一个严重的错误，因为路由器注意到前一个“延迟位”被设置。

尽管上述五个值以外的其他值的语义未由本备忘录定义，但它们是完全合法的TOS值，主机和路由器不得以任何方式排除它们的使用。在阅读完本规范的其余部分后，我们将清楚地看到，只有默认的TOS在任何方面都是特殊的。主机或路由器不需要（除第8节中所述的情况外）对其语义由本规范定义的TOS值和不由本规范定义的TOS值进行任何区分。

在TOS字段的值定义中注意“最小化”和“最大化”这两个词的使用是很重要的。例如，将TOS字段设置为1000（最小化延迟）不能保证数据报所采用的路径具有用户认为“低”的延迟。网络将尝试根据其（通常是不完全的）路径延迟信息来选择可用的最低延迟路径。网络不会仅仅因为认为可用路径的延迟“太高”而丢弃数据报（实际上，网络管理器可以通过创造性地使用路由度量来覆盖此行为，但强烈建议不要这样做：设置TOS字段是为了在可用时提供更好的服务，而不是拒绝服务。）

5、Internet协议中TOS字段的使用
为了使TOS字段有用，IP包中的TOS字段必须用合理的值填充。本节讨论IP以上的协议如何选择适当的值。

5.1互联网控制消息协议（ICMP）
ICMP定义了许多用于执行Internet层的错误报告和诊断功能的消息。本节描述主机或路由器如何为其发起的ICMP消息选择适当的TOS值。TOS字段也会影响ICMP重定向和ICMP目的地不可访问的发起和处理，但这是第6节的主题。

在本讨论中，将ICMP消息分为三类是很有用的：
· ICMP错误消息包括ICMP消息类型3（目标不可达）、4（源抑制）、5（重定向）、11（时间超时）和12（参数问题）。
· ICMP请求消息包括ICMP消息类型8（Echo）、10（路由器请求）、13（时间戳）、15（信息请求——现已过时）和17（地址掩码请 求）。
· ICMP回复消息包括ICMP消息类型0（回送回复）、9（路由器播发）、14（时间戳回复）、16（信息回复——也已过时）和18（地址掩码回复）。

ICMP错误消息总是以默认的TOS（0000）发送。

ICMP请求消息可以用TOS字段中的任何值发送。在许多生成ICMP请求消息的应用程序中，允许用户指定要使用的TOS值的机制将是一个有用的功能。

发送的ICMP回复消息的TOS字段值与相应ICMP请求消息中使用的值相同。

5.2传输协议
发送数据报时，传输协议使用应用程序请求的TOS。不要求传输连接的两端使用相同的TOS。例如，大容量数据传输应用程序的发送端应该请求最大吞吐量，而接收端可能请求最小延迟（假设它主要发送小的确认数据包）。对于传输协议来说，为应用程序提供一种机制来学习最近接收的数据的TOS值可能是有用的。

如果正在生成的通信量的性质发生变化，则可以在连接中切换到不同的TOS。其中一个例子就是SMTP，它的一部分时间用于批量数据传输，另一部分时间用于交换短命令消息和响应。

对于只包含TCP控制信息的数据报，TCP应该使用与包含用户数据的数据报相同的TOS。尽管总是为不含数据的确认数据段请求网络最小延迟似乎直观上是正确的，但这样做可能会破坏TCP的往返时间估计。

5.3应用协议
应用程序负责为它们产生的任何通信量选择适当的TOS值。附录列出了许多常见网络应用程序要使用的TOS值。对于其他应用程序，应用程序的设计者或程序员有责任根据应用程序发起的流量的性质做出适当的选择。

对于许多类型的网络诊断应用程序和其他应用程序来说，应用程序的用户能够覆盖应用程序将要选择的TOS值是非常必要的。

附录文件定期修订和重发。在RFC-1060（目前正在编写的版本）被取代之前，读者应查阅本规范的附录A.2。

6、ICMP和TOS设施
路由器使用ICMP协议向主机传送路由信息。本节描述对TOS功能的支持如何影响ICMP重定向消息和某些类型的ICMP目标不可到达消息的发起和解释。此规范未定义ICMP协议的任何新扩展。

6.1目标不可达
ICMP目标不可到达消息包含描述目标不可到达原因的代码。有四种代码与本规范主题特别相关：
0—网络不可达
1—主机不可达
11—网络对服务类型不可达
12—主机对服务类型不可达

如果因为指定了不同的TOS值，当无法到达的目的地（网络或主机）变得可达时，路由器会生成代码11或12目标不可达。路由器在其他情况下生成代码0或1目标不可达。

接收到包含这些代码中任何一个的目的地不可到达消息的主机应认识到，这可能是路由瞬态造成的。因此，主机应将消息解释为只提示而不是证明指定目标无法到达的证据。

使用代码11和12似乎与第2节中的陈述相反，即不能仅仅因为不能提供请求的TOS而丢弃分组。附录B.5中描述了使用这些代码的基本原理和预期使用这些代码的有限情况。

6.2重定向
ICMP重定向消息还包括一个代码，该代码指定了应用重定向的数据报的类别。目前定义了四种代码：
0—重定向网络的数据报
1—重定向主机的数据报
2——重定向服务和网络类型的数据报
3——重定向服务和主机类型的数据报

当重定向仅应用于请求特定TOS值的IP包时，路由器生成代码3重定向。当到达目的地的路径上的最佳下一跳对于任何TOS值都相同时，路由器生成一个code 1重定向。为了尽量减少主机混淆的可能性，路由器应该避免在重定向中使用代码0和2。

尽管当前的Internet主机规范仅要求主机正确处理代码0和代码1重定向，但主机也应正确处理代码2和代码3重定向，如本规范第7.1节所述。如果主机不这样做，则主机最好将代码2视为等同于代码0，将代码3视为等同于代码1，而不是简单地忽略代码2和代码3重定向。

7、TOS字段在路由中的使用

主机和路由器在选择适当的路径将数据报发送到目的地时，都应该考虑数据报的TOS字段的值。本节将讨论执行此操作的机制。

数据包的TOS值是否真的影响到它在特定路由域中的路径是路由域的网络管理器做出的选择。在许多路由域中，路径具有足够的同质性，因此路由器没有理由基于数据报中的TOS字段选择不同的路径。在这样的路由域中，网络管理器可以选择通过仅为默认（0000）TOS定义路由来限制路由数据库和路由协议更新的大小。主机和路由器都不需要知道TOS是否影响本地路由域中的路由。

7.1主机路由
当主机（不是路由器）希望将IP数据包发送到另一个网络或子网上的目的地时，它需要选择合适的路由器将数据包发送。根据IP架构，它通过维护路由缓存和默认路由器列表来实现。路由缓存中的每个条目都列出一个目的地（IP地址）和用于到达该目的地的适当路由器。主机通过ICMP重定向机制学习存储在其路由缓存中的信息。主机从静态配置信息或使用ICMP路由器发现机制来学习默认路由器列表。当主机希望发送IP包时，它会在其路由缓存中搜索与包中的目标地址匹配的路由。如果找到一个，则使用它；如果没有，则将数据包发送到默认路由器之一。所有这些在RFC-1122的第3.3.1节中有更详细的描述。

添加对TOS字段的支持只会稍微改变主机路由过程。在下面，假设（根据当前因特网主机规范）主机将代码0（网络重定向数据报）重定向视为代码1（主机重定向数据报）重定向。类似地，假设主机将代码2（重定向网络和服务类型的数据报）重定向视为代码3（重定向主机和服务类型的数据报）重定向。考虑违反这些假设的读者应该意识到，为了避免发送到某个目的地的每个数据包都会引起重定向，有必要对重定向的处理方式进行长时间的仔细考虑。由于这些假设与Internet主机规范的建议相匹配，因此仔细考虑超出了本规范的范围。

如第6.2节所述，某些ICMP重定向仅适用于请求特定TOS的IP数据包。因此，主机（至少在概念上）需要在其路由缓存中存储两种类型的条目：
type 1: { destination, TOS, router }
type 2: { destination, *, router }

其中，类型1条目是由于收到代码3（或代码1）重定向和输入代码2（或代码0）重定向后将产生类型2条目。

当主机要发送数据包时，它首先搜索路由缓存类型1条目，其目的地址与数据包的目标地址匹配，并且TOS与数据包中的请求的TOS匹配。如果找不到，主机将再次搜索其路由缓存，这一次将查找其目的地与数据包的目的地地址匹配的类型2条目。如果这些搜索中的任何一个找到匹配的条目，则将数据包发送到匹配条目中列出的路由器。否则，数据包将发送到默认路由器列表中的其中一个路由器。

主机创建（或更新）类型2条目时，必须从其路由缓存中清除所有具有相同类型的类型1条目目的地。这对于正确性是必要的，因为类型1 条目可能已过时，但如果不刷新，则将继续使用，因为类型1条目始终比类型2 条目更受青睐。

但是，反之则不成立：当主机创建类型1 条目时，它不应刷新具有相同目的地的类型2条目。在这种情况下，对于目标地址和请求的TOS与类型1条目匹配的数据包，类型1条目将正确覆盖类型2 条目。因为类型2 条目可以很好地为某些类型的TOS值指定正确的路由器，而不是类型1条目中指定的路由器，所以保存类型2项可能会减少主机原本会收到的重定向的数量。如果避免的重定向之一将创建新的2类条目（从而导致刷新了新的1类条目），则可能会节省大量资金。例如，如果仅本地网络上的某些路由器属于为每个TOS计算单独路由的路由域的一部分，则可能发生这种情况。

作为替代方案，主机可以将所有重定向视为代码3（主机和服务类型的重定向数据报）重定向。此替代方法允许主机仅具有类型1路由缓存条目，从而简化了路由查找并消除了前两段中对规则的需要。这种方法的缺点是，如果主机将带有各种请求的TOS的数据包发送到目的地，而主机应使用同一路由器而不考虑请求的TOS ，则会增加路由缓存的大小和重定向流量。TOS设施还没有足够的经验来知道这种缺点在实践中是否会严重到足以胜过这种方法的简单性。

尽管有RFC-1122，一些主机通过“窃听”路由协议而不是使用上述机制来获取其路由信息。此类主机将需要遵循第7.2节中描述的过程（当然，主机不会发送无法到达的ICMP目标或ICMP重定向）。

7.2转发

在选择转发IP数据包的适当路径时，Internet上的路由器应该能够考虑TOS字段的值。路由器如何做到这一点是路由器如何选择适当路径的更普遍的问题。这个更大的问题可能非常复杂[4]，并且不在本备忘录的讨论范围之内。因此，该讨论仅应视为概述。实现者应参考路由器要求规范[3]和他们实现的路由协议的规范以获取详细信息。

路由器将TOS值与其转发表中的每个路由相关联。该值可以是IP数据报中TOS 字段的任何可能值（包括其语义尚待定义的那些值）。使用路由学到的任何路由支持TOS的协议由那些协议分配了适当的TOS值。使用其他路由协议获知的路由始终被分配默认的TOS值（0000）。静态路由的TOS值由网络管理员分配。

当路由器要转发数据包时，它首先在其转发表中查找目标地址。这产生了一组候选路线。该集合可能为空（如果目的地不可达），或者可能包含一条或多条通往目的地的路线。如果集合不为空，则检查集合中路由的TOS值。如果集合中包含一条路线，TOS与要转发的数据包的TOS字段完全匹配，然后选择该路由。如果不是，但集合包含具有默认TOS的路由，则选择该路由。

如果找不到路由，或者所选路由具有无限度量，则认为无法到达目标。数据包将被丢弃，无法到达的ICMP目标将返回到源。通常，无法访问使用代码0（网络无法访问）或1（主机无法访问）。但是，如果存在到目的地的路由，该路由具有不同的TOS值和非无限度量，则必须改用代码11（服务类型无法访问网络）或代码12（服务类型无法访问主机）。

8.TOS的其他重要性

数据报中的TOS字段主要影响通过网络选择的路径，但是实现者可以选择使TOS也影响数据报的其他方面。处理。例如，主机或路由器可能会选择在网络输出队列上优先处理已请求将延迟最小化的数据报。同样，由于过载而被迫丢弃数据包的路由器可能尝试避免丢弃要求可靠性最大化的数据包。至少有一篇论文[14]对这些想法进行了详细的探讨，但对于这种特殊处理在实践中的效果知之甚少。

此外，某些链路层协议具有自己的服务质量机制。当路由器或主机传输IP数据包时，它可能会从链路层请求服务质量，该服务质量应尽可能接近IP头中TOS字段中请求的质量。很久以前，曾尝试（RFC-795）来编码该怎么做，但是该文档描述了具有以下特征的链路层协议：
自从过时以来，就没有关于该主题的最新文档被写入。

附录A.其他规格的更新

虽然此备忘录主要是对IP协议的更新规范[11]，它还会在外围影响许多其他规格。本附录描述了这些外围效应。此信息包含在附录中，而不是主要内容中。该文档的正文，因为大多数其他（如果不是全部）规格将在将来更新。碰巧的是，本附录中包含的信息将过时。

A.1 RFC-792（ICMP）
RFC-792 [12]定义了一组代码，指示为什么目的地无法到达。本备忘录描述了两种用法
附加代码：
11-服务类型无法访问网络
12-服务类型无法访问主机
这些代码在RFC-1122 中定义，但未包含在RFC-792。

A.2 RFC-1060（分配编号）
RFC-1060[15]描述了TOS字段的旧解释（作为三个独立的位，无法指定货币成本应最小化）。尽管很明显，RFC-1060中的值应该如何根据本备忘录进行解释，但RFC中的信息在此复制。唯一的实际变化是ICMP（符合本备忘录第5.1节）和NNTP：
----- Type-of-Service Value -----

     Protocol          		 TOS Value

     TELNET (1)       	   	    1000                 (minimize delay)

     FTP
       Control       			    1000                 (minimize delay)
       Data (2)      			    0100                 (maximize throughput)

     TFTP          		        1000                 (minimize delay)

     SMTP (3)
       Command phase     1000                 (minimize delay)
       DATA phase       	    0100                 (maximize throughput)
     Domain Name Service
       UDP Query        		1000                 (minimize delay)
       TCP Query        		0000
       Zone Transfer    		0100                 (maximize throughput)

     NNTP               			0001                 (minimize monetary cost)

     ICMP
       Errors           			0000
       Requests         			0000 (4)
       Responses         (4)

     Any IGP            			0010                 (maximize reliability)

     EGP                			0000

     SNMP               			0010                 (maximize reliability)

     BOOTP              		0000

注意：

（1）包括所有交互式用户协议（例如，rlogin）。
（2）包括所有批量数据传输协议（例如，rcp）。
（3）如果实现不支持在连接的生命周期内更改TOS ，则在打开连接时建议的TOS是默认的TOS（0000）。
（4）尽管通常使用默认的TOS 发送ICMP请求消息，但是有时出于某些原因，为什么将它们与其他TOS值一起发送。ICMP响应始终使用与相应ICMP请求消息中使用的相同的TOS值。请参阅本备忘录的第5.1节。

应用程序可以（应用户的请求）用0001 （最小化货币成本）代替以上任何一个值。
预期该附录将在下一版“分配的数字”文档中被淘汰。

A.3 RFC-1122和RFC-1123（主机要求）
RFC-1122 [1]和RFC-1123 [2] 中详细描述了主机对TOS字段的使用。此处提供的信息仍然正确，除了：

（1）TOS字段为四位而不是五位。引用TOS字段的要求应仅引用组成TOS字段的四个位。
（2）应用程序可以将TOS八位位组的第6位设置为非零值（但仍不得将第7位设置为非零值）。

这些详细信息可能会在下一版的主机要求规范，此时该附录可被视为过时的。

A.4 RFC-1195（集成IS-IS）
集成IS-IS（有时称为双IS-IS）为每个路由具有多个度量。哪个度量标准用于路由特定IP数据包由数据包中的TOS字段确定。
RFC-1195 [7]的3.5节对此进行了详细说明。

该部分中的表格描述了从TOS字段的值到适当的集成IS-IS度量的映射。尽管本备忘录中的规范旨在与集成IS-IS实质上兼容，但是扩展了将TOS字段更改为4位，并添加请求“最小化货币成本” 的TOS值，需要对该表进行较小的修改，如下所示：

IP TOS八位位组映射到以下四个可用度量：

     Bits 0-2（优先级）：（与RFC-1195相同）

     位3-6（TOS）：

        0000（全部正常）使用默认度量
        1000（最小化延迟）使用延迟度量
        0100（最大吞吐量）使用默认度量
        0010（最大可靠性）使用可靠性度量
        0001 （最小化货币成本）使用成本指标
        其他使用默认度量标准的

     位7（MBZ）：集成IS-IS忽略此位。

预期集成IS-IS 规范的下一个修订版将包含此更正的表，届时该附录可以被认为已过时。

A.5 RFC-1247（OSPF）和RFC-1248（OSPF MIB）
尽管本备忘录中的规范旨在与OSPF实质上兼容，但将TOS字段扩展为4位需要对以下部分进行较小的修改：
描述了在RFC-1247 [10]的12.3节中描述的链接状态广告中TOS值的编码。该备忘录的表17中汇总了编码。
下面是表17 的更新版本。第一列中的数字是十进制整数，第二列中的数字是二进制TOS 值：

            OSPF编码TOS 
            _____________________________________________ 

            0 0000正常服务
            2 0001最小化货币成本
            4 0010最大化可靠性
            6 0011
            8 0100最大化吞吐量
            10 0101 
            12 0110 
            14 0111 
            16 1000最小化延迟
            18 1001 
            20 1010 
            22 1011 
            24 1100 
            26 1101 
            28 1110 
            30 1111 

RFC-1248 [5]中描述的OSPF MIB 与本备忘录完全一致，除了描述以下内容的文字评论将旧的TOS标志位映射到TOSType值。TOSType 值使用与OSPF的链接状态公告相同的TOS值编码，因此上表还描述了TOSType值（第一列）和TOS字段值（第二列）之间的映射。

如果将来对RFC-1247和RFC-1248进行修订，则有望将此信息合并到修订版本中。那时，该附录可能被认为已过时。

附录B

本备忘录的主体描述了TOS 设施如何工作的细节。本附录适用于那些想知道为什么这样工作的人。

本文档中的大部分内容可以通过一个简单的事实来解释，即本文档的目标是提供现有TOS设施的清晰完整的规范，而不是从头开始设计IP的新服务质量机制。尽管此备忘录确实以下面讨论的一些小巧且经过深思熟虑的方式对设施进行了修改，但从未希望与现有规范和TOS设施[1,2,7,10,11]的使用兼容怀疑。向后兼容的目标确定了本规范的概述和许多细节。

本规范的其余大部分内容由另外两个目标决定，这些目标在第2节中进行了更详细的描述。第一个目标是，主机永远不应因使用TOS 设施而受到惩罚，因为这很可能确保主机永远不会被广泛部署。 。第二个问题是该规范应该使将来（至少在将来）定义和部署新的服务类型变得容易或至少可行。

上面的三个目标并未消除对工程选择的所有需求，但是在某些情况下，这些目标被证明是可行的。彼此冲突。本附录的其余部分讨论了其中一些工程选择背后的原理。

B.1最小化货币成本TOS值

由于Internet日益商业化，IETF路由器要求工作组的许多参与者认为拥有TOS值很重要，这将使用户能够声明货币成本更高。比其他服务质量更重要。

关于此值的确切含义，存在很多争论。例如，有人认为TOS值应表示“绝不花钱”。这被拒绝有几个原因。因为它将请求特定级别的服务（成本= 0），而不是仅请求最小化或最大化某个服务属性，所以它不仅在哲学上与其他TOS值不一致，而且在主机和路由器中都需要特殊的代码。同样，这对于希望其数据包通过最低成本路径但在必要时可以接受一定水平成本的用户也无济于事。最后，由于当路由是由网络管理器做出的选择时，任何特定路由域是否考虑TOS字段，因此，如果数据包必须通过在其路由决策中不考虑TOS的路由域，则要求自由路径的用户可能无法获得该TOS字段。

有人提出了一个略微的变化：TOS值，它表示“我愿意为交付这个数据包而付钱”。该提议遭受了与前一个提议相同的大多数缺点，并且还存在一个有趣的怪癖：由于第7.2节中指定的算法，使用此TOS值的任何数据包都将优先选择花费金钱的链接，而不是同样好的免费链接。因此，这样的TOS值几乎是相当于“最大化货币成本”值！

未来，用户似乎可能需要某种机制来表达他们愿意为传送数据包而支付的最大金额。但是，IP选项将是一种更合适的机制，因为存在所有路由器都必须遵循的IP 选项的先例，并且IP选项可以包含诸如用户愿意支付的最大金额之类的参数。因此，此备忘录中定义的TOS值仅请求网络“最小化货币成本”。

B.2 TOS字段的规范

有四个目标指导了决定将四位数TOS字段和该字段的值的规范：

   （1）定义一种新的服务类型，要求网络“最小化货币成本” 

   （2）保持与TOS设施的现有规范和使用尽可能兼容

   （3）为了将来可以定义和部署新的服务类型

   （4）永久固定TOS字段的大小

最后一个目标似乎令人惊讶，但是当新的服务类型出现时，路由才能正常工作是必要的正在部署。如果路由器对路由器的大小有不同的想法他们在TOS字段中做出的决策不一致，可能导致路由循环。

乍一看，目标（3）和（4）似乎是相互排斥的。IP报头当前只有三个未使用的位，因此最多可以定义三种新的服务位，而无需采取不切实际的步骤来更改IP报头格式。由于需要分配其中之一来实现目标（1），因此最多可以保留两位以用于新的或实验性的服务类型。两者是否足够不仅令人怀疑，而且IETF和IAB不可能将所有当前未使用的位永久保留给可能定义或可能定义的服务类型。

但是，个别位的某些（如果不是全部）可能的组合将无用。显然，设置所有位将等同于不设置任何位，因为设置所有位将指示优化类型中的任何一种都不比其他类型重要。尽管可以为大多数人分配合理的语义对于成对的比特，不清楚由各种路径提供的网络服务范围是否可以以如此精细的方式有效地细分。如果可以将这些无用的比特组合中的一些分配给新的服务类型，则有可能满足目标（3）和目标（4），而不必用尽IP头中的所有剩余保留比特。显而易见的方法是更改TOS值的解释，以使它们是整数而不是可独立设置的位。

选择整数以与RFC-791中的位定义兼容。因此，例如，将TOS字段设置为1000（最小延迟）设置服务类型八位位组的第3位；在RFC-791中，位3被定义为低延迟位。本备忘录仅定义与设置RFC-791位中的单个位相对应的值，因为设置多个TOS位似乎并不常见。根据[15]，当前没有一个通用的TCP / IP 应用程序设置多个TOS位。但是，如果确定是否有用，则可以定义与RFC-791位的特定组合对应的TOS值。

用于“最小化货币成本”的新TOS值必须是一个不会因预先存在而被太误解的值实现。这似乎暗示该值应为一个值，以使所有RFC-791位均保持清零状态。这将需要扩展TOS字段，但将允许旧的实现将请求最小化货币成本（TOS 0001）的数据包视为已请求默认的TOS。这不是一个完美的解决方案，因为（如上所述）更改TOS字段的大小可能会导致路由环路，如果某些路由器要基于三位TOS字段进行路由，而其他路由器要基于四位TOS字段进行路由。幸运的是，在实践中这应该不是什么大问题，因为基于三位TOS字段非常少见，因为它正在编写中，并且只有在发布此规范后才会变得越来越多。

由于这些考虑，并且为了允许合理数量的TOS值用于将来的定义，似乎需要扩展TOS字段。剩下的问题是要扩大多少。将其扩展到五位将允许将来进行相当大的扩展（27个新的TOS值），并且与主机要求保持一致，但是将其减少到一个IP标头中保留位的数量。将TOS字段扩展到4位将限制将来扩展到更适中的级别（11个新的TOS值），但将使额外的IP头位保持空闲。IETF的路由器要求工作组得出结论，四位宽的TOS字段允许有足够的值供将来使用，并且与主机要求的一致性不足以证明不必要地增加了TOS 字段的大小。

B.3弱TOS路由的选择

“下一跳上的总结” [4]描述了基于TOS字段的三种替代路由方法。简要地说，它们是：

   （1）强大的服务条款-仅当路由的TOS 与要路由的数据报中的TOS完全匹配时，才可以使用该路由。如果不存在具有所请求的TOS的路由，则将丢弃该数据包。

   （2）弱TOS- 与强TOS相似，不同之处在于，如果没有路由具有所请求的TOS ，则使用具有默认TOS （0000）的路由。如果没有使用所请求的TOS或默认TOS的路由，则将丢弃该数据包。

   （3）非常弱的TOS- 与弱TOS相似，不同之处在于，如果不存在具有所请求的TOS或默认TOS的路由，则使用数值最小的TOS路由。

  本规范采用了弱TOS。

强大的TOS很快就被拒绝了。因为它要求数据包遍历的每个路由器都有一条带有所请求的TOS的路由，所以请求非零的TOS值的数据包将具有被丢弃为不可传递的高可能性（至少直到TOS设施被广泛使用为止）。这违反了原则（第2节中所述），即主机不应因选择非零的TOS值而受到惩罚。

弱TOS和极弱TOS之间的选择并不那么简单。之所以选择弱TOS，是因为它的实现稍微简单一些，而且它与OSPF和集成的is-is规范相一致。此外，许多人不喜 欢非常弱的TOS，因为无法凭直觉就无法在没有可用路线都具有请求的或默认的TOS 的情况下选择路线的算法进行直觉判断（没有理由认为数字较小的TOS会构成一条路线更好）。由于路由器将需要了解所有TOS值的语义以做出更明智的选择，因此似乎没有合理的方法来解决这种特殊的缺陷。TOS非常弱。

在实践中，期望在“弱TOS”和“ 极弱TOS” 之间进行选择几乎没有什么实际差异，因为（除非网络管理员有意设置，否则）会有一条默认TOS的路由到达任何目的地是与任何其他服务条款的路线。

B.4最长匹配路由的保留

一个有趣的问题是应该在路由选择过程TOS 中考虑多早。似乎有两种明显的可能性：

   （1）找到最匹配数据包目的地址的路由集。从这些中选择路线最符合要求的服务条款。

   （2）找到最符合请求的服务条款的路线集。从这些中，选择最匹配数据包目标地址的路由。

据信这两种方法都支持相同的路由策略集。两者中的哪一个允许更简单的配置并最小化需要传递的路由信息​​的数量似乎取决于拓扑，尽管有些人认为第二个选择在这方面略有优势。

在第一种选择下，如果网络管理员忽略了一些在某些配置中，可能的结果是，将受益于TOS特定路由的某些数据包进行路由，就好像它们请求了默认TOS一样。然而，在第二种选择下，网络管理员可以轻松地（偶然地）配置事物，以使请求某个TOS并应在本地传送的数据包将遵循该TOS 的默认路由，然后转储到Internet中。因此，面对网络管理器的错误，第一种选择在健壮性方面似乎略有优势。

还建议使用第一种选择，它的另一个好处是允许在包含两个在其路由决策中考虑TOS的路由器和不考虑TOS的路由器的路由域中进行无环路由。在所有情况下是否都是这样还未知。但是，确实是这种情况，在第二种选择下，将考虑TOS的路由器和不在同一路由域中的路由器混合在一起是行不通的。

总而言之，没有真正令人信服的论据来选择一种或另一种方式，但是仍然有必要做出一种选择。选择：如果不同的路由器做出不同的选择，则会导致混乱（以路由环路的形式）。本备忘录中指定的机制反映了第一种选择，因为这对于大多数网络管理员来说可能更直观。传统上，Internet 路由选择了与目标地址最匹配的路由，而其他机制仅充当平局。第一种选择与该传统一致。

B.5使用目的地不可达

也许本规范中最具争议和最缺乏防御性的部分是可以丢弃数据包，因为即使到达相同目的地但请求其他TOS 的数据包也可以传递，该目的地仍被视为不可到达。这似乎危险地接近违反了以下原则：即主机永远不会因在其发出的数据包中请求非默认TOS值而受到惩罚。

这仅会在三种情况下发生，这种情况有些不同寻常：

   （1）存在一条到达数据包目的地的路由，该路由具有数据包中请求的TOS值，但该路由具有无限量度。

   （2）到封包目的地的唯一路由具有TOS值除了数据包中请求的那个。其中之一具有默认的TOS，但它具有无限量度。

   （3）到数据包目的地的唯一路由的TOS值不同于数据包中请求的路由。它们都没有默认的TOS。

公认的是，如果具有默认路由的路由器在其转发表中具有到目标的更特定的路由，但该路由具有无限量度，则该路由器仍应丢弃数据包。前两种情况似乎类似于该规则。

此外，值得注意的是，除了在拓扑更改引起的短暂瞬变期间，具有无限量度的路由仅是由于网络管理器的故意行为（或严重错误）而产生的。因此，除非网络管理者已采取有意的措施使数据包被丢弃，否则不太可能将其丢弃。有人认为这是该规范的重要特征，它允许网络（例如）将那些要求将成本降至最低的数据包保留在昂贵的链路之外，以至于网络管理员对用户希望丢弃其数据包充满信心。其他人（包括本备忘录的作者）认为，此“功能”将被证明是无用的，并且链接访问控制可能需要其他机制，但无法证明以消除该限制的必要方式更改此规范是合理的。 “特征”。

上面的情况（3）更成问题。通过使用非常弱的TOS 可以避免这种情况，但是由于附录B.3中讨论的原因，该想法被拒绝了。有人建议可以通过放宽最长匹配路由来解决情况（3）（请参见附录B.4），但是这个想法被拒绝了，因为它会增加路由器的复杂性，而不必使他们的路由选择特别直观。还值得注意的是，这是网络管理员必须努力创建的另一种情况：由于OSPF和集成式IS-IS都强制执行以下约束：必须存在一条默认TOS的路由，该路由将到达任何目标如果TOS为非零，则网络管理员必须等待新路由协议的开发或使用静态路由来解决问题。在最终的结论是，任何修复程序的情况下（3）比糟糕的问题。

附录C. TOS机制的局限性

必须注意，TOS设施有一些局限性。有些是本规范中工程选择的结果。在不替换RFC-791中定义的TOS 设施或接受直到Internet上的所有路由器都支持TOS设施才无法正常工作的情况下，可能无法避免其他被称为“固有限制”的事物。

C.1固有限制

最重要的固有限制是TOS 设施严格来说是一种咨询机制。这不是请求服务保证的适当机制。那里造成这种情况的两个原因：

   （1）在决定如何处理和路由数据包时，并非所有网络都会考虑TOS字段的值。在某种程度上，这是一个过渡问题：某些网络将使用早于此规范的设备，这将有一段（可能很长的时间）。但是，即使是长期来看，许多网络也无法通过考虑TOS字段的价值来提供更好的服务。例如，通过对于任何可能的TOS 值，由互连LAN 的同类集合组成的网络可能是相同的。在这样的网络内部，要求路由器和路由协议进行转发数据包时考虑TOS字段的值所需的额外工作几乎没有意义。

   （2）TOS机制的功能不足以允许应用程序量化其所需的服务级别。对于例如，一个应用程序可以使用TOS字段请求网络选择最大化吞吐量的路径，但是无法使用该机制的说，它需要或想要一个每秒特定的千字节或兆字节数。由于网络无法知道应用程序需要什么，因此网络决定放弃请求最大吞吐量的数据包是不合适的，因为没有“高吞吐量”路径可用。

对于某些类型的网络应用程序而言，无法提供资源保证是一个严重的缺陷。例如，当可用带宽不足以传递可理解的语音时，使用打包语音的系统只会造成网络拥塞。同样，网络甚至不必费心表达声音数据包在网络中遭受的延迟超过了应用程序所不能承受的范围。不幸的是，资源保证在无连接网络中是有问题的。Internet研究人员正在积极研究此问题，并乐观地认为他们将能够发明Internet架构可以演变为支持资源保证的方法，同时保留无连接网络的优点。

C.2本规范的局限性

TOS设施还有一些其他局限性，这些局限性不是固有的局限性，而是本规范中所做的工程选择的结果：

（1） 对于某些TOS值，路由并不是真正的最佳选择。这是因为这些TOS值的最佳路由要求路由协议认识到TOS值的语义，并使用特殊算法来计算它们的路由。例	如，路由协议传统上是通过将构成路径的各个链路的成本相加来计算路径的度量。但是，为了最大程度地提高可靠性，路由协议将不得不计算度量标准，该度量标准是路径中每个单独链接成功交付的概率的乘积。尽管从某种意义上说该限制是当前路由协议的限制，而不是本规范的限制，但存在许多没有当前定义的语义的合法TOS值而加剧了该问题。

   （2）本规范假设网络管理员将做“ 正确的事情”。如果路由域使用TOS，则网络管理器必须以以下方式配置路由器：为每个TOS选择合理的路径。尽管这应该不是很困难，但网络管理员可能会偶然或有意违反我们的规则，即使用TOS工具应至少提供与不使用服务一样好的服务。